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.
1070 vulnerabilities reference this CWE, most recent first.
GHSA-3JJ9-9269-99M2
Vulnerability from github – Published: 2024-08-06 15:30 – Updated: 2024-08-12 18:30Calling PK11_Encrypt() in NSS using CKM_CHACHA20 and the same buffer for input and output can result in plaintext on an Intel Sandy Bridge processor. In Firefox this only affects the QUIC header protection feature when the connection is using the ChaCha20-Poly1305 cipher suite. The most likely outcome is connection failure, but if the connection persists despite the high packet loss it could be possible for a network observer to identify packets as coming from the same source despite a network path change. This vulnerability affects Firefox < 129, Firefox ESR < 115.14, and Firefox ESR < 128.1.
{
"affected": [],
"aliases": [
"CVE-2024-7531"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-06T13:15:57Z",
"severity": "MODERATE"
},
"details": "Calling `PK11_Encrypt()` in NSS using CKM_CHACHA20 and the same buffer for input and output can result in plaintext on an Intel Sandy Bridge processor. In Firefox this only affects the QUIC header protection feature when the connection is using the ChaCha20-Poly1305 cipher suite. The most likely outcome is connection failure, but if the connection persists despite the high packet loss it could be possible for a network observer to identify packets as coming from the same source despite a network path change. This vulnerability affects Firefox \u003c 129, Firefox ESR \u003c 115.14, and Firefox ESR \u003c 128.1.",
"id": "GHSA-3jj9-9269-99m2",
"modified": "2024-08-12T18:30:46Z",
"published": "2024-08-06T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7531"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1905691"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-33"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-34"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2024-35"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3MG2-Q757-F3M2
Vulnerability from github – Published: 2022-05-12 00:01 – Updated: 2022-05-20 00:00TOCTOU (time-of-check to time-of-use) issue in the System Management Unit (SMU) may result in a DMA (Direct Memory Access) to invalid DRAM address that could result in denial of service.
{
"affected": [],
"aliases": [
"CVE-2021-26347"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-11T17:15:00Z",
"severity": "MODERATE"
},
"details": "TOCTOU (time-of-check to time-of-use) issue in the System Management Unit (SMU) may result in a DMA (Direct Memory Access) to invalid DRAM address that could result in denial of service.",
"id": "GHSA-3mg2-q757-f3m2",
"modified": "2022-05-20T00:00:25Z",
"published": "2022-05-12T00:01:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26347"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/corporate/product-security/bulletin/AMD-SB-1031"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1028"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3P2X-HJXJ-C7RV
Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-24 19:04Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-mwcg-wfq3-4gjc. This link is maintained to preserve external references.
Original Description
OpenClaw versions prior to 2026.2.25 contain a time-of-check-time-of-use vulnerability in approval-bound system.run execution where the cwd parameter is validated at approval time but resolved at execution time. Attackers can retarget a symlinked cwd between approval and execution to bypass command execution restrictions and execute arbitrary commands on node hosts.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.2.24"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-24T19:04:22Z",
"nvd_published_at": "2026-03-21T01:17:06Z",
"severity": "MODERATE"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-mwcg-wfq3-4gjc. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw versions prior to 2026.2.25 contain a time-of-check-time-of-use vulnerability in approval-bound system.run execution where the cwd parameter is validated at approval time but resolved at execution time. Attackers can retarget a symlinked cwd between approval and execution to bypass command execution restrictions and execute arbitrary commands on node hosts.",
"id": "GHSA-3p2x-hjxj-c7rv",
"modified": "2026-03-24T19:04:22Z",
"published": "2026-03-21T03:31:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mwcg-wfq3-4gjc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32043"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/f789f880c934caa8be25b38832f27f90f37903db"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-time-of-check-time-of-use-via-mutable-symlink-in-system-run-cwd-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/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\u0027s system.run approval TOCTOU via mutable symlink cwd target on node host",
"withdrawn": "2026-03-24T19:04:22Z"
}
GHSA-3PHX-V48R-RMWC
Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2025-03-18 21:31A TOCTOU (Time-Of-Check-Time-Of-Use) in SMM may allow an attacker with ring0 privileges and access to the BIOS menu or UEFI shell to modify the communications buffer potentially resulting in arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2023-20578"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T17:15:19Z",
"severity": "HIGH"
},
"details": "A TOCTOU (Time-Of-Check-Time-Of-Use) in SMM may allow\nan attacker with ring0 privileges and access to the\nBIOS menu or UEFI shell to modify the communications buffer\u00a0potentially\nresulting in arbitrary code execution.",
"id": "GHSA-3phx-v48r-rmwc",
"modified": "2025-03-18T21:31:48Z",
"published": "2024-08-13T18:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20578"
},
{
"type": "WEB",
"url": "https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3003.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3PQC-836W-JGR7
Vulnerability from github – Published: 2026-01-13 21:53 – Updated: 2026-01-21 16:17Summary
A TOCTOU race condition vulnerability allows a user to exceed the set number of active tunnels in their subscription plan.
Details
Affected conponent: apps/web/src/routes/api/tunnel/register.ts
- /tunnel/register endpoint code-:
// Check if tunnel already exists in database
const [existingTunnel] = await db
.select()
.from(tunnels)
.where(eq(tunnels.url, tunnelUrl));
const isReconnection = !!existingTunnel;
console.log(
`[TUNNEL LIMIT CHECK] Org: ${organizationId}, Tunnel: ${tunnelId}`,
);
console.log(
`[TUNNEL LIMIT CHECK] Is Reconnection: ${isReconnection}`,
);
console.log(
`[TUNNEL LIMIT CHECK] Plan: ${currentPlan}, Limit: ${tunnelLimit}`,
);
// Check limits only for NEW tunnels (not reconnections)
if (!isReconnection) {
// Count active tunnels from Redis SET
const activeCount = await redis.scard(setKey);
console.log(
`[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,
);
// The current tunnel is NOT yet in the online_tunnels set (added after successful registration)
// So we check if activeCount >= limit (not >)
if (activeCount >= tunnelLimit) {
console.log(
`[TUNNEL LIMIT CHECK] REJECTED - ${activeCount} >= ${tunnelLimit}`,
);
return json(
{
error: `Tunnel limit reached. The ${currentPlan} plan allows ${tunnelLimit} active tunnel${tunnelLimit > 1 ? "s" : ""}.`,
},
{ status: 403 },
);
}
console.log(
`[TUNNEL LIMIT CHECK] ALLOWED - ${activeCount} < ${tunnelLimit}`,
);
} else {
console.log(`[TUNNEL LIMIT CHECK] SKIPPED - Reconnection detected`);
}
if (existingTunnel) {
// Tunnel with this URL already exists, update lastSeenAt
await db
.update(tunnels)
.set({ lastSeenAt: new Date() })
.where(eq(tunnels.id, existingTunnel.id));
return json({
success: true,
tunnelId: existingTunnel.id,
});
}
// Create new tunnel record
const tunnelRecord = {
id: randomUUID(),
url: tunnelUrl,
userId,
organizationId,
name: name || null,
protocol,
remotePort: remotePort || null,
lastSeenAt: new Date(),
createdAt: new Date(),
updatedAt: new Date(),
};
await db.insert(tunnels).values(tunnelRecord);
return json({ success: true, tunnelId: tunnelRecord.id });
} catch (error) {
console.error("Tunnel registration error:", error);
return json({ error: "Internal server error" }, { status: 500 });
}
- It checks if the tunnel exists in the database.
// Check if tunnel already exists in database
const [existingTunnel] = await db
.select()
.from(tunnels)
.where(eq(tunnels.url, tunnelUrl));
const isReconnection = !!existingTunnel;
- Limit is checked here-:
// Check limits only for NEW tunnels (not reconnections)
if (!isReconnection) {
// Count active tunnels from Redis SET
const activeCount = await redis.scard(setKey);
console.log(
`[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,
);
- Redis is checked for existing tunnel to check for reconnection.
// Check limits only for NEW tunnels (not reconnections)
if (!isReconnection) {
// Count active tunnels from Redis SET
const activeCount = await redis.scard(setKey);
console.log(
`[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,
);
- If the tunnel limit is exceeded, it pops up the tunnel limit error.
if (activeCount >= tunnelLimit) {
console.log(
`[TUNNEL LIMIT CHECK] REJECTED - ${activeCount} >= ${tunnelLimit}`,
);
return json(
{
error: `Tunnel limit reached. The ${currentPlan} plan allows ${tunnelLimit} active tunnel${tunnelLimit > 1 ? "s" : ""}.`,
},
{ status: 403 },
);
- If the limit is not exceeded, it triggers a the
InsertStatement without locking transactions from other request
await db.insert(tunnels).values(tunnelRecord);
- If parallel requests are made by the
wshandlerin/outray/outray-main/apps/tunnel/src/core/WSHandler.tsfrom the command line app. A request can work on a non updated row because theinsertrow has not been triggered allowing the user to bypass the limit. It is much explained in the proof of concept. The key takeaway is db transactions should remain locked.
PoC
Using this simple bash script, the outray binary will be run at the same time in one tmux window, demonstrating the race condition and opening 4 tunnels.
#!/usr/bin/env bash
# POC for Outray Tunnel Race condition
SESSION="outray-race"
PORTS=(8090 4000 5000 6000)
# Create new detached tmux session
tmux new-session -d -s "$SESSION" "echo '[*] outray race session started'; bash"
# Split the panes and run outray
for i in "${!PORTS[@]}"; do
port="${PORTS[$i]}"
if [ "$i" -ne 0 ]; then
tmux split-window -t "$SESSION" -h
tmux select-layout -t "$SESSION" tiled
fi
tmux send-keys -t "$SESSION" "echo '[*] Running outray on port $port'; outray $port" C-m
done
tmux set-window-option -t "$SESSION" synchronize-panes off
echo "[+] tmux session '$SESSION' created"
echo "[+] Attach with: tmux attach -t $SESSION"
Running this
seeker@instance-20260106-20011$ bash kay.sh
[+] tmux session 'outray-race' created
[+] Attach with: tmux attach -t outray-race
seeker@instance-20260106-20011$ tmux attach -t outray-race
Impact
By exploiting this TOCTOU race condition in the affected component, the intended limit is bypassed and server resources is used with no extra billing charges on the user.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "outray"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22820"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-13T21:53:44Z",
"nvd_published_at": "2026-01-14T15:16:05Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nA TOCTOU race condition vulnerability allows a user to exceed the set number of active tunnels in their subscription plan.\n\n### Details\n\nAffected conponent: `apps/web/src/routes/api/tunnel/register.ts`\n- `/tunnel/register` endpoint code-:\n\n```ts\n// Check if tunnel already exists in database\n const [existingTunnel] = await db\n .select()\n .from(tunnels)\n .where(eq(tunnels.url, tunnelUrl));\n\n const isReconnection = !!existingTunnel;\n\n console.log(\n `[TUNNEL LIMIT CHECK] Org: ${organizationId}, Tunnel: ${tunnelId}`,\n );\n console.log(\n `[TUNNEL LIMIT CHECK] Is Reconnection: ${isReconnection}`,\n );\n console.log(\n `[TUNNEL LIMIT CHECK] Plan: ${currentPlan}, Limit: ${tunnelLimit}`,\n );\n\n // Check limits only for NEW tunnels (not reconnections)\n if (!isReconnection) {\n // Count active tunnels from Redis SET\n const activeCount = await redis.scard(setKey);\n console.log(\n `[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,\n );\n\n // The current tunnel is NOT yet in the online_tunnels set (added after successful registration)\n // So we check if activeCount \u003e= limit (not \u003e)\n if (activeCount \u003e= tunnelLimit) {\n console.log(\n `[TUNNEL LIMIT CHECK] REJECTED - ${activeCount} \u003e= ${tunnelLimit}`,\n );\n return json(\n {\n error: `Tunnel limit reached. The ${currentPlan} plan allows ${tunnelLimit} active tunnel${tunnelLimit \u003e 1 ? \"s\" : \"\"}.`,\n },\n { status: 403 },\n );\n }\n console.log(\n `[TUNNEL LIMIT CHECK] ALLOWED - ${activeCount} \u003c ${tunnelLimit}`,\n );\n } else {\n console.log(`[TUNNEL LIMIT CHECK] SKIPPED - Reconnection detected`);\n }\n\n if (existingTunnel) {\n // Tunnel with this URL already exists, update lastSeenAt\n await db\n .update(tunnels)\n .set({ lastSeenAt: new Date() })\n .where(eq(tunnels.id, existingTunnel.id));\n\n return json({\n success: true,\n tunnelId: existingTunnel.id,\n });\n }\n\n // Create new tunnel record\n const tunnelRecord = {\n id: randomUUID(),\n url: tunnelUrl,\n userId,\n organizationId,\n name: name || null,\n protocol,\n remotePort: remotePort || null,\n lastSeenAt: new Date(),\n createdAt: new Date(),\n updatedAt: new Date(),\n };\n\n await db.insert(tunnels).values(tunnelRecord);\n\n return json({ success: true, tunnelId: tunnelRecord.id });\n } catch (error) {\n console.error(\"Tunnel registration error:\", error);\n return json({ error: \"Internal server error\" }, { status: 500 });\n }\n```\n- It checks if the tunnel exists in the database.\n```ts\n// Check if tunnel already exists in database\n const [existingTunnel] = await db\n .select()\n .from(tunnels)\n .where(eq(tunnels.url, tunnelUrl));\n\n const isReconnection = !!existingTunnel;\n```\n\n- Limit is checked here-:\n```ts\n// Check limits only for NEW tunnels (not reconnections)\n\nif (!isReconnection) {\n\n// Count active tunnels from Redis SET\n\nconst activeCount = await redis.scard(setKey);\n\nconsole.log(\n\n`[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,\n\n);\n```\n- Redis is checked for existing tunnel to check for reconnection.\n```ts\n// Check limits only for NEW tunnels (not reconnections)\n if (!isReconnection) {\n // Count active tunnels from Redis SET\n const activeCount = await redis.scard(setKey);\n console.log(\n `[TUNNEL LIMIT CHECK] Active count in Redis: ${activeCount}`,\n );\n```\n\n- If the tunnel limit is exceeded, it pops up the tunnel limit error.\n\n```ts\nif (activeCount \u003e= tunnelLimit) {\n console.log(\n `[TUNNEL LIMIT CHECK] REJECTED - ${activeCount} \u003e= ${tunnelLimit}`,\n );\n return json(\n {\n error: `Tunnel limit reached. The ${currentPlan} plan allows ${tunnelLimit} active tunnel${tunnelLimit \u003e 1 ? \"s\" : \"\"}.`,\n },\n { status: 403 },\n );\n```\n- If the limit is not exceeded, it triggers a the `Insert` Statement without locking transactions from other request\n\n```ts\nawait db.insert(tunnels).values(tunnelRecord);\n```\n- If parallel requests are made by the `wshandler` in `/outray/outray-main/apps/tunnel/src/core/WSHandler.ts` from the command line app. A request can work on a non updated row because the `insert` row has not been triggered allowing the user to bypass the limit. It is much explained in the proof of concept. The key takeaway is db transactions should remain locked.\n\n### PoC\n\nUsing this simple bash script, the `outray` binary will be run at the same time in one `tmux` window, demonstrating the race condition and opening 4 tunnels.\n\n```bash\n#!/usr/bin/env bash\n\n# POC for Outray Tunnel Race condition\nSESSION=\"outray-race\"\nPORTS=(8090 4000 5000 6000)\n\n# Create new detached tmux session\ntmux new-session -d -s \"$SESSION\" \"echo \u0027[*] outray race session started\u0027; bash\"\n\n# Split the panes and run outray\nfor i in \"${!PORTS[@]}\"; do\n port=\"${PORTS[$i]}\"\n\n if [ \"$i\" -ne 0 ]; then\n tmux split-window -t \"$SESSION\" -h\n tmux select-layout -t \"$SESSION\" tiled\n fi\n\n tmux send-keys -t \"$SESSION\" \"echo \u0027[*] Running outray on port $port\u0027; outray $port\" C-m\ndone\n\ntmux set-window-option -t \"$SESSION\" synchronize-panes off\n\necho \"[+] tmux session \u0027$SESSION\u0027 created\"\necho \"[+] Attach with: tmux attach -t $SESSION\"\n\n```\n\nRunning this\n\n```\nseeker@instance-20260106-20011$ bash kay.sh\n[+] tmux session \u0027outray-race\u0027 created\n[+] Attach with: tmux attach -t outray-race\n\nseeker@instance-20260106-20011$ tmux attach -t outray-race\n```\n\n\u003cimg width=\"1909\" height=\"1021\" alt=\"image\" src=\"https://github.com/user-attachments/assets/c234cc94-fc25-4542-abdf-815332493a85\" /\u003e\n\n\n\u003cimg width=\"1907\" height=\"936\" alt=\"image\" src=\"https://github.com/user-attachments/assets/1c302d7f-1ca6-46af-ab72-60fd01cdfded\" /\u003e\n\n### Impact\n\nBy exploiting this TOCTOU race condition in the affected component, the intended limit is bypassed and server resources is used with no extra billing charges on the user.",
"id": "GHSA-3pqc-836w-jgr7",
"modified": "2026-01-21T16:17:07Z",
"published": "2026-01-13T21:53:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/akinloluwami/outray/security/advisories/GHSA-3pqc-836w-jgr7"
},
{
"type": "WEB",
"url": "https://github.com/outray-tunnel/outray/security/advisories/GHSA-3pqc-836w-jgr7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22820"
},
{
"type": "WEB",
"url": "https://github.com/outray-tunnel/outray/commit/08c61495761349e7fd2965229c3faa8d7b1c1581"
},
{
"type": "PACKAGE",
"url": "https://github.com/akinloluwami/outray"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Outray cli is vulnerable to race conditions in tunnels creation"
}
GHSA-3PXQ-F3CP-JMXP
Vulnerability from github – Published: 2026-03-03 21:20 – Updated: 2026-03-18 01:31Summary
A path-confinement bypass in browser output handling allowed writes outside intended roots in openclaw versions up to and including 2026.3.1.
The fix unifies root-bound, file-descriptor-verified write semantics and canonical path-boundary validation across browser output and related install/skills write paths.
Affected Packages / Versions
- Package:
openclaw(npm) - Latest published npm version at triage time:
2026.3.1 - Affected range:
<= 2026.3.1 - Patched release:
2026.3.2(released)
Fix Commit(s)
104d32bb64cdf19d5e77f70553a511a2ae90ad1c
Technical Notes
- Browser output writes now use root-bound, fd/inode-verified commit flow.
- Install + skills path checks now share canonical in-base validation to reduce drift and close equivalent escape surfaces.
- Added regression coverage for symlink-rebind and root-bound source-path write behavior.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.1"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22180"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-59"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-03T21:20:01Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nA path-confinement bypass in browser output handling allowed writes outside intended roots in `openclaw` versions up to and including `2026.3.1`.\n\nThe fix unifies root-bound, file-descriptor-verified write semantics and canonical path-boundary validation across browser output and related install/skills write paths.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version at triage time: `2026.3.1`\n- Affected range: `\u003c= 2026.3.1`\n- Patched release: `2026.3.2` (released)\n\n### Fix Commit(s)\n- `104d32bb64cdf19d5e77f70553a511a2ae90ad1c`\n\n### Technical Notes\n- Browser output writes now use root-bound, fd/inode-verified commit flow.\n- Install + skills path checks now share canonical in-base validation to reduce drift and close equivalent escape surfaces.\n- Added regression coverage for symlink-rebind and root-bound source-path write behavior.",
"id": "GHSA-3pxq-f3cp-jmxp",
"modified": "2026-03-18T01:31:51Z",
"published": "2026-03-03T21:20:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3pxq-f3cp-jmxp"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/104d32bb64cdf19d5e77f70553a511a2ae90ad1c"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenClaw: Unified root-bound write hardening for browser output and related path-boundary flows"
}
GHSA-3Q2P-72CJ-682C
Vulnerability from github – Published: 2026-06-12 21:07 – Updated: 2026-06-12 21:07Summary
This is similar vulnrability of CVE-2026-0035, which was fixed in Android MediaProvider with high severity. In the original Java issue, MediaStore.createWriteRequest() accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.
filebrowser/filebrowser has the analogous issue in Go. POST /api/share/<path> accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through GET /api/public/dl/<hash>.
Details
The vulnerable create path is:
http/share.gosharePostHandler()- route:
POST /api/share/<path>
sharePostHandler() only checks that the caller is authenticated and has share/download permissions. It then builds a share.Link directly from r.URL.Path and saves it:
s = &share.Link{
Path: r.URL.Path,
Hash: str,
Expire: expire,
UserID: d.user.ID,
PasswordHash: string(hash),
Token: token,
}
if err := d.store.Share.Save(s); err != nil {
return http.StatusInternalServerError, err
}
There is no Stat, Exists, or equivalent check before the public share record is committed.
The vulnerable consume path is:
http/public.gowithHashFile()- routes:
GET /api/public/share/<hash>,GET /api/public/dl/<hash>
Each public request loads the saved share by hash and then resolves link.Path against the owner's current filesystem state:
file, err := files.NewFileInfo(&files.FileOptions{
Fs: d.user.Fs,
Path: link.Path,
...
})
This means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.
PoC
The PoC below starts from external HTTP input only.
- Authenticate to File Browser.
- Confirm
/future4.txtdoes not exist. - Create a public share for
/future4.txtanyway. - Confirm the public share returns
404. - Upload a file to
/future4.txt. - Reuse the same public share URL and read the file content.
Reproduction commands:
TOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \
-H 'Content-Type: application/json' \
-d '{"username":"admin","password":"Password123!"}')
curl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \
-H "X-Auth: $TOKEN" \
-H 'Content-Type: application/json' \
-d '{}'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
curl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \
-H "X-Auth: $TOKEN" \
--data-binary 'fourth-secret'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
Impact
An authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.
Reference
Original CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.6"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54096"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-668"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T21:07:55Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nThis is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.\n\n`filebrowser/filebrowser` has the analogous issue in Go. `POST /api/share/\u003cpath\u003e` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/\u003chash\u003e`.\n\n### Details\nThe vulnerable create path is:\n\n- `http/share.go`\n- `sharePostHandler()`\n- route: `POST /api/share/\u003cpath\u003e`\n\n`sharePostHandler()` only checks that the caller is authenticated and has share/download permissions. It then builds a `share.Link` directly from `r.URL.Path` and saves it:\n\n```go\ns = \u0026share.Link{\n Path: r.URL.Path,\n Hash: str,\n Expire: expire,\n UserID: d.user.ID,\n PasswordHash: string(hash),\n Token: token,\n}\n\nif err := d.store.Share.Save(s); err != nil {\n return http.StatusInternalServerError, err\n}\n```\n\nThere is no `Stat`, `Exists`, or equivalent check before the public share record is committed.\n\nThe vulnerable consume path is:\n\n- `http/public.go`\n- `withHashFile()`\n- routes: `GET /api/public/share/\u003chash\u003e`, `GET /api/public/dl/\u003chash\u003e`\n\nEach public request loads the saved share by hash and then resolves `link.Path` against the owner\u0027s current filesystem state:\n\n```go\nfile, err := files.NewFileInfo(\u0026files.FileOptions{\n Fs: d.user.Fs,\n Path: link.Path,\n ...\n})\n```\n\nThis means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.\n\n\n### PoC\nThe PoC below starts from external HTTP input only.\n\n1. Authenticate to File Browser.\n2. Confirm `/future4.txt` does not exist.\n3. Create a public share for `/future4.txt` anyway.\n4. Confirm the public share returns `404`.\n5. Upload a file to `/future4.txt`.\n6. Reuse the same public share URL and read the file content.\n\nReproduction commands:\n\n```bash\nTOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"admin\",\"password\":\"Password123!\"}\u0027)\n\ncurl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{}\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n\ncurl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n --data-binary \u0027fourth-secret\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n```\n\n\n### Impact\nAn authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.\n\n### Reference\n\nOriginal CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035",
"id": "GHSA-3q2p-72cj-682c",
"modified": "2026-06-12T21:07:55Z",
"published": "2026-06-12T21:07:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3q2p-72cj-682c"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/166583db632e088e9f0adce30aec43bb9d9019f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path"
}
GHSA-3R66-J4HR-JMXJ
Vulnerability from github – Published: 2026-06-09 15:32 – Updated: 2026-06-09 15:32A vulnerability in the quarantine and restore workflow of the X-VPN macOS website versions 77.0 through 77.5 allow a local attacker to leverage a race condition and symlink manipulation to achieve privileged file corruption.
{
"affected": [],
"aliases": [
"CVE-2026-2638"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-09T13:16:35Z",
"severity": "HIGH"
},
"details": "A vulnerability in the quarantine and restore workflow of the X-VPN macOS website versions 77.0 through 77.5 allow a local attacker to leverage a race condition and symlink manipulation to achieve privileged file corruption.",
"id": "GHSA-3r66-j4hr-jmxj",
"modified": "2026-06-09T15:32:17Z",
"published": "2026-06-09T15:32:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2638"
},
{
"type": "WEB",
"url": "https://fluidattacks.com/es/advisories/soad"
},
{
"type": "WEB",
"url": "https://xvpn.io"
},
{
"type": "WEB",
"url": "https://xvpn.io/download/vpn-mac"
},
{
"type": "WEB",
"url": "https://xvpn.io/resources/statement-local-privilege-escalation-vulnerability"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/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"
}
]
}
GHSA-3V2R-C9X3-5FGR
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37In the Linux kernel, the following vulnerability has been resolved:
sched/psi: fix race between file release and pressure write
A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1].
Consider the following scenario involving execution on two separate CPUs:
CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv
The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered.
Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write().
And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point after the live kn lock has been successfully acquired.
In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition:
CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================
kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex
cgroup_pressure_write()
cgroup_kn_lock_live(cgroup.pressure)
cgroup_file_show(memory.pressure, false)
kernfs_show(false)
kernfs_drain_open_files()
cgroup_file_release(of)
kfree(ctx)
of->priv = NULL
cgroup_kn_unlock()
... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference
Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.
Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.
[1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---
{
"affected": [],
"aliases": [
"CVE-2026-52991"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:09Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: fix race between file release and pressure write\n\nA potential race condition exists between pressure write and cgroup file\nrelease regarding the priv member of struct kernfs_open_file, which\ntriggers the uaf reported in [1].\n\nConsider the following scenario involving execution on two separate CPUs:\n\n CPU0\t\t\t\t\tCPU1\n ====\t\t\t\t\t====\n\t\t\t\t\tvfs_rmdir()\n\t\t\t\t\tkernfs_iop_rmdir()\n\t\t\t\t\tcgroup_rmdir()\n\t\t\t\t\tcgroup_kn_lock_live()\n\t\t\t\t\tcgroup_destroy_locked()\n\t\t\t\t\tcgroup_addrm_files()\n\t\t\t\t\tcgroup_rm_file()\n\t\t\t\t\tkernfs_remove_by_name()\n\t\t\t\t\tkernfs_remove_by_name_ns()\n vfs_write()\t\t\t\t__kernfs_remove()\n new_sync_write()\t\t\tkernfs_drain()\n kernfs_fop_write_iter()\t\tkernfs_drain_open_files()\n cgroup_file_write()\t\t\tkernfs_release_file()\n pressure_write()\t\t\tcgroup_file_release()\n ctx = of-\u003epriv;\n\t\t\t\t\tkfree(ctx);\n \t\t\t\t\tof-\u003epriv = NULL;\n\t\t\t\t\tcgroup_kn_unlock()\n cgroup_kn_lock_live()\n cgroup_get(cgrp)\n cgroup_kn_unlock()\n if (ctx-\u003epsi.trigger) // here, trigger uaf for ctx, that is of-\u003epriv\n\nThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards\nthe memory deallocation of of-\u003epriv performed within cgroup_file_release().\nHowever, the operations involving of-\u003epriv executed within pressure_write()\nare not entirely covered by the protection of cgroup_mutex. Consequently,\nif the code in pressure_write(), specifically the section handling the\nctx variable executes after cgroup_file_release() has completed, a uaf\nvulnerability involving of-\u003epriv is triggered.\n\nTherefore, the issue can be resolved by extending the scope of the\ncgroup_mutex lock within pressure_write() to encompass all code paths\ninvolving of-\u003epriv, thereby properly synchronizing the race condition\noccurring between cgroup_file_release() and pressure_write().\n\nAnd, if an live kn lock can be successfully acquired while executing\nthe pressure write operation, it indicates that the cgroup deletion\nprocess has not yet reached its final stage; consequently, the priv\npointer within open_file cannot be NULL. Therefore, the operation to\nretrieve the ctx value must be moved to a point *after* the live kn\nlock has been successfully acquired.\n\nIn another situation, specifically after entering cgroup_kn_lock_live()\nbut before acquiring cgroup_mutex, there exists a different class of\nrace condition:\n\nCPU0: write memory.pressure CPU1: write cgroup.pressure=0\n===========================\t\t =============================\n\nkernfs_fop_write_iter()\n kernfs_get_active_of(of)\n pressure_write()\n cgroup_kn_lock_live(memory.pressure)\n cgroup_tryget(cgrp)\n kernfs_break_active_protection(kn)\n ... blocks on cgroup_mutex\n\n \t cgroup_pressure_write()\n \t cgroup_kn_lock_live(cgroup.pressure)\n \t cgroup_file_show(memory.pressure, false)\n \t kernfs_show(false)\n \t kernfs_drain_open_files()\n \t cgroup_file_release(of)\n \t kfree(ctx)\n \t of-\u003epriv = NULL\n \t cgroup_kn_unlock()\n\n ... acquires cgroup_mutex\n ctx = of-\u003epriv; // may now be NULL\n if (ctx-\u003epsi.trigger) // NULL dereference\n\nConsequently, there is a possibility that of-\u003epriv is NULL, the pressure\nwrite needs to check for this.\n\nNow that the scope of the cgroup_mutex has been expanded, the original\nexplicit cgroup_get/put operations are no longer necessary, this is\nbecause acquiring/releasing the live kn lock inherently executes a\ncgroup get/put operation.\n\n[1]\nBUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\nCall Trace:\n pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\n cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43\n---truncated---",
"id": "GHSA-3v2r-c9x3-5fgr",
"modified": "2026-06-30T03:37:13Z",
"published": "2026-06-24T18:32:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52991"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-52991"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492403"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/03dc070fa0fc3cb4068693f468ccd5f8a7e58282"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b98009f16d8a5fb4a8ff9a193f5735515c38fa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d4352c0709bfd38c752fccbde7fd72a82ac78f23"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52991.json"
}
],
"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-3W2F-J9R3-9H89
Vulnerability from github – Published: 2023-07-11 18:31 – Updated: 2025-10-22 00:32Microsoft Outlook Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-35311"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-11T18:15:17Z",
"severity": "HIGH"
},
"details": "Microsoft Outlook Security Feature Bypass Vulnerability",
"id": "GHSA-3w2f-j9r3-9h89",
"modified": "2025-10-22T00:32:44Z",
"published": "2023-07-11T18:31:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35311"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-35311"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-35311"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.