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

CWE-59

Allowed

Improper Link Resolution Before File Access ('Link Following')

Abstraction: Base · Status: Draft

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource.

2236 vulnerabilities reference this CWE, most recent first.

GHSA-8PGQ-966C-5F7Q

Vulnerability from github – Published: 2022-05-17 03:52 – Updated: 2022-05-17 03:52
VLAI
Details

lisp/emacs-lisp/find-gc.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on a temporary file under /tmp/esrc/.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-3422"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-05-08T10:55:00Z",
    "severity": "LOW"
  },
  "details": "lisp/emacs-lisp/find-gc.el in GNU Emacs 24.3 and earlier allows local users to overwrite arbitrary files via a symlink attack on a temporary file under /tmp/esrc/.",
  "id": "GHSA-8pgq-966c-5f7q",
  "modified": "2022-05-17T03:52:13Z",
  "published": "2022-05-17T03:52:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-3422"
    },
    {
      "type": "WEB",
      "url": "http://advisories.mageia.org/MGASA-2014-0250.html"
    },
    {
      "type": "WEB",
      "url": "http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17428#8"
    },
    {
      "type": "WEB",
      "url": "http://lists.gnu.org/archive/html/emacs-diffs/2014-05/msg00056.html"
    },
    {
      "type": "WEB",
      "url": "http://openwall.com/lists/oss-security/2014/05/07/7"
    },
    {
      "type": "WEB",
      "url": "http://www.mandriva.com/security/advisories?name=MDVSA-2015:117"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8PMQ-VH8M-9XJ5

Vulnerability from github – Published: 2025-02-11 18:31 – Updated: 2025-02-11 18:31
VLAI
Details

Windows Deployment Services Denial of Service Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-21347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-11T18:15:33Z",
    "severity": "MODERATE"
  },
  "details": "Windows Deployment Services Denial of Service Vulnerability",
  "id": "GHSA-8pmq-vh8m-9xj5",
  "modified": "2025-02-11T18:31:38Z",
  "published": "2025-02-11T18:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21347"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21347"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8PV9-VFQJ-Q49W

Vulnerability from github – Published: 2022-05-24 17:44 – Updated: 2026-08-19 18:31
VLAI
Details

Windows Update Service Elevation of Privilege Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-26866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-11T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows Update Service Elevation of Privilege Vulnerability",
  "id": "GHSA-8pv9-vfqj-q49w",
  "modified": "2026-08-19T18:31:29Z",
  "published": "2022-05-24T17:44:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26866"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-26866"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-26866"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-21-286"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8Q24-HC9H-H952

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-03-20 12:32
VLAI
Details

GPT Academic version 3.83 is vulnerable to a Local File Read (LFI) vulnerability through its HotReload function. This function can download and extract tar.gz files from arxiv.org. Despite implementing protections against path traversal, the application overlooks the Tarslip triggered by symlinks. This oversight allows attackers to read arbitrary local files from the victim server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-10986"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:22Z",
    "severity": "HIGH"
  },
  "details": "GPT Academic version 3.83 is vulnerable to a Local File Read (LFI) vulnerability through its HotReload function. This function can download and extract tar.gz files from arxiv.org. Despite implementing protections against path traversal, the application overlooks the Tarslip triggered by symlinks. This oversight allows attackers to read arbitrary local files from the victim server.",
  "id": "GHSA-8q24-hc9h-h952",
  "modified": "2025-03-20T12:32:41Z",
  "published": "2025-03-20T12:32:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10986"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/db2167f5-f17f-491d-aeec-69ba55bf6427"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8QF9-62X2-82PP

Vulnerability from github – Published: 2026-08-17 21:56 – Updated: 2026-08-17 21:56
VLAI
Summary
chrome-devtools-mcp: validatePath() does not canonicalize symlinks before enforcing roots
Details

Summary

I originally reported this through Google Bug Hunters. The Google Bug Hunters team said this is in OSS VRP scope but not reward-eligible due to the project tier, and asked me to file an issue or PR directly with this repository. I am reporting it privately here first because it is an unfixed security issue.

McpContext.validatePath() enforces workspace roots by checking whether path.resolve(filePath) textually falls under one of the configured root paths. path.resolve() does not canonicalize symbolic links. As a result, a symlink inside a configured workspace root can point to a file outside that root, pass validation, and then be followed by downstream file read/write operations.

