The Exploit Bulletin — Thursday, October 22, 2026: 4 issues require action
Thursday, October 22, 2026 — 4 issues require action. If you run none of the software below, you are done.
Affects: PHP (CVE-2026-109619) · PHP (CVE-2026-109618) · pypi/litellm · Fortinet FortiSIEM
1. Stale global state use-after-free in PHP core gives unauthenticated remote code execution (CVE-2026-109619)
REMOTE CODE EXECUTION · CRITICAL · CVSS 9.2
VulnCheck's canary sensors recorded exploitation attempts on 2026-10-21 and 2026-10-22, other firms saw attempts before the emergency 8.2.35/8.3.36/8.4.27/8.5.12 releases shipped yesterday, and public exploits exist — any internet-facing PHP host still on an older build is now exposed to code execution as the web server user.
PHP worker processes retain error, session, object and extension state that points into memory owned by a single request; when that state is not reset before the request memory is freed, the next request can touch it during early initialization, producing a use-after-free that a crafted heap layout turns into full remote code execution. One of the two flaws tracked as PHP2Shell, it affects every supported PHP branch and needs no authentication or user interaction.
Affected: PHP < 8.2.35; PHP 8.3.0 – 8.3.35; PHP 8.4.0 – 8.4.26; PHP 8.5.0 – 8.5.11
How to Test: Confirm the PHP version on every web host, container image and PHP-FPM pool against the fixed builds 8.2.35, 8.3.36, 8.4.27 and 8.5.12 — anything lower is vulnerable, including distribution packages that have not yet backported the fix. Deploy the Snort rules Talos published in the Community Ruleset for both PHP2Shell CVEs and review web server and PHP-FPM logs since 2026-10-21 for the malformed request patterns described in the ellio.tech and AWS write-ups, as well as unexpected worker crashes, out-of-memory errors or new processes spawned by the web server user, which the public exploits produce when they land or fail.
How to Patch: Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (the project's out-of-cycle security release of 2026-10-21) and rebuild any container images that bundle PHP. Where the upgrade cannot land immediately, follow the maintainers' and NCSC's guidance to take exposed PHP applications offline until patched.
Evidence: VulnCheck KEV · SecurityWeek: several firms saw exploitation attempts of CVE-2026-109618/109619 before patches shipped · Dark Reading: reports of exploitation attempts · UK NCSC alert urging immediate action · Cisco Talos analysis and Snort coverage · AWS: PHP2Shell exploitation observed in MadPot prior to disclosure, with request-level PoC
2. Out-of-memory longjmp corruption in PHP core gives unauthenticated remote code execution (CVE-2026-109618)
REMOTE CODE EXECUTION · CRITICAL · CVSS 9.2
VulnCheck's canary sensors recorded exploitation attempts on 2026-10-21 and 2026-10-22, AWS and other firms saw attempts before the emergency 8.2.35/8.3.36/8.4.27/8.5.12 releases shipped yesterday, and six public exploits are already catalogued — an unpatched internet-facing PHP host can be taken over with a single crafted request sequence.
PHP aborts a request on out-of-memory via longjmp(), but in some contexts request memory is reachable before it is fully initialized; an attacker who forces an allocation failure at that point leaves the request in an invalid state that the cleanup path then reads, and several reliable OOM strategies turn this into remote code execution. It is the second of the two PHP2Shell flaws, affects every supported PHP branch, and requires neither authentication nor user interaction.
Affected: PHP < 8.2.35; PHP 8.3.0 – 8.3.35; PHP 8.4.0 – 8.4.26; PHP 8.5.0 – 8.5.11
How to Test: Confirm the PHP version on every web host, container image and PHP-FPM pool against the fixed builds 8.2.35, 8.3.36, 8.4.27 and 8.5.12 — anything lower is vulnerable, including distribution packages that have not yet backported the fix. Deploy the Snort rules Talos published in the Community Ruleset for the PHP2Shell CVEs and review web server and PHP-FPM logs since 2026-10-21 for the request patterns in the ellio.tech and AWS write-ups, for bursts of PHP memory-exhaustion (out-of-memory) errors from a single client, and for unexpected processes spawned by the web server user.
How to Patch: Upgrade to PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (the project's out-of-cycle security release of 2026-10-21) and rebuild any container images that bundle PHP. Where the upgrade cannot land immediately, follow the maintainers' and NCSC's guidance to take exposed PHP applications offline until patched.
Evidence: VulnCheck KEV · SecurityWeek: several firms saw exploitation attempts of CVE-2026-109618/109619 before patches shipped · Dark Reading: reports of exploitation attempts · UK NCSC alert urging immediate action · Ars Technica: unconfirmed PHP2Shell exploit report before the emergency patches · AWS: PHP2Shell exploitation observed in MadPot prior to disclosure, with request-level PoC
3. LiteLLM 1.107.0 shipped a credential stealer and hourly remote-code loader on PyPI and in official Docker images
SUPPLY-CHAIN COMPROMISE · CRITICAL
Any pip install or container pull of the compromised litellm 1.107.0 release on 21 October means every secret on that host and in that CI job should already be considered stolen, and the hourly loader keeps granting fresh code execution until the machine is rebuilt.
litellm 1.107.0 was published to PyPI with malware in all seven compiled wheels and the identical payload baked into the official LiteLLM Docker images, including the latest/main-stable tags; the release was built from a lookalike Berri-AI/litellm repository, with the maintainer suspecting a leaked GitHub token in AI gateway logs. A .pth/sitecustomize hook means the stealer executes on every Python process start on the host — not only when litellm is imported — harvesting SSH keys, AWS credentials, browser passwords, shell history and AI coding-tool configs, while a daemon backdoor fetches and runs attacker code hourly. PyPI has quarantined the release and the malicious Docker images were pulled.
Affected: litellm 1.107.0 (PyPI, all seven wheels); LiteLLM official Docker images built from 1.107.0, including latest and main-stable tags
How to Test: Grep lockfiles, poetry.lock/requirements/uv.lock, pip caches and CI images for litellm==1.107.0 (pip list | grep litellm, pip download cache, image SBOMs); on suspect hosts look for cook.pth or an unexpected sitecustomize.py in site-packages, a persistent Python daemon, and hourly outbound HTTP beacons from build agents or Kubernetes nodes running LiteLLM images.
How to Mitigate: Pin and reinstall litellm 1.106.2 from a clean index, delete and re-pull LiteLLM container images by digest rather than tag, rebuild or reimage any host or runner that executed 1.107.0, then rotate SSH keys, cloud access keys, provider API keys, Git tokens and browser-stored passwords from those machines.
Evidence: The Hacker News — LiteLLM security director confirms compromise of 1.107.0, package quarantined on PyPI · StepSecurity — all seven wheels and official Docker images carry cook.pth stealer plus hourly sitecustomize loader · The Register — LiteLLM supply chain attack hoovers up passwords and secrets · The Hacker News — LiteLLM suspects GitHub token leak in AI gateway logs behind malicious release
4. Unauthenticated gRPC path traversal to arbitrary file write and RCE in Fortinet FortiSIEM (CVE-2026-106173)
PUBLIC EXPLOIT · NO ATTACKS CONFIRMED · REMOTE CODE EXECUTION · CRITICAL · CVSS 9.4
horizon3.ai published a working proof-of-concept repository and a technical deep-dive on 2026-10-20 for this unauthenticated RCE, so any FortiSIEM 7.5.0 (or older 7.x) supervisor with port 27918 reachable is now exposed to copy-paste exploitation; no attacks are confirmed.
A path traversal in FortiSIEM's phQueryMaster gRPC service (tcp port 27918) lets an unauthenticated attacker write arbitrary files with specially crafted packets, which horizon3.ai has chained to remote code execution on the appliance. No credentials or non-default configuration are needed; the exploit is a single network request sequence against the exposed port.
Affected: Fortinet FortiSIEM 7.5.0 (fixed in 7.5.1); Fortinet FortiSIEM 7.4.0 – 7.4.2; Fortinet FortiSIEM 7.3.0 – 7.3.5; Fortinet FortiSIEM 7.2.0 – 7.2.7; Fortinet FortiSIEM 7.1.0 – 7.1.9; Fortinet FortiSIEM 7.0.0 – 7.0.4; Not affected: FortiSIEM 7.6 and FortiSIEM Cloud
How to Test: Check the FortiSIEM supervisor/worker version in the admin UI or the appliance's version output: 7.5.0 and the 7.0–7.4 branches listed above are affected; 7.6 and FortiSIEM Cloud are not. Confirm from outside your network whether tcp port 27918 (the phQueryMaster gRPC service) is reachable by anything other than trusted FortiSIEM nodes. For signs of compromise, review network records for connections to port 27918 from unexpected sources, noting that horizon3.ai found no application logs that explicitly reveal exploitation and look for unexpected or recently modified files in writable locations on the appliance, since the flaw is an arbitrary file write that is then used for code execution.
How to Patch: Upgrade FortiSIEM 7.5.0 to 7.5.1 or later (FG-IR-26-180). For the affected 7.0–7.4 branches, Fortinet's advisory names no fixed build beyond the 7.5.1 line; until you can move to a fixed release, apply the vendor workaround: restrict access to tcp port 27918 so only trusted FortiSIEM components can reach it. FortiSIEM Cloud requires no action.
Evidence: horizon3ai public PoC repository for CVE-2026-106173
Read on the web · Every past edition
The Exploit Bulletin is free and daily. It publishes only what security teams must act on today — nothing else. Forward it freely.
Spot an error, or an exploit we missed? Reply here or email [email protected].
