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-CMRH-WVQ6-WM9R
Vulnerability from github – Published: 2026-05-08 16:59 – Updated: 2026-05-13 13:35Summary
Authenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (N8N_API_URL), and per-request URLs supplied via the x-n8n-url header in multi-tenant HTTP mode.
Impact
A caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel.
- Multi-tenant HTTP deployments where tenants share an
AUTH_TOKEN: any tenant with valid credentials can reach the operator's cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials. - Single-tenant deployments: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM's tool calls can read internal services from the n8n-mcp host.
- Stdio deployments are reachable via the same prompt-injection path.
Patched Versions
Fixed in n8n-mcp@2.50.2.
Note for operators: The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If N8N_API_URL points at http://localhost:5678 (n8n on the same host) or an RFC1918 address (n8n on the same private network), set WEBHOOK_SECURITY_MODE=moderate (allows localhost, still blocks RFC1918 and cloud metadata) or WEBHOOK_SECURITY_MODE=permissive (allows RFC1918 too — only safe on a trusted private network). Default strict is correct for deployments where n8n is reachable at a public hostname.
Workarounds
For deployments that cannot upgrade immediately:
- Restrict network egress from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (
169.254.169.254,169.254.170.2,100.100.100.200,192.0.0.192, and the GCPmetadata.google.internalresolved IP) and any RFC1918 networks the server does not legitimately need to reach. - Run in stdio mode instead of HTTP if the multi-tenant surface is not needed (no shared
AUTH_TOKENto compromise). - Disable workflow management tools via
DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflowif the deployment does not need them.
Credit
Reported by @fg0x0.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "n8n-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "2.18.7"
},
{
"fixed": "2.50.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44694"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T16:59:17Z",
"nvd_published_at": "2026-05-08T20:16:31Z",
"severity": "HIGH"
},
"details": "### Summary\n\nAuthenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (`N8N_API_URL`), and per-request URLs supplied via the `x-n8n-url` header in multi-tenant HTTP mode.\n\n### Impact\n\nA caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel.\n\n- **Multi-tenant HTTP deployments** where tenants share an `AUTH_TOKEN`: any tenant with valid credentials can reach the operator\u0027s cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials.\n- **Single-tenant deployments**: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM\u0027s tool calls can read internal services from the n8n-mcp host.\n- **Stdio deployments** are reachable via the same prompt-injection path.\n\n### Patched Versions\n\nFixed in `n8n-mcp@2.50.2`.\n\n**Note for operators:** The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If `N8N_API_URL` points at `http://localhost:5678` (n8n on the same host) or an RFC1918 address (n8n on the same private network), set `WEBHOOK_SECURITY_MODE=moderate` (allows localhost, still blocks RFC1918 and cloud metadata) or `WEBHOOK_SECURITY_MODE=permissive` (allows RFC1918 too \u2014 only safe on a trusted private network). Default `strict` is correct for deployments where n8n is reachable at a public hostname.\n\n### Workarounds\n\nFor deployments that cannot upgrade immediately:\n\n1. **Restrict network egress** from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (`169.254.169.254`, `169.254.170.2`, `100.100.100.200`, `192.0.0.192`, and the GCP `metadata.google.internal` resolved IP) and any RFC1918 networks the server does not legitimately need to reach.\n2. **Run in stdio mode** instead of HTTP if the multi-tenant surface is not needed (no shared `AUTH_TOKEN` to compromise).\n3. **Disable workflow management tools** via `DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow` if the deployment does not need them.\n\n### Credit\n\nReported by [@fg0x0](https://github.com/fg0x0).",
"id": "GHSA-cmrh-wvq6-wm9r",
"modified": "2026-05-13T13:35:05Z",
"published": "2026-05-08T16:59:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-cmrh-wvq6-wm9r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44694"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/commit/bcaba839409d470abeb4a6ad9b361b553a1098eb"
},
{
"type": "PACKAGE",
"url": "https://github.com/czlonkowski/n8n-mcp"
},
{
"type": "WEB",
"url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.50.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:L/VA:L/SC:H/SI:L/SA:L",
"type": "CVSS_V4"
}
],
"summary": "n8n-mcp webhook and API client paths has an authenticated SSRF"
}
GHSA-CP3Q-Q6MX-W79J
Vulnerability from github – Published: 2023-08-02 15:30 – Updated: 2024-01-12 09:30External service lookups for a number of protocols were vulnerable to a time-of-check/time-of-use (TOCTOU) weakness, involving the JDK DNS cache. Attackers that were timing DNS cache expiry correctly were able to inject configuration that would bypass existing network deny-lists. Attackers could exploit this weakness to discover the existence of restricted network infrastructure and service availability. Improvements were made to include deny-lists not only during the check of the provided connection data, but also during use. No publicly available exploits are known.
{
"affected": [],
"aliases": [
"CVE-2023-26438"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-02T13:15:10Z",
"severity": "LOW"
},
"details": "External service lookups for a number of protocols were vulnerable to a time-of-check/time-of-use (TOCTOU) weakness, involving the JDK DNS cache. Attackers that were timing DNS cache expiry correctly were able to inject configuration that would bypass existing network deny-lists. Attackers could exploit this weakness to discover the existence of restricted network infrastructure and service availability. Improvements were made to include deny-lists not only during the check of the provided connection data, but also during use. No publicly available exploits are known.\n\n",
"id": "GHSA-cp3q-q6mx-w79j",
"modified": "2024-01-12T09:30:27Z",
"published": "2023-08-02T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26438"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/appsuite/security/advisories/csaf/2023/oxas-adv-2023-0003.json"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/security/advisories/csaf/oxas-adv-2023-0003.json"
},
{
"type": "WEB",
"url": "https://software.open-xchange.com/products/appsuite/doc/Release_Notes_for_Patch_Release_6230_7.10.6_2023-05-02.pdf"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/173943/OX-App-Suite-SSRF-SQL-Injection-Cross-Site-Scripting.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2023/Aug/8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-CP85-4PFJ-F5QQ
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53An elevation of privilege vulnerability exists when Windows improperly handles calls to Advanced Local Procedure Call (ALPC), aka "Windows ALPC Elevation of Privilege Vulnerability." This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers.
{
"affected": [],
"aliases": [
"CVE-2018-8584"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-14T01:29:00Z",
"severity": "HIGH"
},
"details": "An elevation of privilege vulnerability exists when Windows improperly handles calls to Advanced Local Procedure Call (ALPC), aka \"Windows ALPC Elevation of Privilege Vulnerability.\" This affects Windows Server 2016, Windows 10, Windows Server 2019, Windows 10 Servers.",
"id": "GHSA-cp85-4pfj-f5qq",
"modified": "2022-05-13T01:53:46Z",
"published": "2022-05-13T01:53:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8584"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8584"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/46104"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105808"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1042119"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CQPW-MC9F-6GF5
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32A race condition was addressed with additional validation. This issue is fixed in macOS Catalina 10.15.6. A malicious application may be able to execute arbitrary code with kernel privileges.
{
"affected": [],
"aliases": [
"CVE-2020-9990"
],
"database_specific": {
"cwe_ids": [
"CWE-362",
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-22T19:15:00Z",
"severity": "HIGH"
},
"details": "A race condition was addressed with additional validation. This issue is fixed in macOS Catalina 10.15.6. A malicious application may be able to execute arbitrary code with kernel privileges.",
"id": "GHSA-cqpw-mc9f-6gf5",
"modified": "2022-05-24T17:32:09Z",
"published": "2022-05-24T17:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9990"
},
{
"type": "WEB",
"url": "https://support.apple.com/kb/HT211289"
}
],
"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-CRRX-464G-PWJ8
Vulnerability from github – Published: 2026-07-14 18:32 – Updated: 2026-07-14 18:32Time-of-check time-of-use (toctou) race condition in Microsoft Defender allows an authorized attacker to elevate privileges locally.
{
"affected": [],
"aliases": [
"CVE-2026-50658"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-14T18:17:59Z",
"severity": "HIGH"
},
"details": "Time-of-check time-of-use (toctou) race condition in Microsoft Defender allows an authorized attacker to elevate privileges locally.",
"id": "GHSA-crrx-464g-pwj8",
"modified": "2026-07-14T18:32:29Z",
"published": "2026-07-14T18:32:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50658"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50658"
}
],
"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-CRV2-V9HJ-XFFJ
Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-08-12 18:31Time-of-check time-of-use (toctou) race condition in Windows NTFS allows an unauthorized attacker to disclose information locally.
{
"affected": [],
"aliases": [
"CVE-2025-50158"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T18:15:32Z",
"severity": "HIGH"
},
"details": "Time-of-check time-of-use (toctou) race condition in Windows NTFS allows an unauthorized attacker to disclose information locally.",
"id": "GHSA-crv2-v9hj-xffj",
"modified": "2025-08-12T18:31:30Z",
"published": "2025-08-12T18:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-50158"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-50158"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-CW28-63X4-37C3
Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-05-04 21:55Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-89r3-6x4j-v7wf. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.3.31 contains a callback origin mutation vulnerability in Plivo voice-call replay that allows attackers to mutate in-process callback origin before replay rejection. Attackers with captured valid callbacks for live calls can exploit this to manipulate callback origins during the replay process.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.3.31"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T21:55:01Z",
"nvd_published_at": "2026-04-23T22:16:39Z",
"severity": "MODERATE"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-89r3-6x4j-v7wf. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.31 contains a callback origin mutation vulnerability in Plivo voice-call replay that allows attackers to mutate in-process callback origin before replay rejection. Attackers with captured valid callbacks for live calls can exploit this to manipulate callback origins during the replay process.",
"id": "GHSA-cw28-63x4-37c3",
"modified": "2026-05-04T21:55:01Z",
"published": "2026-04-24T00:31:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-89r3-6x4j-v7wf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41337"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/efe9183f9d2fd5e01c8068fa01f4a07a58a63c0b"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-callback-origin-mutation-in-plivo-voice-call-replay"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/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: Voice-call Plivo replay mutates in-process callback origin before replay rejection",
"withdrawn": "2026-05-04T21:55:01Z"
}
GHSA-CX44-8C8J-5RR2
Vulnerability from github – Published: 2024-11-09 12:30 – Updated: 2025-09-26 18:31In the Linux kernel, the following vulnerability has been resolved:
fork: do not invoke uffd on fork if error occurs
Patch series "fork: do not expose incomplete mm on fork".
During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete.
In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated.
As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state.
We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred.
This patch (of 2):
Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork.
This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd().
This is problematic, because the virtual address space may not yet be correctly initialised if an error arose.
The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent.
We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete().
We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts.
Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.
{
"affected": [],
"aliases": [
"CVE-2024-50220"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-09T11:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfork: do not invoke uffd on fork if error occurs\n\nPatch series \"fork: do not expose incomplete mm on fork\".\n\nDuring fork we may place the virtual memory address space into an\ninconsistent state before the fork operation is complete.\n\nIn addition, we may encounter an error during the fork operation that\nindicates that the virtual memory address space is invalidated.\n\nAs a result, we should not be exposing it in any way to external machinery\nthat might interact with the mm or VMAs, machinery that is not designed to\ndeal with incomplete state.\n\nWe specifically update the fork logic to defer khugepaged and ksm to the\nend of the operation and only to be invoked if no error arose, and\ndisallow uffd from observing fork events should an error have occurred.\n\n\nThis patch (of 2):\n\nCurrently on fork we expose the virtual address space of a process to\nuserland unconditionally if uffd is registered in VMAs, regardless of\nwhether an error arose in the fork.\n\nThis is performed in dup_userfaultfd_complete() which is invoked\nunconditionally, and performs two duties - invoking registered handlers\nfor the UFFD_EVENT_FORK event via dup_fctx(), and clearing down\nuserfaultfd_fork_ctx objects established in dup_userfaultfd().\n\nThis is problematic, because the virtual address space may not yet be\ncorrectly initialised if an error arose.\n\nThe change in commit d24062914837 (\"fork: use __mt_dup() to duplicate\nmaple tree in dup_mmap()\") makes this more pertinent as we may be in a\nstate where entries in the maple tree are not yet consistent.\n\nWe address this by, on fork error, ensuring that we roll back state that\nwe would otherwise expect to clean up through the event being handled by\nuserland and perform the memory freeing duty otherwise performed by\ndup_userfaultfd_complete().\n\nWe do this by implementing a new function, dup_userfaultfd_fail(), which\nperforms the same loop, only decrementing reference counts.\n\nNote that we perform mmgrab() on the parent and child mm\u0027s, however\nuserfaultfd_ctx_put() will mmdrop() this once the reference count drops to\nzero, so we will avoid memory leaks correctly here.",
"id": "GHSA-cx44-8c8j-5rr2",
"modified": "2025-09-26T18:31:18Z",
"published": "2024-11-09T12:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50220"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b"
},
{
"type": "WEB",
"url": "https://project-zero.issues.chromium.org/issues/373391951"
}
],
"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-CX83-HXFR-M85V
Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
xsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()
The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xsk_skb_metadata(), csum_start and csum_offset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path.
Fix this by reading csum_start and csum_offset into local variables once, then using the local copies for both validation and assignment.
Note that other metadata fields (flags, launch_time) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.
{
"affected": [],
"aliases": [
"CVE-2026-53250"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T09:16:42Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: cache csum_start/csum_offset to fix TOCTOU in xsk_skb_metadata()\n\nThe TX metadata area resides in the UMEM buffer which is memory-mapped\nand concurrently writable by userspace. In xsk_skb_metadata(),\ncsum_start and csum_offset are read from shared memory for bounds\nvalidation, then read again for skb assignment. A malicious userspace\napplication can race to overwrite these values between the two reads,\nbypassing the bounds check and causing out-of-bounds memory access\nduring checksum computation in the transmit path.\n\nFix this by reading csum_start and csum_offset into local variables\nonce, then using the local copies for both validation and assignment.\n\nNote that other metadata fields (flags, launch_time) and the cached\ncsum fields may be mutually inconsistent due to concurrent userspace\nwrites, but this is benign: the only security-critical invariant is\nthat each field\u0027s validated value is the same one used, which local\ncaching guarantees.",
"id": "GHSA-cx83-hxfr-m85v",
"modified": "2026-06-28T09:31:46Z",
"published": "2026-06-25T09:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53250"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0dfe05b938435892875e07771170051346412df9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22ba97ea9cc1f63a0d0244fae38057ed452b6ac7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfdfd2706d5fb2cd496a1506e680daf979309c8b"
}
],
"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-CXWJ-7754-PQ73
Vulnerability from github – Published: 2022-11-15 12:00 – Updated: 2022-11-18 00:30DMA transactions which are targeted at input buffers used for the NvmExpressDxe software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the NvmExpressDxe driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. This issue was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022055
{
"affected": [],
"aliases": [
"CVE-2022-33985"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-15T00:15:00Z",
"severity": "HIGH"
},
"details": "DMA transactions which are targeted at input buffers used for the NvmExpressDxe software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the NvmExpressDxe driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel\u0027s iSTARE group. This issue was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022055",
"id": "GHSA-cxwj-7754-pq73",
"modified": "2022-11-18T00:30:20Z",
"published": "2022-11-15T12:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33985"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge/SA-2022055"
}
],
"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"
}
]
}
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.