This bypass applies even when the MCP client correctly declares the roots capability with a non-empty list. It is separate from the documented legacy behavior where missing roots capability allows all paths.

The practical impact is a workspace-boundary bypass. In the write direction, filePath-writing tools can overwrite out-of-root files through an in-root symlink. In the read direction, upload_file can read through the symlink and send the file to the currently selected web page.

Details

Affected code:

src/McpContext.ts:178-199

validatePath(filePath?: string): void {
  if (filePath === undefined) {
    return;
  }
  const roots = this.roots();
  if (roots === undefined) {
    return;
  }
  const absolutePath = path.resolve(filePath);
  for (const root of roots) {
    const rootPath = path.resolve(fileURLToPath(root.uri));
    if (
      absolutePath === rootPath ||
      absolutePath.startsWith(rootPath + path.sep)
    ) {
      return;
    }
  }
  throw new Error(
    `Access denied: path ${filePath} is not within any of the workspace roots ${JSON.stringify(roots)}.`,
  );
}

path.resolve() only normalizes path text such as . and ... It does not call realpath() and does not resolve symlinks. Therefore, a path like:

/workspace/project/cache/profile

can textually pass the /workspace prefix check even when cache/profile is a symlink to:

/home/user/.aws/credentials

Downstream consumers then perform real filesystem operations without O_NOFOLLOW:

  • src/McpContext.ts:720-738 saveFile() uses fs.mkdir({recursive: true}) and fs.writeFile().
  • src/tools/input.ts:454-497 upload_file calls puppeteer.uploadFile(filePath) or fileChooser.accept([filePath]).
  • Other filePath-writing tools include screenshots, heap snapshots, network response save paths, snapshots, screencasts, Lighthouse output, and performance trace saves.

This is not a TOCTOU/race condition. The symlink exists before validation and the PoC uses a single process. The issue is a canonicalization bypass / improper link resolution.

Preconditions:

  • The MCP client declares roots and supplies at least one workspace root.
  • A symlink exists inside the workspace and points outside the workspace.
  • For the remote prompt-injection chain, the user processes untrusted page content while chrome-devtools-mcp is connected.

A remote attacker does not need local access if a suitable workspace-internal symlink already exists, or if another trusted tool/workflow can create it. Without such a symlink, the issue is a local/workspace-state-dependent boundary bypass.

PoC

Conceptual exploitation with a configured root:

Configured roots:
  file:///workspace

Workspace path:
  /workspace/project/cache/profile -> /home/user/.aws/credentials

Tool call:
  upload_file({
    filePath: "/workspace/project/cache/profile",
    uid: "<file input element on current page>"
  })

Result:
  validatePath() accepts the path because it textually starts with /workspace.
  Puppeteer follows the symlink and uploads the target file to the page.

Lab-only PoC that replicates the exact validation logic and subsequent write. It writes only inside a fresh temporary directory and touches no system paths:

const path = require('node:path');
const fs = require('node:fs');
const os = require('node:os');
const {pathToFileURL, fileURLToPath} = require('node:url');

const lab = fs.mkdtempSync(path.join(os.tmpdir(), 'cdtmcp-lab-'));

try {
  fs.chmodSync(lab, 0o755);

  const workspace = path.join(lab, 'workspace');
  fs.mkdirSync(workspace);

  const outside = path.join(lab, 'outside-secret.txt');
  fs.writeFileSync(outside, 'sensitive outside content\n');

  const symlinkInside = path.join(workspace, 'innocent.txt');
  fs.symlinkSync(outside, symlinkInside);

  function validatePath(filePath, roots) {
    const absolutePath = path.resolve(filePath);
    for (const root of roots) {
      const rootPath = path.resolve(fileURLToPath(root.uri));
      if (
        absolutePath === rootPath ||
        absolutePath.startsWith(rootPath + path.sep)
      ) {
        return true;
      }
    }
    throw new Error(`Access denied: ${filePath}`);
  }

  const roots = [{uri: pathToFileURL(workspace).href, name: 'workspace'}];
  validatePath(symlinkInside, roots);

  fs.writeFileSync(symlinkInside, 'OVERWRITTEN BY MCP\n');

  console.log(fs.readFileSync(outside, 'utf8'));
  // -> "OVERWRITTEN BY MCP"
} finally {
  fs.rmSync(lab, {recursive: true, force: true});
}

Observed result:

validatePath() accepts the in-root symlink path.
The subsequent write follows the symlink and modifies the out-of-root target.

