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.
1284 vulnerabilities reference this CWE, most recent first.
GHSA-9GH9-HWPR-RVQQ
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-05-08 01:24A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the mkfifo utility of uutils coreutils. The utility creates a FIFO and then performs a path-based chmod to set permissions. A local attacker with write access to the parent directory can swap the newly created FIFO for a symbolic link between these two operations. This redirects the chmod call to an arbitrary file, potentially enabling privilege escalation if the utility is run with elevated privileges.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "coreutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35352"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T17:09:11Z",
"nvd_published_at": "2026-04-22T17:16:37Z",
"severity": "HIGH"
},
"details": "A Time-of-Check to Time-of-Use (TOCTOU) race condition exists in the mkfifo utility of uutils coreutils. The utility creates a FIFO and then performs a path-based chmod to set permissions. A local attacker with write access to the parent directory can swap the newly created FIFO for a symbolic link between these two operations. This redirects the chmod call to an arbitrary file, potentially enabling privilege escalation if the utility is run with elevated privileges.",
"id": "GHSA-9gh9-hwpr-rvqq",
"modified": "2026-05-08T01:24:58Z",
"published": "2026-04-22T18:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35352"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/issues/10020"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/04/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/04/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/05/04/6"
}
],
"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"
}
],
"summary": "uutils coreutils has a Time-of-Check to Time-of-Use (TOCTOU) race condition"
}
GHSA-9HGC-G3W5-67CM
Vulnerability from github – Published: 2026-08-14 19:49 – Updated: 2026-08-14 19:49Summary
The /admin/gateways/test endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.
Details
validate_gateway_test_url() in mcpgateway/common/validators.py (lines 1527–1710) calls socket.getaddrinfo() on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client as the original hostname string, not as the validated IP address.
The HTTP client (httpx, via ResilientHttpClient) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:
- The validated IP address is never passed to the HTTP client.
- Only the original hostname is forwarded, triggering a second independent lookup.
- No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is implemented.
The configuration options ssrf_blocked_networks (default: enabled, covers 169.254.169.254/32, link-local ranges, etc.) and ssrf_dns_fail_closed (default: True) apply exclusively at validation time. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.
Two independent acknowledgements in the source code
Location 1 — mcpgateway/common/validators.py, lines 1537–1543 (function docstring of validate_gateway_test_url):
"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but the HTTP client will re-resolve DNS at connection time. An attacker controlling DNS can return a public IP during validation and a private IP during connection (DNS rebinding). True mitigation requires pinning the validated IP into the connection (custom resolver/transport, or IP allowlist check at connect callback). This is tracked as a known limitation for future improvement."
Location 2 — mcpgateway/admin.py, lines 14025–14029 (call site comment):
"TODO(ICACF-15): DNS rebinding risk — allowlist and SSRF checks resolve DNS, but the actual ResilientHttpClient request resolves DNS a third time. An attacker-controlled DNS server could return a public IP during validation and a private IP during the actual request. Consider pinning the resolved IP for outbound requests (custom transport) or caching DNS resolution across validation and request phases."
The existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.
Prerequisites
MCPGATEWAY_ADMIN_API_ENABLED=true(not the default; must be explicitly enabled by an operator).- The attacker holds a credential with explicit
gateways.readpermission assigned via a database role.
Regarding prerequisite 2: the endpoint is decorated with @require_permission("gateways.read", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) — a virtual identity with no database record — is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.
Proof of Concept
Setup
cd /opt/mcp-cf-test
MCPGATEWAY_ADMIN_API_ENABLED=true \
JWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \
uvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 &
sleep 5
Step 1 — Obtain a token for an account with database role assignment
The exploit requires a credential for a user who exists in the database with a role carrying gateways.read (e.g., platform_admin, which holds the * wildcard). Register a user through the Admin UI or API and assign the platform_admin role, then generate a JWT:
import datetime, jwt, uuid
SECRET = "my-test-key-but-now-longer-than-32-bytes"
EMAIL = "admin@example.com" # must have platform_admin role in DB
now = datetime.datetime.now(datetime.timezone.utc)
payload = {
"sub": EMAIL,
"aud": "mcpgateway-api",
"iss": "mcpgateway",
"jti": str(uuid.uuid4()),
"iat": now,
"exp": now + datetime.timedelta(hours=1),
}
print(jwt.encode(payload, SECRET, algorithm="HS256"), end="")
TOKEN=$(python3 /tmp/gen_token.py)
Step 2 — Baseline control: direct private IP is rejected
Submitting a literal private IP is blocked unconditionally before any DNS resolution occurs:
curl -s -w "\nHTTP %{http_code}\n" \
-X POST http://127.0.0.1:8000/admin/gateways/test \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"url": "http://169.254.169.254/latest/meta-data/", "method": "GET"}'
# Expected: HTTP 400 — "Invalid gateway URL"
Step 3 — DNS rebinding attack
- Attacker controls DNS for
attacker.example.comwith TTL set to 1 second. - Initial record:
attacker.example.com → 1.2.3.4(any public IP). - Submit the request:
curl -s -w "\nHTTP %{http_code}\n" \
-X POST http://127.0.0.1:8000/admin/gateways/test \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"url": "http://attacker.example.com/latest/meta-data/", "method": "GET"}'
validate_gateway_test_url()resolvesattacker.example.com → 1.2.3.4; all SSRF checks pass.- Attacker immediately flips the DNS record:
attacker.example.com → 169.254.169.254. httpxindependently re-resolves the hostname and connects to169.254.169.254.- The gateway returns the IMDS response body to the caller.
Standard DNS rebinding infrastructure (e.g., rbndr.us) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.
Impact
Server-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from 169.254.169.254/latest/meta-data/iam/security credentials/, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.
Suggested Fix
After DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom httpx transport or resolver that binds the socket to the already-resolved address and sets the Host header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "mcp-contextforge-gateway"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53708"
],
"database_specific": {
"cwe_ids": [
"CWE-350",
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-14T19:49:14Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `/admin/gateways/test` endpoint validates submitted URLs by resolving the hostname at validation time and blocking private address ranges. The HTTP client independently re-resolves DNS at connection time with no IP binding between the two operations, creating a TOCTOU window exploitable via DNS rebinding. The source code explicitly acknowledges this limitation in two separate locations.\n\n## Details\n\n`validate_gateway_test_url()` in `mcpgateway/common/validators.py` (lines 1527\u20131710) calls `socket.getaddrinfo()` on the submitted hostname, checks whether the resolved IP falls in private, loopback, link-local, or cloud-metadata ranges (including `169.254.169.254`, `10.0.0.0/8`, `172.16.0.0/12`, and `192.168.0.0/16`), and accepts the URL if the result is clean. The validated URL is then passed to the HTTP client **as the original hostname string**, not as the validated IP address.\n\nThe HTTP client (`httpx`, via `ResilientHttpClient`) performs its own independent DNS resolution at connection time. No mechanism bridges the two resolutions:\n\n- The validated IP address is never passed to the HTTP client.\n- Only the original hostname is forwarded, triggering a second independent lookup.\n- No TTL enforcement, mandatory DNS-cache reuse, or IP-level socket binding is\n implemented.\n\nThe configuration options `ssrf_blocked_networks` (default: enabled, covers `169.254.169.254/32`, link-local ranges, etc.) and `ssrf_dns_fail_closed` (default: `True`) apply exclusively at **validation time**. They share the same TOCTOU gap because they operate on the validation-time resolution result, not on the connection-time resolution performed by the HTTP client.\n\n### Two independent acknowledgements in the source code\n\n**Location 1** \u2014 `mcpgateway/common/validators.py`, lines 1537\u20131543 (function docstring of `validate_gateway_test_url`):\n\n\u003e \"DNS TOCTOU Limitation: This validation resolves DNS at validation time, but\n\u003e the HTTP client will re-resolve DNS at connection time. An attacker controlling\n\u003e DNS can return a public IP during validation and a private IP during connection\n\u003e (DNS rebinding). True mitigation requires pinning the validated IP into the\n\u003e connection (custom resolver/transport, or IP allowlist check at connect\n\u003e callback). This is tracked as a known limitation for future improvement.\"\n\n**Location 2** \u2014 `mcpgateway/admin.py`, lines 14025\u201314029 (call site comment):\n\n\u003e \"TODO(ICACF-15): DNS rebinding risk \u2014 allowlist and SSRF checks resolve DNS,\n\u003e but the actual ResilientHttpClient request resolves DNS a third time. An\n\u003e attacker-controlled DNS server could return a public IP during validation and a\n\u003e private IP during the actual request. Consider pinning the resolved IP for\n\u003e outbound requests (custom transport) or caching DNS resolution across\n\u003e validation and request phases.\"\n\nThe existence of a named TODO ticket (ICACF-15) confirms the maintainers consider this an open, tracked defect.\n\n### Prerequisites\n\n1. `MCPGATEWAY_ADMIN_API_ENABLED=true` (not the default; must be explicitly\n enabled by an operator).\n2. The attacker holds a credential with explicit `gateways.read` permission\n assigned via a database role.\n\nRegarding prerequisite 2: the endpoint is decorated with @require_permission(\"gateways.read\", allow_admin_bypass=False). The allow_admin_bypass=False flag explicitly disables the platform-admin shortcut, meaning even a platform admin must hold an explicit database-backed role assignment that carries gateways.read. A credential produced solely via the platform-admin bootstrap bypass described in the companion advisory (GHSA-m8rv-5m6m-32ff) \u2014 a virtual identity with no database record \u2014 is rejected with HTTP 403 at this endpoint because no role lookup can succeed without a database row. An attacker who has forged a JWT via that bootstrap path does not automatically gain access to this endpoint; they still require a separately provisioned account with an appropriate role.\n\n## Proof of Concept\n\n### Setup\n\n```bash\ncd /opt/mcp-cf-test\nMCPGATEWAY_ADMIN_API_ENABLED=true \\\nJWT_SECRET_KEY=my-test-key-but-now-longer-than-32-bytes \\\nuvicorn mcpgateway.main:app --host 0.0.0.0 --port 8000 \u0026\nsleep 5\n```\n\n### Step 1 \u2014 Obtain a token for an account with database role assignment\n\nThe exploit requires a credential for a user who exists in the database with a role carrying `gateways.read` (e.g., `platform_admin`, which holds the `*` wildcard). Register a user through the Admin UI or API and assign the `platform_admin` role, then generate a JWT:\n\n```python\nimport datetime, jwt, uuid\n\nSECRET = \"my-test-key-but-now-longer-than-32-bytes\"\nEMAIL = \"admin@example.com\" # must have platform_admin role in DB\nnow = datetime.datetime.now(datetime.timezone.utc)\n\npayload = {\n \"sub\": EMAIL,\n \"aud\": \"mcpgateway-api\",\n \"iss\": \"mcpgateway\",\n \"jti\": str(uuid.uuid4()),\n \"iat\": now,\n \"exp\": now + datetime.timedelta(hours=1),\n}\nprint(jwt.encode(payload, SECRET, algorithm=\"HS256\"), end=\"\")\n```\n\n```bash\nTOKEN=$(python3 /tmp/gen_token.py)\n```\n\n### Step 2 \u2014 Baseline control: direct private IP is rejected\n\nSubmitting a literal private IP is blocked unconditionally before any DNS resolution occurs:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n -X POST http://127.0.0.1:8000/admin/gateways/test \\\n -H \"Authorization: Bearer $TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"url\": \"http://169.254.169.254/latest/meta-data/\", \"method\": \"GET\"}\u0027\n# Expected: HTTP 400 \u2014 \"Invalid gateway URL\"\n```\n\n### Step 3 \u2014 DNS rebinding attack\n\n1. Attacker controls DNS for `attacker.example.com` with TTL set to 1 second.\n2. Initial record: `attacker.example.com \u2192 1.2.3.4` (any public IP).\n3. Submit the request:\n\n```bash\ncurl -s -w \"\\nHTTP %{http_code}\\n\" \\\n -X POST http://127.0.0.1:8000/admin/gateways/test \\\n -H \"Authorization: Bearer $TOKEN\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"url\": \"http://attacker.example.com/latest/meta-data/\", \"method\": \"GET\"}\u0027\n```\n\n4. `validate_gateway_test_url()` resolves `attacker.example.com \u2192 1.2.3.4`;\n all SSRF checks pass.\n5. Attacker immediately flips the DNS record:\n `attacker.example.com \u2192 169.254.169.254`.\n6. `httpx` independently re-resolves the hostname and connects to\n `169.254.169.254`.\n7. The gateway returns the IMDS response body to the caller.\n\nStandard DNS rebinding infrastructure (e.g., `rbndr.us`) reliably achieves this window against the 1-second TTL. In cloud environments with IMDSv2 disabled or not enforced, the response contains IAM role credentials.\n\n## Impact\n\nServer-Side Request Forgery against internal services and cloud instance metadata. An attacker with a sufficiently privileged credential can probe internal network services, retrieve cloud credentials from `169.254.169.254/latest/meta-data/iam/security credentials/`, access internal APIs not exposed to the internet, or conduct port scanning of the internal network. In cloud environments where IMDSv1 is accessible, this can lead to full cloud account compromise through metadata-service credential theft.\n\n## Suggested Fix\n\nAfter DNS validation passes, pin the connection to the validated IP address rather than re-passing the hostname to the HTTP client. Implement this via a custom `httpx` transport or resolver that binds the socket to the already-resolved address and sets the `Host` header to the original hostname. Additionally, enforce a maximum DNS resolution age and refuse to connect if the elapsed time between validation and connection exceeds a configurable threshold. The codebase already tracks this requirement under TODO ICACF-15; the suggested fix closes it.",
"id": "GHSA-9hgc-g3w5-67cm",
"modified": "2026-08-14T19:49:14Z",
"published": "2026-08-14T19:49:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/IBM/mcp-context-forge/security/advisories/GHSA-9hgc-g3w5-67cm"
},
{
"type": "PACKAGE",
"url": "https://github.com/IBM/mcp-context-forge"
},
{
"type": "WEB",
"url": "https://github.com/IBM/mcp-context-forge/releases/tag/v1.0.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ContextForge: DNS TOCTOU race condition causes SSRF protection bypass (`/admin/gateways/test`)"
}
GHSA-9HHX-MWF2-VR7V
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31OpenClaw before 2026.3.31 contains a time-of-check-time-of-use vulnerability in sandbox file operations that allows attackers to bypass fd-based defenses. Attackers can exploit check-then-act patterns in apply_patch, remove, and mkdir operations to manipulate files between validation and execution.
{
"affected": [],
"aliases": [
"CVE-2026-41338"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T22:16:39Z",
"severity": "MODERATE"
},
"details": "OpenClaw before 2026.3.31 contains a time-of-check-time-of-use vulnerability in sandbox file operations that allows attackers to bypass fd-based defenses. Attackers can exploit check-then-act patterns in apply_patch, remove, and mkdir operations to manipulate files between validation and execution.",
"id": "GHSA-9hhx-mwf2-vr7v",
"modified": "2026-04-24T00:31:51Z",
"published": "2026-04-24T00:31:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rm5c-4rmf-vvhw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41338"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/32a4a47d602e0618f87b3e59f94d8c142767f860"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-time-of-check-time-of-use-toctou-vulnerability-in-sandbox-file-operations"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:P/VC:N/VI:H/VA:L/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-9J94-67JR-4CQJ
Vulnerability from github – Published: 2025-05-08 14:45 – Updated: 2025-05-09 14:34Summary
When using the Rack::Session::Pool middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.
Details
Rack session middleware prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.
Impact
When using the Rack::Session::Pool middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.
Mitigation
- Update to the latest version of
rack-session, or - Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a
logged_outflag, instead of deleting them, and check this flag on every request to prevent reuse, or - Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.
Related
This code was previously part of rack in Rack < 3, see https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g for the equivalent advisory in rack (affecting Rack < 3 only).
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack-session"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-46336"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-08T14:45:33Z",
"nvd_published_at": "2025-05-08T20:15:30Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nWhen using the `Rack::Session::Pool` middleware, simultaneous rack requests can restore a deleted rack session, which allows the unauthenticated user to occupy that session.\n\n## Details\n\n[Rack session middleware](https://github.com/rack/rack-session/blob/v2.1.0/lib/rack/session/abstract/id.rb#L271-L278) prepares the session at the beginning of request, then saves is back to the store with possible changes applied by host rack application. This way the session becomes to be a subject of race conditions in general sense over concurrent rack requests.\n\n## Impact\n\nWhen using the `Rack::Session::Pool` middleware, and provided the attacker can acquire a session cookie (already a major issue), the session may be restored if the attacker can trigger a long running request (within that same session) adjacent to the user logging out, in order to retain illicit access even after a user has attempted to logout.\n\n## Mitigation\n\n- Update to the latest version of `rack-session`, or\n- Ensure your application invalidates sessions atomically by marking them as logged out e.g., using a `logged_out` flag, instead of deleting them, and check this flag on every request to prevent reuse, or\n- Implement a custom session store that tracks session invalidation timestamps and refuses to accept session data if the session was invalidated after the request began.\n\n## Related\n\nThis code was previously part of `rack` in Rack \u003c 3, see \u003chttps://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g\u003e for the equivalent advisory in `rack` (affecting Rack \u003c 3 only).",
"id": "GHSA-9j94-67jr-4cqj",
"modified": "2025-05-09T14:34:48Z",
"published": "2025-05-08T14:45:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack-session/security/advisories/GHSA-9j94-67jr-4cqj"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-vpfw-47h7-xj4g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46336"
},
{
"type": "WEB",
"url": "https://github.com/rack/rack-session/commit/c28c4a8c1861d814e09f2ae48264ac4c40be2d3b"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack-session"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack-session/CVE-2025-46336.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Rack session gets restored after deletion"
}
GHSA-9JCM-V2GM-FPX9
Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2024-05-14 18:30 A local attacker with low privileges can perform a privilege escalation with an init script due to a TOCTOU vulnerability.
{
"affected": [],
"aliases": [
"CVE-2024-28137"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-14T16:16:42Z",
"severity": "HIGH"
},
"details": "\n\t\n\t\t\n\t\t\n\t\n\t\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\n\t\n\t\t\n\t\t\n\t\n\t\n\t\t\n\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\tA local attacker with low privileges can\u00a0perform a privilege escalation with an init script due to a TOCTOU vulnerability.\n\n\n\n\n\n\n\n\n\n\n\t\t\t\t\n\n\n\t\t\t\n\n\n\t\t\n\n\n\t\n",
"id": "GHSA-9jcm-v2gm-fpx9",
"modified": "2024-05-14T18:30:59Z",
"published": "2024-05-14T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28137"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2024-019"
}
],
"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-9JFR-2H37-X8QG
Vulnerability from github – Published: 2026-09-15 21:33 – Updated: 2026-09-16 00:31Race condition in PlatformIntegration in Google Chrome on on Mac prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-91744"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T21:16:48Z",
"severity": "MODERATE"
},
"details": "Race condition in PlatformIntegration in Google Chrome on on Mac prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: High)",
"id": "GHSA-9jfr-2h37-x8qg",
"modified": "2026-09-16T00:31:28Z",
"published": "2026-09-15T21:33:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91744"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0541751186.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/520019273"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9JHR-52W2-JGH9
Vulnerability from github – Published: 2026-08-25 21:31 – Updated: 2026-08-26 18:31Race condition in FileSystem in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-79155"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T21:18:10Z",
"severity": "HIGH"
},
"details": "Race condition in FileSystem in Google Chrome prior to 152.0.7977.65 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)",
"id": "GHSA-9jhr-52w2-jgh9",
"modified": "2026-08-26T18:31:46Z",
"published": "2026-08-25T21:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79155"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0256176589.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/522294538"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9M5F-J2G3-2FCR
Vulnerability from github – Published: 2023-06-13 18:30 – Updated: 2024-04-04 04:47Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.
{
"affected": [],
"aliases": [
"CVE-2022-31636"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-13T17:15:12Z",
"severity": "HIGH"
},
"details": "Potential time-of-check to time-of-use (TOCTOU) vulnerabilities have been identified in the BIOS for certain HP PC products, which might allow arbitrary code execution, escalation of privilege, denial of service, and information disclosure.",
"id": "GHSA-9m5f-j2g3-2fcr",
"modified": "2024-04-04T04:47:02Z",
"published": "2023-06-13T18:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31636"
},
{
"type": "WEB",
"url": "https://support.hp.com/us-en/document/ish_7149996-7150021-16/hpsbhf03814"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9MV8-62Q2-X7P7
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2024-01-04 03:30An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka 'Windows Print Spooler Elevation of Privilege Vulnerability'.
{
"affected": [],
"aliases": [
"CVE-2020-1337"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-17T19:15:00Z",
"severity": "HIGH"
},
"details": "An elevation of privilege vulnerability exists when the Windows Print Spooler service improperly allows arbitrary writing to the file system, aka \u0027Windows Print Spooler Elevation of Privilege Vulnerability\u0027.",
"id": "GHSA-9mv8-62q2-x7p7",
"modified": "2024-01-04T03:30:31Z",
"published": "2022-05-24T17:25:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1337"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1337"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160028/Microsoft-Windows-Local-Spooler-Bypass.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160993/Microsoft-Spooler-Local-Privilege-Elevation.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-9P3R-HH9G-5CMG
Vulnerability from github – Published: 2026-04-03 03:14 – Updated: 2026-04-24 21:04Summary
Sandbox escape via TOCTOU race in remote FS bridge readFile
Current Maintainer Triage
- Normalized severity: critical
- Assessment: v2026.3.28 remote sandbox reads still do path-check then separate file read, so the TOCTOU sandbox escape remains present in the latest shipped tag.
Affected Packages / Versions
- Package:
openclaw(npm) - Latest published npm version:
2026.3.31 - Vulnerable version range:
<=2026.3.28 - Patched versions:
>= 2026.3.31 - First stable tag containing the fix:
v2026.3.31
Fix Commit(s)
121870a08583033ed6a0ed73d9ffea32991252bb— 2026-03-31T09:55:51+09:00
OpenClaw thanks @AntAISecurityLab for reporting.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.3.28"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.31"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41296"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-03T03:14:16Z",
"nvd_published_at": "2026-04-21T00:16:29Z",
"severity": "CRITICAL"
},
"details": "## Summary\nSandbox escape via TOCTOU race in remote FS bridge readFile\n\n## Current Maintainer Triage\n- Normalized severity: critical\n- Assessment: v2026.3.28 remote sandbox reads still do path-check then separate file read, so the TOCTOU sandbox escape remains present in the latest shipped tag.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `121870a08583033ed6a0ed73d9ffea32991252bb` \u2014 2026-03-31T09:55:51+09:00\n\nOpenClaw thanks @AntAISecurityLab for reporting.",
"id": "GHSA-9p3r-hh9g-5cmg",
"modified": "2026-04-24T21:04:35Z",
"published": "2026-04-03T03:14:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9p3r-hh9g-5cmg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41296"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/121870a08583033ed6a0ed73d9ffea32991252bb"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-sandbox-escape-via-toctou-race-in-remote-fs-bridge-readfile"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Sandbox escape via TOCTOU race in remote FS bridge readFile"
}
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.