Two Critical PHP Vulnerabilities Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35: Patch Now

PHP has released fixes for two critical vulnerabilities that can allow unauthenticated remote code execution (RCE) on servers that run PHP to serve web requests. PHP rates both CVSS v4.0 9.2 (Critical). The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. PHP's GitHub security advisories were published at 13:34 UTC (16:34 Cyprus time), ahead of the scheduled 14:00 UTC release time.

PHP's security advisory says "all PHP installations serving web requests" are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk "highest for mod_php, with a demonstrated exploit where an unauthenticated request can trigger the attack before any application code runs." PHP says "There are no complete mitigations, updating is the only safe choice."

PHP powers many websites and web applications, including content management systems, e-commerce platforms and custom web services (BleepingComputer), so it is very likely to be somewhere in your vendors' stacks.

Technical Information

PHP describes the two flaws as follows (php.net security advisory and GitHub advisories):

• CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat the invalid data as valid. CWEs listed by PHP: CWE-416, CWE-755, CWE-824, CWE-1325, CWE-1419.
• CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state (a use-after-free). Same CWE list.

Both have the CVSS v4.0 vector AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N (score 9.2) from PHP as CNA. For CVE-2026-109618, PHP says complete remote code execution "was validated over HTTP against mod_php", and that source analysis supports PHP-FPM as susceptible, "though no complete FPM exploit has been demonstrated". For CVE-2026-109619, PHP says "Session lifecycle RCE was validated against mod_php and FPM"; it adds that the FPM path "depends on a suitable application operation" (GHSA-6wmf-4rv5-p3rp). This advisory does not cover how to exploit the flaws.

PHP's CVE records credit Ryan at Calif.io, Wiz and OpenAI with reporting or finding the flaws, and PHP developers Arnaud Le Blanc, Ilija Tovilo, Jakub Zelenka and Nora Dossche with the fix.

Timeline (UTC):

• 20 Oct 2026: PHP posts an advance notice on php.net: one release, two critical vulnerabilities, both CVSS v4.0 9.2, scheduled for 21 October at 14:00 UTC. CERT-EU publishes Security Advisory 2026-018 the same day, naming both CVE IDs. BleepingComputer and watchTowr report that details leaked before the planned disclosure.
• 21 Oct 2026, before the release: Cloudflare CTO Dane Knecht says Cloudflare is "seeing early attacks emerging" and has deployed stopgap WAF rules (quoted by Tenable). Cloudflare has not published details of these attacks. Tenable says code claiming to exploit the flaws is circulating publicly but that it has not verified any of it works.
• 21 Oct 2026, 13:34: PHP publishes the two GitHub security advisories.
• 21 Oct 2026, 13:48 and 13:54: PHP, as CNA, publishes the CVE-2026-109618 and CVE-2026-109619 records on cve.org.
• 21 Oct 2026: PHP announces PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on php.net, each "a security release fixing two critical vulnerabilities (CVE-2026-109618, CVE-2026-109619)". PHP's releases feed and announcements date the releases 21 October; PHP's ChangeLog lists them under 22 October, the original disclosure date.
• 21 Oct 2026, 14:17: NVD receives both CVE records (status "Received").

CVE / KEV status (checked 21 Oct 2026, 17:29 Cyprus time): Both CVEs are published on cve.org by PHP. NVD lists both as "Received" and shows only PHP's CNA score (CVSS v4.0 9.2, Critical). NVD has not published its own score. Neither CVE is in CISA's KEV catalog (catalog version 2026.10.20, released 20 Oct 2026).

Affected Product Versions

• PHP 8.1 and older: PHP says these branches "no longer receive updates from the PHP project". Some distributions and LTS vendors provide backported fixes. PHP's security team also "provided minimal source-backports for PHP 7.4, PHP 8.0, and PHP 8.1 to help people building from source or without access to an LTS vendor". These are source branches in PHP's GitHub repository, linked from PHP's advisory, not official releases. PHP has not said whether versions older than 7.4 are affected. Before the release, CERT-EU said the flaws "could affect all PHP versions from PHP 5 onwards". PHP's CVE records list only the supported 8.2 to 8.5 branches.
• Distribution and vendor packages: PHP says Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
• PHP also notes that PHP 8.2 reaches end of life on 31 December 2026.

Workaround and Mitigation