I can provide an end-to-end MCP client reproduction if needed. The lab PoC above demonstrates the root cause using the same validation logic as the server.

Impact

Who can exploit:

  • A local process/user or trusted workflow that can create a symlink inside the workspace.
  • A remote page/prompt-injection attacker, if a suitable workspace-internal symlink already exists or can be created by another trusted workflow/tool.

Security impact:

  • Integrity: tools that write to filePath can overwrite files outside the configured workspace root through an in-root symlink.
  • Confidentiality: upload_file can read a file outside the workspace through an in-root symlink and attach it to a file input on the current page.
  • Stealth/auditability: the exfiltration path goes through normal page file-upload behavior, and chrome-devtools-mcp does not appear to log the canonical path that was uploaded.

Example sensitive files reachable if symlinked into the workspace:

  • Cloud credentials such as ~/.aws/credentials, ~/.config/gcloud/..., or ~/.azure/....
  • SSH private keys or .ssh files readable by the user.
  • Project secrets such as .env, .npmrc, .netrc, secrets.json, and API tokens.
  • Out-of-workspace source files or configuration files.

Severity:

  • Suggested GitHub severity: Moderate.
  • CVSS v3.1 chain estimate: CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N.
  • AC:H reflects that a workspace-internal symlink must exist at validation time.

Suggested fix:

Canonicalize paths before comparing against roots. For an existing file, use fs.realpath() on the path. For a new file, resolve the parent directory with fs.realpath() and re-join the basename.

