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.
1215 vulnerabilities reference this CWE, most recent first.
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"
}
]
}
GHSA-F2WX-XJFW-XJV6
Vulnerability from github – Published: 2023-07-17 18:21 – Updated: 2023-07-17 18:21Summary
https://github.com/advisories/GHSA-mc8h-8q98-g5hr https://github.com/XAMPPRocky/remove_dir_all/commit/7247a8b6ee59fc99bbb69ca6b3ca4bfd8c809ead
tempfile v0.4.26 ships with affected remove_dir_all v0.5.3 and so blocks my deployment of v12 to openSUSE distribution because it imposes a clean cargo audit
Updating tempfile is warranted
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.0.0"
},
"package": {
"ecosystem": "crates.io",
"name": "topgrade"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-17T18:21:58Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\nhttps://github.com/advisories/GHSA-mc8h-8q98-g5hr\nhttps://github.com/XAMPPRocky/remove_dir_all/commit/7247a8b6ee59fc99bbb69ca6b3ca4bfd8c809ead\n\n`tempfile` v0.4.26 ships with affected `remove_dir_all` v0.5.3 and so blocks my deployment of v12 to openSUSE distribution because it imposes a clean `cargo audit`\n\nUpdating `tempfile` is warranted",
"id": "GHSA-f2wx-xjfw-xjv6",
"modified": "2023-07-17T18:21:58Z",
"published": "2023-07-17T18:21:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/topgrade-rs/topgrade/security/advisories/GHSA-f2wx-xjfw-xjv6"
},
{
"type": "WEB",
"url": "https://github.com/XAMPPRocky/remove_dir_all/commit/7247a8b6ee59fc99bbb69ca6b3ca4bfd8c809ead"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-mc8h-8q98-g5hr"
},
{
"type": "PACKAGE",
"url": "https://github.com/topgrade-rs/topgrade"
},
{
"type": "WEB",
"url": "https://github.com/topgrade-rs/topgrade/releases/tag/v12.0.0"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "topgrade Time-of-check Time-of-use (TOCTOU) Race Condition in remove_dir_all"
}
GHSA-F3QQ-49M6-RW8F
Vulnerability from github – Published: 2026-08-18 20:51 – Updated: 2026-08-18 20:51Summary
The SSRF mitigation added for GHSA-54vg-pfh7-jq95 (_validate_revocation_url() in lemur
/certificates/verify.py) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification.
Affected version
Tested against main (the commit that introduced _validate_revocation_url). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in main. Please map the affected range to whichever release will first contain _validate_revocation_url.
Bypass 1 — HTTP redirect (deterministic)
The guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target:
# lemur/certificates/verify.py:174
response = requests.get(point, timeout=(3.05, 6))
The attacker hosts the CRL URL on a public host they control (passes the guard); that host returns 302 Location: http://169.254.169.254/.... requests follows it to the internal target the guard never inspected.
Bypass 2 — DNS rebinding / TOCTOU (probabilistic)
The guard resolves once during validation; the fetch re-resolves independently:
# lemur/certificates/verify.py:51
addr = ipaddress.ip_address(socket.gethostbyname(hostname))
A low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (openssl ocsp -url <url>, verify.py:90-99).
Relationship to GHSA-54vg-pfh7-jq95
Incomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory's remediation text anticipated ("pins the resolved IP") but the code does not implement.
Affected endpoint
POST /api/1/certificates/upload (operator role) → verify_string → crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).
PoC
- Generate a cert with
crlDistributionPoints = URI:http://attacker.example/crl. - That host returns
302 Location: http://169.254.169.254/latest/meta-data/...(bypass 1), or use a low-TTL rebinding name (bypass 2). - Upload via
POST /api/1/certificates/uploadas an operator user. - Trigger
lemur certificate check_revocation. - Observe the request reach the internal address (
tcpdump -nni any host 169.254.169.254).
Impact
Blind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded — reachability/side-effects, not response exfiltration.
Remediation
allow_redirects=Falseon CRL fetches (or re-validate every redirect hop).- Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.
- Reject names with any internal A/AAAA record.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-70667"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-18T20:51:12Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\nThe SSRF mitigation added for GHSA-54vg-pfh7-jq95 (`_validate_revocation_url()` in `lemur\n/certificates/verify.py`) can be bypassed. An operator-role user who uploads a certificate with attacker-controlled CRL/OCSP extensions can still make Lemur reach internal destinations (RFC1918, loopback, link-local 169.254.169.254) during verification.\n\n## Affected version\nTested against `main` (the commit that introduced `_validate_revocation_url`). The 1.9.2 release predates that guard and is vulnerable to the original SSRF (GHSA-54vg-pfh7-jq95) directly; this bypass applies to the unreleased mitigation in `main`. Please map the affected range to whichever release will first contain `_validate_revocation_url`.\n\n## Bypass 1 \u2014 HTTP redirect (deterministic)\nThe guard validates only the URL in the certificate; the CRL fetch then follows redirects without re-validating the target:\n```python\n# lemur/certificates/verify.py:174\nresponse = requests.get(point, timeout=(3.05, 6)) \n```\nThe attacker hosts the CRL URL on a public host they control (passes the guard); that host returns `302 Location: http://169.254.169.254/...`. `requests` follows it to the internal target the guard never inspected.\n\n## Bypass 2 \u2014 DNS rebinding / TOCTOU (probabilistic)\nThe guard resolves once during validation; the fetch re-resolves independently:\n```python\n# lemur/certificates/verify.py:51\naddr = ipaddress.ip_address(socket.gethostbyname(hostname))\n```\n\nA low-TTL attacker name that answers a public IP at check time and an internal IP at fetch time passes the guard but is fetched internally. Same gap affects the OCSP path (`openssl ocsp -url \u003curl\u003e`, verify.py:90-99).\n\n## Relationship to GHSA-54vg-pfh7-jq95\nIncomplete-fix of that mitigation, not a duplicate. Bypass 1 is not mentioned there; bypass 2 is the rebinding gap that advisory\u0027s remediation text anticipated (\"pins the resolved IP\") but the code does not implement.\n\n## Affected endpoint\n`POST /api/1/certificates/upload` (operator role) \u2192 verify_string \u2192 crl_verify / ocsp_verify. Triggered when verification runs (e.g. the check_revocation task).\n\n## PoC\n1. Generate a cert with `crlDistributionPoints = URI:http://attacker.example/crl`.\n2. That host returns `302 Location: http://169.254.169.254/latest/meta-data/...` (bypass 1), or use a low-TTL rebinding name (bypass 2).\n3. Upload via `POST /api/1/certificates/upload` as an operator user.\n4. Trigger `lemur certificate check_revocation`.\n5. Observe the request reach the internal address (`tcpdump -nni any host 169.254.169.254`).\n\n\u003cimg width=\"1140\" height=\"277\" alt=\"poc-1\" src=\"https://github.com/user-attachments/assets/f27b9584-b33a-4b9c-b812-8c60302e1892\" /\u003e\n\n## Impact\nBlind SSRF from the Lemur host: reach internal services and instance metadata (169.254.169.254 without IMDSv2). Response is parsed as a CRL and discarded \u2014 reachability/side-effects, not response exfiltration.\n\n## Remediation\n- `allow_redirects=False` on CRL fetches (or re-validate every redirect hop).\n- Resolve once, pin the IP, connect to the pinned address; route the OCSP URL through the same check.\n- Reject names with any internal A/AAAA record.",
"id": "GHSA-f3qq-49m6-rw8f",
"modified": "2026-08-18T20:51:13Z",
"published": "2026-08-18T20:51:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-f3qq-49m6-rw8f"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/commit/ed504a830f38a83825b1570302e9f38d6553938a"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Lemur: SSRF protection in certificate revocation checking bypassable via HTTP redirects and DNS rebinding (incomplete fix for GHSA-54vg-pfh7-jq95)"
}
GHSA-F3WP-GX52-Q6G2
Vulnerability from github – Published: 2024-10-11 18:32 – Updated: 2024-10-11 18:32A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the AgentD process of Juniper Networks Junos OS allows an attacker who is already causing impact to established sessions which generates counter changes picked up by the AgentD process during telemetry polling, to move the AgentD process into a state where AgentD attempts to reap an already destroyed sensor. This reaping attempt then leads to memory corruption causing the FPC to crash which is a Denial of Service (DoS).
The FPC will recover automatically without user intervention after the crash. This issue affects Junos OS:
- All versions before 21.4R3-S9
- From 22.2 before 22.2R3-S5,
- From 22.3 before 22.3R3-S4,
- From 22.4 before 22.4R3-S3,
- From 23.2 before 23.2R2-S2,
- From 23.4 before 23.4R2.
This issue does not affect Junos OS Evolved.
{
"affected": [],
"aliases": [
"CVE-2024-47494"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T16:15:09Z",
"severity": "HIGH"
},
"details": "A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the AgentD process of Juniper Networks Junos OS allows an attacker who is already causing impact to established sessions which generates counter changes picked up by the AgentD process during telemetry polling, to move the AgentD process into a state where AgentD attempts to reap an already destroyed sensor. This reaping attempt then leads to memory corruption causing the FPC to crash which is a Denial of Service (DoS).\n\n\n\n\n\nThe FPC will recover automatically without user intervention after the crash.\nThis issue affects Junos OS:\u00a0\n\n * All versions before\u00a021.4R3-S9\n * From 22.2 before 22.2R3-S5,\n * From 22.3 before 22.3R3-S4,\n * From 22.4 before 22.4R3-S3,\n * From 23.2 before 23.2R2-S2,\n * From 23.4 before 23.4R2.\n\n\nThis issue does not affect Junos OS Evolved.",
"id": "GHSA-f3wp-gx52-q6g2",
"modified": "2024-10-11T18:32:49Z",
"published": "2024-10-11T18:32:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47494"
},
{
"type": "WEB",
"url": "https://supportportal.juniper.net/JSA88121"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:N/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:Y/R:A/V:X/RE:L/U:Green",
"type": "CVSS_V4"
}
]
}
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.