1. Update now. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (PHP security advisory, downloads), or install your distribution's or vendor's patched package. Restart PHP workers (PHP-FPM pools, Apache) so the fixed binaries are loaded (Rescana guidance). Prioritise internet-facing PHP applications, starting with mod_php deployments, which PHP rates as highest risk. (PHP rates the risk highest for mod_php, but do not defer PHP-FPM: PHP says it validated remote code execution against FPM for CVE-2026-109619.)
2. Inventory PHP everywhere. Look beyond your web servers: include PHP runtimes bundled inside applications, container images, hosting control panels, and vendor appliances or virtual appliances that ship their own PHP. Record the version and who maintains each one. (Rescana guidance.)
3. Unsupported branches. For PHP 8.1 and older, PHP says to contact your distribution or LTS vendor for backported fixes, or upgrade to a supported version (PHP security advisory). PHP's source backports for 7.4, 8.0 and 8.1 are a fallback for people who build from source.
4. If you cannot update immediately. These steps are only for systems that cannot be patched right away. PHP says its temporary measures "reduce exposure to specific attack paths but do not make an installation safe" (PHP security advisory). For CVE-2026-109618, PHP's measures include setting memory_limit=-1 "preferably in a way applications can't override", a low post_max_size, and request-size limits at the web server or proxy. PHP says an underlying allocation failure "can still reach the vulnerable path". For CVE-2026-109619, PHP says to set session.upload_progress.enabled=0 (and on PHP 8.5, fatal_error_backtraces=0) in php.ini, an FPM pool or server configuration, not with ini_set() or .user.ini, and to restart every worker. PHP says this "blocks the confirmed session paths but not other variants". See PHP's advisory for the full list and caveats.
5. Compensating controls (if you can't patch or apply PHP's measures). The UK NCSC says that if you are unable to apply the temporary mitigations, or applying them would take too long, you "should consider taking the system offline until it can be fully mitigated". Before the release, CERT-EU advised that organisations "should consider isolating internet-facing applications from public networks until a fix can be applied". Cloudflare's CTO has described Cloudflare's WAF rules as "a STOPGAP only" (quoted by Tenable).
6. Check for compromise. The NCSC says that if you cannot update or disable a system immediately, you "should assess the system for any evidence of compromise prior to your upgrade or mitigation and look for backdoors installed by an attacker".

Indicators of Compromise

None published. PHP, CERT-EU and the NCSC have released no indicators of compromise. Cloudflare says it was seeing early attacks before the release but has not published details. Rescana has not confirmed in-the-wild exploitation, and neither CVE is in CISA's KEV catalog as of this update.

Why this matters for vendor risk

The fix is now out, but you are only protected once every vendor running PHP in its stack has deployed it, and many of those dependencies are invisible from the outside. Ask your critical vendors now whether they run PHP, including bundled runtimes and appliances, whether they are on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a patched vendor build, and when they will finish. Then follow up until each one confirms.

What we will update: We will update this post if NVD publishes its own assessment, if either CVE is added to CISA's KEV catalog, or if PHP revises its advisories.

Sources

• PHP security advisory, "Security advisory: Critical remote code execution vulnerabilities, update now" (21 Oct 2026): https://www.php.net/archive/2026.php#2026-10-21-5
• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 release announcements: https://www.php.net/releases/8_5_12.php · https://www.php.net/releases/8_4_27.php · https://www.php.net/releases/8_3_36.php · https://www.php.net/releases/8_2_35.php
• PHP 8 ChangeLog: https://www.php.net/ChangeLog-8.php
• GitHub php/php-src advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GitHub php/php-src advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• PHP advance notice, "Upcoming Critical PHP Security Release" (20 Oct 2026): https://www.php.net/archive/2026.php#2026-10-20-1
• PHP downloads: https://www.php.net/downloads.php
• cve.org records, CVE-2026-109618 and CVE-2026-109619: https://www.cve.org/CVERecord?id=CVE-2026-109618 · https://www.cve.org/CVERecord?id=CVE-2026-109619
• NVD, CVE-2026-109618 and CVE-2026-109619: https://nvd.nist.gov/vuln/detail/CVE-2026-109618 · https://nvd.nist.gov/vuln/detail/CVE-2026-109619
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• UK NCSC, "Critical security issue affecting PHP": https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
• CERT-EU Security Advisory 2026-018, "Critical Vulnerabilities in PHP": https://cert.europa.eu/publications/security-advisories/2026-018
• BleepingComputer, "PHP ships emergency patches for critical PHP2Shell flaws" (21 Oct 2026): https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/
• Tenable, "php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ": https://www.tenable.com/blog/php2shell-cve-2026-109618-cve-2026-109619-frequently-asked-questions-about-critical-php-remote

Forward this to your TPRM owner: If your vendors run PHP-based web apps, portals or appliances, ask them today whether they have deployed PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or a patched vendor build), and when they will finish.

Want to see which of your vendors expose PHP-based services and how quickly they patch? Book a demo.