```ts async validatePath(filePath?: string): Promise { if (filePath === undefined) return; const roots = this.roots(); if (roots === undefined) return;

const abs = path.resolve(filePath); let canonical; try { canonical = await fs.realpath(abs); } catch (err) { if (err.code === 'ENOENT') { const parent = await fs.realpath(path.dirname(abs)); canonical = path.join(parent, path.basename(abs)); } else { throw err; } }

for (const root of roots) { const canonicalRoot = await fs.realpath(fileURLToPath(root.uri)); if ( canonical === canonicalRoot || canonical.startsWith(canonicalRoot + path.sep) ) { return; } }

throw new Error( Access denied: ${filePath} (canonical: ${canonical}) is not within any workspace root., ); }

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "chrome-devtools-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.24.0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-17T21:56:12Z",
    "nvd_published_at": "2026-06-24T22:16:47Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nI originally reported this through Google Bug Hunters. The Google Bug Hunters team said this is in OSS VRP scope but not reward-eligible due to the project tier, and asked me to file an issue or PR directly with this repository. I am reporting it privately here first because it is an unfixed security issue.\n\n`McpContext.validatePath()` enforces workspace `roots` by checking whether `path.resolve(filePath)` textually falls under one of the configured root paths. `path.resolve()` does not canonicalize symbolic links. As a result, a symlink inside a configured workspace root can point to a file outside that root, pass validation, and then be followed by downstream file read/write operations.\n\nThis bypass applies even when the MCP client correctly declares the `roots` capability with a non-empty list. It is separate from the documented legacy behavior where missing `roots` capability allows all paths.\n\nThe practical impact is a workspace-boundary bypass. In the write direction, filePath-writing tools can overwrite out-of-root files through an in-root symlink. In the read direction, `upload_file` can read through the symlink and send the file to the currently selected web page.\n\n### Details\n\nAffected code:\n\n`src/McpContext.ts:178-199`\n\n```ts\nvalidatePath(filePath?: string): void {\n  if (filePath === undefined) {\n    return;\n  }\n  const roots = this.roots();\n  if (roots === undefined) {\n    return;\n  }\n  const absolutePath = path.resolve(filePath);\n  for (const root of roots) {\n    const rootPath = path.resolve(fileURLToPath(root.uri));\n    if (\n      absolutePath === rootPath ||\n      absolutePath.startsWith(rootPath + path.sep)\n    ) {\n      return;\n    }\n  }\n  throw new Error(\n    `Access denied: path ${filePath} is not within any of the workspace roots ${JSON.stringify(roots)}.`,\n  );\n}\n```\n\n`path.resolve()` only normalizes path text such as `.` and `..`. It does not call `realpath()` and does not resolve symlinks. Therefore, a path like:\n\n```text\n/workspace/project/cache/profile\n```\n\ncan textually pass the `/workspace` prefix check even when `cache/profile` is a symlink to:\n\n```text\n/home/user/.aws/credentials\n```\n\nDownstream consumers then perform real filesystem operations without `O_NOFOLLOW`:\n\n- `src/McpContext.ts:720-738` `saveFile()` uses `fs.mkdir({recursive: true})` and `fs.writeFile()`.\n- `src/tools/input.ts:454-497` `upload_file` calls `puppeteer.uploadFile(filePath)` or `fileChooser.accept([filePath])`.\n- Other filePath-writing tools include screenshots, heap snapshots, network response save paths, snapshots, screencasts, Lighthouse output, and performance trace saves.\n\nThis is not a TOCTOU/race condition. The symlink exists before validation and the PoC uses a single process. The issue is a canonicalization bypass / improper link resolution.\n\nPreconditions:\n\n- The MCP client declares `roots` and supplies at least one workspace root.\n- A symlink exists inside the workspace and points outside the workspace.\n- For the remote prompt-injection chain, the user processes untrusted page content while chrome-devtools-mcp is connected.\n\nA remote attacker does not need local access if a suitable workspace-internal symlink already exists, or if another trusted tool/workflow can create it. Without such a symlink, the issue is a local/workspace-state-dependent boundary bypass.\n\n### PoC\n\nConceptual exploitation with a configured root:\n\n```text\nConfigured roots:\n  file:///workspace\n\nWorkspace path:\n  /workspace/project/cache/profile -\u003e /home/user/.aws/credentials\n\nTool call:\n  upload_file({\n    filePath: \"/workspace/project/cache/profile\",\n    uid: \"\u003cfile input element on current page\u003e\"\n  })\n\nResult:\n  validatePath() accepts the path because it textually starts with /workspace.\n  Puppeteer follows the symlink and uploads the target file to the page.\n```\n\nLab-only PoC that replicates the exact validation logic and subsequent write. It writes only inside a fresh temporary directory and touches no system paths:\n\n```js\nconst path = require(\u0027node:path\u0027);\nconst fs = require(\u0027node:fs\u0027);\nconst os = require(\u0027node:os\u0027);\nconst {pathToFileURL, fileURLToPath} = require(\u0027node:url\u0027);\n\nconst lab = fs.mkdtempSync(path.join(os.tmpdir(), \u0027cdtmcp-lab-\u0027));\n\ntry {\n  fs.chmodSync(lab, 0o755);\n\n  const workspace = path.join(lab, \u0027workspace\u0027);\n  fs.mkdirSync(workspace);\n\n  const outside = path.join(lab, \u0027outside-secret.txt\u0027);\n  fs.writeFileSync(outside, \u0027sensitive outside content\\n\u0027);\n\n  const symlinkInside = path.join(workspace, \u0027innocent.txt\u0027);\n  fs.symlinkSync(outside, symlinkInside);\n\n  function validatePath(filePath, roots) {\n    const absolutePath = path.resolve(filePath);\n    for (const root of roots) {\n      const rootPath = path.resolve(fileURLToPath(root.uri));\n      if (\n        absolutePath === rootPath ||\n        absolutePath.startsWith(rootPath + path.sep)\n      ) {\n        return true;\n      }\n    }\n    throw new Error(`Access denied: ${filePath}`);\n  }\n\n  const roots = [{uri: pathToFileURL(workspace).href, name: \u0027workspace\u0027}];\n  validatePath(symlinkInside, roots);\n\n  fs.writeFileSync(symlinkInside, \u0027OVERWRITTEN BY MCP\\n\u0027);\n\n  console.log(fs.readFileSync(outside, \u0027utf8\u0027));\n  // -\u003e \"OVERWRITTEN BY MCP\"\n} finally {\n  fs.rmSync(lab, {recursive: true, force: true});\n}\n```\n\nObserved result:\n\n```text\nvalidatePath() accepts the in-root symlink path.\nThe subsequent write follows the symlink and modifies the out-of-root target.\n```\n\nI can provide an end-to-end MCP client reproduction if needed. The lab PoC above demonstrates the root cause using the same validation logic as the server.\n\n### Impact\n\nWho can exploit:\n\n- A local process/user or trusted workflow that can create a symlink inside the workspace.\n- A remote page/prompt-injection attacker, if a suitable workspace-internal symlink already exists or can be created by another trusted workflow/tool.\n\nSecurity impact:\n\n- Integrity: tools that write to `filePath` can overwrite files outside the configured workspace root through an in-root symlink.\n- Confidentiality: `upload_file` can read a file outside the workspace through an in-root symlink and attach it to a file input on the current page.\n- Stealth/auditability: the exfiltration path goes through normal page file-upload behavior, and chrome-devtools-mcp does not appear to log the canonical path that was uploaded.\n\nExample sensitive files reachable if symlinked into the workspace:\n\n- Cloud credentials such as `~/.aws/credentials`, `~/.config/gcloud/...`, or `~/.azure/...`.\n- SSH private keys or `.ssh` files readable by the user.\n- Project secrets such as `.env`, `.npmrc`, `.netrc`, `secrets.json`, and API tokens.\n- Out-of-workspace source files or configuration files.\n\nSeverity:\n\n- Suggested GitHub severity: Moderate.\n- CVSS v3.1 chain estimate: `CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N`.\n- AC:H reflects that a workspace-internal symlink must exist at validation time.\n\nSuggested fix:\n\nCanonicalize paths before comparing against roots. For an existing file, use `fs.realpath()` on the path. For a new file, resolve the parent directory with `fs.realpath()` and re-join the basename.\n\n```ts\nasync validatePath(filePath?: string): Promise\u003cvoid\u003e {\n  if (filePath === undefined) return;\n  const roots = this.roots();\n  if (roots === undefined) return;\n\n  const abs = path.resolve(filePath);\n  let canonical;\n  try {\n    canonical = await fs.realpath(abs);\n  } catch (err) {\n    if (err.code === \u0027ENOENT\u0027) {\n      const parent = await fs.realpath(path.dirname(abs));\n      canonical = path.join(parent, path.basename(abs));\n    } else {\n      throw err;\n    }\n  }\n\n  for (const root of roots) {\n    const canonicalRoot = await fs.realpath(fileURLToPath(root.uri));\n    if (\n      canonical === canonicalRoot ||\n      canonical.startsWith(canonicalRoot + path.sep)\n    ) {\n      return;\n    }\n  }\n\n  throw new Error(\n    `Access denied: ${filePath} (canonical: ${canonical}) is not within any workspace root.`,\n  );\n}",
  "id": "GHSA-8qf9-62x2-82pp",
  "modified": "2026-08-17T21:56:12Z",
  "published": "2026-08-17T21:56:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ChromeDevTools/chrome-devtools-mcp/security/advisories/GHSA-8qf9-62x2-82pp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53766"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChromeDevTools/chrome-devtools-mcp/pull/2127"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChromeDevTools/chrome-devtools-mcp/commit/176eb695137d9c46a61e2d4d5571880c5145cf46"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ChromeDevTools/chrome-devtools-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ChromeDevTools/chrome-devtools-mcp/releases/tag/chrome-devtools-mcp-v1.1.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "chrome-devtools-mcp: validatePath() does not canonicalize symlinks before enforcing roots"
}

