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.
1411 vulnerabilities reference this CWE, most recent first.
GHSA-4QQW-WG6J-834R
Vulnerability from github – Published: 2026-10-03 00:31 – Updated: 2026-10-03 00:31OpenLiteSpeed before 1.9.3 contains a local privilege escalation vulnerability in admin/misc/lsup.sh that runs unverified update packages from a nobody-writable directory as root. Attackers controlling the nobody web process can replace the package in /usr/local/lsws/autoupdate/ before extraction, so its install.sh runs as root on the next update.
{
"affected": [],
"aliases": [
"CVE-2026-104474"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-03T00:16:35Z",
"severity": "MODERATE"
},
"details": "OpenLiteSpeed before 1.9.3 contains a local privilege escalation vulnerability in admin/misc/lsup.sh that runs unverified update packages from a nobody-writable directory as root. Attackers controlling the nobody web process can replace the package in /usr/local/lsws/autoupdate/ before extraction, so its install.sh runs as root on the next update.",
"id": "GHSA-4qqw-wg6j-834r",
"modified": "2026-10-03T00:31:14Z",
"published": "2026-10-03T00:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104474"
},
{
"type": "WEB",
"url": "https://github.com/litespeedtech/openlitespeed/commit/468523ce84388cea9ba6633c26517bc05b3e2bc1"
},
{
"type": "WEB",
"url": "https://github.com/litespeedtech/openlitespeed/blob/v1.9.2/dist/admin/misc/lsup.sh#L538"
},
{
"type": "WEB",
"url": "https://openlitespeed.org/release-log/version-1-9-x"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openlitespeed-before-1.9.3-local-privilege-escalation-via-lsup-sh-auto-update"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4QR2-3MPC-GRQM
Vulnerability from github – Published: 2026-08-06 12:31 – Updated: 2026-08-07 00:31A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-57818"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T12:16:27Z",
"severity": "HIGH"
},
"details": "A race condition in JCacheCodeDataProvider allows an attacker to redeem a single authorization code multiple times via concurrent requests, resulting in the issuance of multiple distinct, valid access tokens. Users are recommended to upgrade to versions 4.2.3, 4.1.8 or 3.6.12, which fix this issue.",
"id": "GHSA-4qr2-3mpc-grqm",
"modified": "2026-08-07T00:31:10Z",
"published": "2026-08-06T12:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57818"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/7q08mz8bcbosp25wok7gr537zlp15mfz"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/20"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4RRH-WMGW-CHC3
Vulnerability from github – Published: 2023-02-15 03:30 – Updated: 2023-02-23 18:31An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the IdeBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.
{
"affected": [],
"aliases": [
"CVE-2022-32478"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-15T02:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the IdeBusDxe shared buffer used by SMM and non-SMM code could cause TOCTOU race-condition issues that could lead to corruption of SMRAM and escalation of privileges. This attack can be mitigated using IOMMU protection for the ACPI runtime memory used for the command buffer. This attack can be mitigated by copying the firmware block services data to SMRAM before checking it.",
"id": "GHSA-4rrh-wmgw-chc3",
"modified": "2023-02-23T18:31:05Z",
"published": "2023-02-15T03:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32478"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge"
},
{
"type": "WEB",
"url": "https://www.insyde.com/security-pledge/SA-2023010"
}
],
"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-4V28-J6Q3-5M4R
Vulnerability from github – Published: 2026-09-10 15:10 – Updated: 2026-09-10 15:10Summary
With the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.
Preconditions
WEB_LOADER_ENGINE=playwright. This is not the default, and deployments on the default web loader are unaffected.- A reachable Playwright browser, either local or via
PLAYWRIGHT_WS_URL. - Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.
- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.
- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.
Impact
An authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.
Because the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.
Fix
Fixed in 0.11.1 by commit 27402ff21 (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.
Root cause
Affected component: SafePlaywrightURLLoader in backend/open_webui/retrieval/web/utils.py, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.
The address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright's request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.
Proof of concept
Reproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.
Credits
- @baeseungwon1010 — identified that the address check and the browser's own resolution are two separate lookups, so the check cannot constrain where the browser connects.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.6"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87996"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T15:10:12Z",
"nvd_published_at": "2026-09-09T22:18:47Z",
"severity": "HIGH"
},
"details": "## Summary\nWith the Playwright web loader enabled, Open WebUI checks the address behind a user-submitted URL before allowing the request, then handed the request to the browser to perform. The browser resolved the hostname a second time, on its own, and that answer was never checked. An attacker who controls the authoritative DNS for a hostname they submit can answer the first lookup with a public address and the second with an internal one, so the browser connects to an address the check exists to block. The connection-layer pinning that protects the other fetch paths could not apply here, because the request ran inside the browser rather than through our own HTTP clients.\n\n## Preconditions\n- `WEB_LOADER_ENGINE=playwright`. This is not the default, and deployments on the default web loader are unaffected.\n- A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`.\n- Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required.\n- Control of the authoritative DNS for a hostname the attacker submits, serving a short TTL and alternating answers. No timing race is needed, because the two lookups are separate queries the attacker answers differently.\n- Internal services the browser process can actually reach. A deployment whose browser has no route to internal addresses loses nothing here.\n\n## Impact\nAn authenticated user can make the server read HTTP responses from addresses only it can reach: cloud instance metadata, loopback-bound admin APIs, and internal services on the same network. The response body is fulfilled back into the page, and the loader returns that page as the document, so the content lands in the web-search or ingestion result the user receives. On a cloud host with IMDSv1 reachable, that is enough to take instance IAM credentials.\n\nBecause the intercepted request forwards the original method and headers, a page the attacker controls can also drive requests that need a header or a non-GET method, which covers the header-gated metadata endpoints. This is a read primitive; no modification of Open WebUI data and no availability impact was demonstrated. Deployments on the default web loader are not affected at all.\n\n## Fix\nFixed in 0.11.1 by commit `27402ff21` (#28634). The interceptor no longer asks the browser to perform the request. It issues the request from the SSRF-safe HTTP client instead, which resolves the hostname once and connects to that same validated address, re-validates every redirect hop, and then fulfils the browser with the response it received. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.\n\n## Root cause\nAffected component: `SafePlaywrightURLLoader` in `backend/open_webui/retrieval/web/utils.py`, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine.\n\nThe address check and the connection were performed by two different resolvers in two different processes. Validation resolved the hostname in Python and inspected the result, then the request was handed to the browser, which resolved the name again and connected to whatever it got. Playwright\u0027s request-fetch API offers no way to pin a connection to an already-validated address, so the fix that had been applied to the other fetch paths, resolving once and connecting to that same address, could not reach this one. The check was therefore an opinion about an earlier lookup rather than a constraint on the connection that followed.\n\n## Proof of concept\nReproduced against the real implementation: the validation and interception code was taken unmodified, with only the module-level configuration constants stubbed at their documented defaults, and driven against a real Chromium instance inside an unprivileged network namespace with an authoritative DNS server answering the first lookup public and the second internal. Instance metadata and a loopback service were both reached, with the response body returned through the page. A second run showed an attacker-controlled page driving the header-gated metadata sequence to completion. The path from the HTTP endpoint to the loader was traced in source rather than driven end to end.\n\n## Credits\n- **@baeseungwon1010** \u2014 identified that the address check and the browser\u0027s own resolution are two separate lookups, so the check cannot constrain where the browser connects.",
"id": "GHSA-4v28-j6q3-5m4r",
"modified": "2026-09-10T15:10:12Z",
"published": "2026-09-10T15:10:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-4v28-j6q3-5m4r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87996"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/28634"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/27402ff210bfa253445720920dfb86b15a00327b"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: SSRF into internal services via DNS rebinding in the Playwright web loader"
}
GHSA-4VPV-7RCQ-X7HW
Vulnerability from github – Published: 2023-05-17 00:30 – Updated: 2024-04-04 04:12Videostream macOS app 0.5.0 and 0.4.3 has a Race Condition. The Updater privileged script attempts to update Videostream every 5 hours.
{
"affected": [],
"aliases": [
"CVE-2023-25394"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-17T00:15:08Z",
"severity": "HIGH"
},
"details": "Videostream macOS app 0.5.0 and 0.4.3 has a Race Condition. The Updater privileged script attempts to update Videostream every 5 hours.",
"id": "GHSA-4vpv-7rcq-x7hw",
"modified": "2024-04-04T04:12:32Z",
"published": "2023-05-17T00:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25394"
},
{
"type": "WEB",
"url": "https://danrevah.github.io/2023/05/03/CVE-2023-25394-VideoStream-LPE"
},
{
"type": "WEB",
"url": "https://getvideostream.com"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/757109"
}
],
"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-4W49-GWV8-FPJG
Vulnerability from github – Published: 2026-10-08 21:57 – Updated: 2026-10-08 21:57Summary
PraisonAI's Async Jobs API enables its API-key middleware only when PRAISONAI_JOBS_API_KEY is set, so by default every endpoint is unauthenticated. An unauthenticated POST /api/v1/runs accepts an attacker-controlled webhook_url; on job completion the server POSTs the job payload to it via httpx. The webhook_url has an SSRF validator (gethostbyname + private-IP check), but it validates at request time while httpx re-resolves at connection time — a DNS-rebinding TOCTOU that reaches internal services. Runtime-confirmed as an unauthenticated, blind SSRF (the internal canary received the POST; the internal response is not returned to the attacker). Severity Medium.
Details
Affected component
- Package:
praisonai4.6.63. Files:src/praisonai/praisonai/jobs/server.py,jobs/router.py,jobs/executor.py,jobs/models.py.
Vulnerable code / root cause
Path:
src/praisonai/praisonai/jobs/server.py
Function:
create_app
Snippet:
jobs_api_key = os.environ.get("PRAISONAI_JOBS_API_KEY")
# ...
if jobs_api_key:
app.add_middleware(JobsAPIKeyMiddleware) # auth ONLY when env var is set
Issue: with the env var unset (default), no auth middleware is added → all endpoints unauthenticated. Default bind is 127.0.0.1.
Path:
src/praisonai/praisonai/jobs/router.py
Function:
submit_job
Snippet:
@router.post("", response_model=JobSubmitResponse, status_code=202)
async def submit_job(request, response, body: JobSubmitRequest, ...):
# no auth dependency; body.webhook_url is attacker-controlled
job = Job(prompt=body.prompt, webhook_url=body.webhook_url, ...)
await executor.submit(job)
Issue: attacker-controlled webhook_url flows into the job with no authentication on the endpoint.
Path:
src/praisonai/praisonai/jobs/models.py (validator) and src/praisonai/praisonai/jobs/executor.py (sink)
Function:
validate_webhook_url → _send_webhook
Snippet:
# models.py validate_webhook_url (CHECK time)
ip = socket.gethostbyname(hostname)
if ipaddress.ip_address(ip).is_private or ...:
raise ValueError("Webhook URL resolves to a private or restricted network address")
# executor.py _send_webhook (CONNECT time, re-resolves, no pinning)
async with httpx.AsyncClient(timeout=30.0) as client:
response = await client.post(job.webhook_url, json=payload, ...)
Issue: the validator resolves the hostname at validation time but does not pin the IP for the httpx.post connection → DNS rebinding (independent resolution at check vs connect) bypasses it and reaches internal services.
Attack flow
- Operator runs the Jobs API without
PRAISONAI_JOBS_API_KEY(default → unauth). - Attacker
POST /api/v1/runswithwebhook_url= a rebinding domain. - The validator(s) see a public IP (pass); on completion
httpx.postre-resolves to an internal IP and connects → SSRF to internal.
Why existing protection is bypassed
Auth is opt-in (only when the env var is set). The webhook_url validator resolves at check time but does not pin the IP for the connection → DNS-rebinding TOCTOU. (Correction to an earlier static note: the guard exists but is bypassable.)
Security boundary
Unauthenticated network peer → server-side request to internal services (Scope: Changed). Default bind 127.0.0.1 limits remote reach unless the operator binds non-loopback.
Proof of Concept
Environment
Real Jobs API (python -m praisonai.jobs.server, no API key) in a local runtime (127.0.0.1:18085), resolver pointed at the controlled rebinding DNS, internal canary Docker-internal only. Runnable assets: PraisonAI-Runtime-Repro\runtime-files\ (docker-compose.jobs.yml).
Steps to reproduce
PRAI-04-01-Jobs-Submit-NoAuth:POST /api/v1/runs {"prompt":"hello"}→202(no auth).PRAI-04-02-Jobs-Webhook-SSRF-Blind:POST /api/v1/runs {"prompt":"hello","webhook_url":"http://rebind.lab:8081/secret"}→202.
Expected result
Unauthenticated job submission should be rejected; the webhook SSRF guard should prevent reaching internal services regardless of DNS timing.
Impact
Unauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.
Suggested remediation
- Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway.
- For
webhook_url: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.77"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonai"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.78"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-60091"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306",
"CWE-367",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T21:57:57Z",
"nvd_published_at": "2026-07-15T14:18:35Z",
"severity": "HIGH"
},
"details": "## Summary\n\nPraisonAI\u0027s Async Jobs API enables its API-key middleware **only when `PRAISONAI_JOBS_API_KEY` is set**, so by default every endpoint is unauthenticated. An unauthenticated `POST /api/v1/runs` accepts an attacker-controlled `webhook_url`; on job completion the server POSTs the job payload to it via `httpx`. The `webhook_url` has an SSRF validator (`gethostbyname` + private-IP check), but it validates at request time while `httpx` re-resolves at connection time \u2014 a DNS-rebinding TOCTOU that reaches internal services. Runtime-confirmed as an **unauthenticated, blind** SSRF (the internal canary received the POST; the internal response is not returned to the attacker). Severity Medium.\n\n## Details\n\n### Affected component\n- Package: `praisonai` 4.6.63. Files: `src/praisonai/praisonai/jobs/server.py`, `jobs/router.py`, `jobs/executor.py`, `jobs/models.py`.\n\n### Vulnerable code / root cause\n\nPath:\n`src/praisonai/praisonai/jobs/server.py`\n\nFunction:\n`create_app`\n\nSnippet:\n```python\njobs_api_key = os.environ.get(\"PRAISONAI_JOBS_API_KEY\")\n# ...\nif jobs_api_key:\n app.add_middleware(JobsAPIKeyMiddleware) # auth ONLY when env var is set\n```\nIssue: with the env var unset (default), no auth middleware is added \u2192 all endpoints unauthenticated. Default bind is `127.0.0.1`.\n\nPath:\n`src/praisonai/praisonai/jobs/router.py`\n\nFunction:\n`submit_job`\n\nSnippet:\n```python\n@router.post(\"\", response_model=JobSubmitResponse, status_code=202)\nasync def submit_job(request, response, body: JobSubmitRequest, ...):\n # no auth dependency; body.webhook_url is attacker-controlled\n job = Job(prompt=body.prompt, webhook_url=body.webhook_url, ...)\n await executor.submit(job)\n```\nIssue: attacker-controlled `webhook_url` flows into the job with no authentication on the endpoint.\n\nPath:\n`src/praisonai/praisonai/jobs/models.py` (validator) and `src/praisonai/praisonai/jobs/executor.py` (sink)\n\nFunction:\n`validate_webhook_url` \u2192 `_send_webhook`\n\nSnippet:\n```python\n# models.py validate_webhook_url (CHECK time)\nip = socket.gethostbyname(hostname)\nif ipaddress.ip_address(ip).is_private or ...:\n raise ValueError(\"Webhook URL resolves to a private or restricted network address\")\n\n# executor.py _send_webhook (CONNECT time, re-resolves, no pinning)\nasync with httpx.AsyncClient(timeout=30.0) as client:\n response = await client.post(job.webhook_url, json=payload, ...)\n```\nIssue: the validator resolves the hostname at validation time but does not pin the IP for the `httpx.post` connection \u2192 DNS rebinding (independent resolution at check vs connect) bypasses it and reaches internal services.\n\n### Attack flow\n1. Operator runs the Jobs API without `PRAISONAI_JOBS_API_KEY` (default \u2192 unauth).\n2. Attacker `POST /api/v1/runs` with `webhook_url` = a rebinding domain.\n3. The validator(s) see a public IP (pass); on completion `httpx.post` re-resolves to an internal IP and connects \u2192 SSRF to internal.\n\n### Why existing protection is bypassed\nAuth is opt-in (only when the env var is set). The `webhook_url` validator resolves at check time but does not pin the IP for the connection \u2192 DNS-rebinding TOCTOU. (Correction to an earlier static note: the guard exists but is bypassable.)\n\n### Security boundary\nUnauthenticated network peer \u2192 server-side request to internal services (Scope: Changed). Default bind `127.0.0.1` limits remote reach unless the operator binds non-loopback.\n\n## Proof of Concept\n\n### Environment\nReal Jobs API (`python -m praisonai.jobs.server`, no API key) in a local runtime (`127.0.0.1:18085`), resolver pointed at the controlled rebinding DNS, internal canary Docker-internal only. Runnable assets: `PraisonAI-Runtime-Repro\\runtime-files\\` (`docker-compose.jobs.yml`).\n\n### Steps to reproduce\n1. `PRAI-04-01-Jobs-Submit-NoAuth`: `POST /api/v1/runs {\"prompt\":\"hello\"}` \u2192 `202` (no auth).\n2. `PRAI-04-02-Jobs-Webhook-SSRF-Blind`: `POST /api/v1/runs {\"prompt\":\"hello\",\"webhook_url\":\"http://rebind.lab:8081/secret\"}` \u2192 `202`.\n\n### Expected result\nUnauthenticated job submission should be rejected; the webhook SSRF guard should prevent reaching internal services regardless of DNS timing.\n\n## Impact\nUnauthenticated job submission (LLM cost abuse); SSRF to internal services (blind, DNS-rebinding); exfiltration of the job result to an attacker-controlled webhook.\n\n## Suggested remediation\n- Authenticate the Jobs API by default (auto-generate a token / fail closed when binding non-loopback), like the gateway.\n- For `webhook_url`: resolve once, reject private/loopback/CGNAT/metadata, then pin and connect to the validated IP; disable redirects.",
"id": "GHSA-4w49-gwv8-fpjg",
"modified": "2026-10-08T21:57:57Z",
"published": "2026-10-08T21:57:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4w49-gwv8-fpjg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60091"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62175"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/praisonai-before-unauthenticated-ssrf-via-webhook-url"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "PraisonAI: Jobs API is unauthenticated by default and allows attacker-controlled webhook SSRF"
}
GHSA-4W64-3HFC-PGQC
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-04-28 21:36In the Linux kernel, the following vulnerability has been resolved:
smb: client: make use of smbdirect_socket.recv_io.credits.available
The logic off managing recv credits by counting posted recv_io and granted credits is racy.
That's because the peer might already consumed a credit, but between receiving the incoming recv at the hardware and processing the completion in the 'recv_done' functions we likely have a window where we grant credits, which don't really exist.
So we better have a decicated counter for the available credits, which will be incremented when we posted new recv buffers and drained when we grant the credits to the peer.
{
"affected": [],
"aliases": [
"CVE-2026-31535"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: make use of smbdirect_socket.recv_io.credits.available\n\nThe logic off managing recv credits by counting posted recv_io and\ngranted credits is racy.\n\nThat\u0027s because the peer might already consumed a credit,\nbut between receiving the incoming recv at the hardware\nand processing the completion in the \u0027recv_done\u0027 functions\nwe likely have a window where we grant credits, which\ndon\u0027t really exist.\n\nSo we better have a decicated counter for the\navailable credits, which will be incremented\nwhen we posted new recv buffers and drained when\nwe grant the credits to the peer.",
"id": "GHSA-4w64-3hfc-pgqc",
"modified": "2026-04-28T21:36:01Z",
"published": "2026-04-24T15:32:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31535"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9911b1ed187a770a43950bf51f340ad4b7beecba"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be8845ad5d6558703d20567d8702155598325db8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f664e6e8a81103cb45c8802a9bc7499e0902c458"
}
],
"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-4WR8-65Q4-XG7F
Vulnerability from github – Published: 2026-09-15 21:33 – Updated: 2026-09-16 00:31Race condition in Network in Google Chrome prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High)
{
"affected": [],
"aliases": [
"CVE-2026-91708"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T21:16:43Z",
"severity": "LOW"
},
"details": "Race condition in Network in Google Chrome prior to 153.0.8010.47 allowed a remote attacker who had compromised the renderer process to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High)",
"id": "GHSA-4wr8-65q4-xg7f",
"modified": "2026-09-16T00:31:27Z",
"published": "2026-09-15T21:33:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91708"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0541751186.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/553115724"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4WRP-79M8-9M9P
Vulnerability from github – Published: 2026-04-22 18:31 – Updated: 2026-04-30 17:54A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the split utility of uutils coreutils. The program attempts to prevent data loss by checking for identity between input and output files using their file paths before initiating the split operation. However, the utility subsequently opens the output file with truncation after this path-based validation is complete. A local attacker with write access to the directory can exploit this race window by manipulating mutable path components (e.g., swapping a path with a symbolic link). This can cause split to truncate and write to an unintended target file, potentially including the input file itself or other sensitive files accessible to the process, leading to permanent data loss.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "coreutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35374"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-30T17:54:59Z",
"nvd_published_at": "2026-04-22T17:16:42Z",
"severity": "MODERATE"
},
"details": "A Time-of-Check to Time-of-Use (TOCTOU) vulnerability exists in the split utility of uutils coreutils. The program attempts to prevent data loss by checking for identity between input and output files using their file paths before initiating the split operation. However, the utility subsequently opens the output file with truncation after this path-based validation is complete. A local attacker with write access to the directory can exploit this race window by manipulating mutable path components (e.g., swapping a path with a symbolic link). This can cause split to truncate and write to an unintended target file, potentially including the input file itself or other sensitive files accessible to the process, leading to permanent data loss.",
"id": "GHSA-4wrp-79m8-9m9p",
"modified": "2026-04-30T17:54:59Z",
"published": "2026-04-22T18:31:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35374"
},
{
"type": "WEB",
"url": "https://github.com/uutils/coreutils/pull/11401"
},
{
"type": "PACKAGE",
"url": "https://github.com/uutils/coreutils"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "uutils coreutils has a Time-of-check Time-of-use (TOCTOU) Race Condition"
}
GHSA-4X27-7F5C-RG8P
Vulnerability from github – Published: 2023-12-13 03:31 – Updated: 2023-12-13 03:31A TOCTOU race condition in Samsung Mobile Processor Exynos 9820, Exynos 980, Exynos 1080, Exynos 2100, Exynos 2200, Exynos 1280, and Exynos 1380 can cause unexpected termination of a system.
{
"affected": [],
"aliases": [
"CVE-2023-42483"
],
"database_specific": {
"cwe_ids": [
"CWE-367"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-13T01:15:07Z",
"severity": "MODERATE"
},
"details": "A TOCTOU race condition in Samsung Mobile Processor Exynos 9820, Exynos 980, Exynos 1080, Exynos 2100, Exynos 2200, Exynos 1280, and Exynos 1380 can cause unexpected termination of a system.",
"id": "GHSA-4x27-7f5c-rg8p",
"modified": "2023-12-13T03:31:55Z",
"published": "2023-12-13T03:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-42483"
},
{
"type": "WEB",
"url": "https://semiconductor.samsung.com/support/quality-support/product-security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
Mitigation
When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
Mitigation
Limit the interleaving of operations on files from multiple processes.
Mitigation
If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
Mitigation
Recheck the resource after the use call to verify that the action was taken appropriately.
Mitigation
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Mitigation
Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.
CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions
This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.