GHSA-8QWF-CXW2-23H9

Vulnerability from github – Published: 2022-05-01 23:57 – Updated: 2022-05-01 23:57
VLAI
Details

The save function in br/prefmanager.d in projectl 1.001 creates a projectL.prf file in the current working directory, which allows local users to overwrite arbitrary files via a symlink attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2008-3216"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-07-18T16:41:00Z",
    "severity": "MODERATE"
  },
  "details": "The save function in br/prefmanager.d in projectl 1.001 creates a projectL.prf file in the current working directory, which allows local users to overwrite arbitrary files via a symlink attack.",
  "id": "GHSA-8qwf-cxw2-23h9",
  "modified": "2022-05-01T23:57:55Z",
  "published": "2022-05-01T23:57:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-3216"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/44059"
    },
    {
      "type": "WEB",
      "url": "http://bugs.debian.org/489988"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2008/07/09/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-8QXF-7FXX-743X

Vulnerability from github – Published: 2026-06-22 21:31 – Updated: 2026-06-22 21:31
VLAI
Details

Dell Wyse Management Suite (WMS), versions prior to WMS 2605, contain an Improper Link Resolution Before File Access vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Unauthorized access.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-44274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-22T20:16:29Z",
    "severity": "HIGH"
  },
  "details": "Dell Wyse Management Suite (WMS), versions prior to WMS 2605, contain an Improper Link Resolution Before File Access vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Unauthorized access.",
  "id": "GHSA-8qxf-7fxx-743x",
  "modified": "2026-06-22T21:31:00Z",
  "published": "2026-06-22T21:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44274"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000472001/dsa-2026-247"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8RMQ-JWCC-5RG4

Vulnerability from github – Published: 2022-05-17 03:03 – Updated: 2025-04-20 03:31
VLAI
Details

mail.local in NetBSD versions 6.0 through 6.0.6, 6.1 through 6.1.5, and 7.0 allows local users to change ownership of or append data to arbitrary files on the target system via a symlink attack on the user mailbox.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2016-6253"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-01-20T15:59:00Z",
    "severity": "HIGH"
  },
  "details": "mail.local in NetBSD versions 6.0 through 6.0.6, 6.1 through 6.1.5, and 7.0 allows local users to change ownership of or append data to arbitrary files on the target system via a symlink attack on the user mailbox.",
  "id": "GHSA-8rmq-jwcc-5rg4",
  "modified": "2025-04-20T03:31:23Z",
  "published": "2022-05-17T03:03:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-6253"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40141"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40385"
    },
    {
      "type": "WEB",
      "url": "http://akat1.pl/?id=2"
    },
    {
      "type": "WEB",
      "url": "http://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2016-006.txt.asc"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/138021/NetBSD-mail.local-8-Local-Root.html"
    },
    {
      "type": "WEB",
      "url": "http://www.rapid7.com/db/modules/exploit/unix/local/netbsd_mail_local"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/92101"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1036429"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8V4R-W49G-JC9W

Vulnerability from github – Published: 2026-06-01 21:30 – Updated: 2026-06-01 21:30
VLAI
Details

CodexBar prior to 0.32.0 contains an insecure temporary file handling vulnerability that allows local attackers to access sensitive credentials or tamper with build artifacts by exploiting predictable file paths in the release notarization workflow. Attackers with access to the same host can read the App Store Connect API key written to a fixed path, pre-create files or symbolic links at predictable locations to redirect writes to attacker-controlled destinations, or tamper with notarization archives before submission.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-49135"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-01T21:16:46Z",
    "severity": "HIGH"
  },
  "details": "CodexBar prior to 0.32.0 contains an insecure temporary file handling vulnerability that allows local attackers to access sensitive credentials or tamper with build artifacts by exploiting predictable file paths in the release notarization workflow. Attackers with access to the same host can read the App Store Connect API key written to a fixed path, pre-create files or symbolic links at predictable locations to redirect writes to attacker-controlled destinations, or tamper with notarization archives before submission.",
  "id": "GHSA-8v4r-w49g-jc9w",
  "modified": "2026-06-01T21:30:44Z",
  "published": "2026-06-01T21:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-49135"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steipete/CodexBar/pull/1228"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steipete/CodexBar/commit/e7d932616508cee43ea9bcc63c269b14698de655"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steipete/CodexBar/releases/tag/v0.32.0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/codexbar-insecure-temporary-file-handling-in-notarization-workflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/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-8VGW-M5FH-HWG3

Vulnerability from github – Published: 2026-08-11 00:31 – Updated: 2026-08-11 00:31
VLAI
Details

The affected TP-Link Aginet devices do not properly validate symbolic links created on external USB storage devices. By placing a crafted symbolic link on supported storage media, an attacker may cause the system to resolve the link.

Successful exploitation may allow unauthorized read access to sensitive files within the device filesystem.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-30240"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-10T23:16:50Z",
    "severity": "MODERATE"
  },
  "details": "The affected TP-Link Aginet devices do not properly validate symbolic links created on external USB storage\ndevices. By placing a crafted symbolic link on supported storage media, an\nattacker may cause the system to resolve the link.\n\n\n\n\n\n\n\n\n\nSuccessful\nexploitation may allow unauthorized read access to sensitive files within the\ndevice filesystem.",
  "id": "GHSA-8vgw-m5fh-hwg3",
  "modified": "2026-08-11T00:31:12Z",
  "published": "2026-08-11T00:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30240"
    },
    {
      "type": "WEB",
      "url": "https://www.tp-link.com/us/support/faq/5239"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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"
    }
  ]
}

Mitigation MIT-48.1
Architecture and Design

Strategy: Separation of Privilege

  • Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Denying access to a file can prevent an attacker from replacing that file with a link to a sensitive file. Ensure good compartmentalization in the system to provide protected areas that can be trusted.
CAPEC-132: Symlink Attack

An adversary positions a symbolic link in such a manner that the targeted user or application accesses the link's endpoint, assuming that it is accessing a file with the link's name.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

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.