PHP emergency security patches fix two critical php2shell flaws

Update, 23 October 2026

The PHP emergency security patches are out: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026, fix CVE-2026-109618 and CVE-2026-109619, two critical "php2shell" flaws rated 9.2 on CVSS v4.0. PHP says all users should update immediately.

The advisory names every PHP installation that serves web requests as at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed, with the highest risk for mod_php. On exploitation, reports differ: Cloudflare's CTO told BleepingComputer the company was already seeing early attacks before the patches shipped, and Help Net Security reports that Amazon's honeypots recorded an exploitation attempt on 17 October. The Canadian Cyber Centre said on 21 October that it had not yet identified active exploitation but warned this could change quickly. The sections below reflect the official advisory; earlier pre-release reporting is kept further down for context.

Key takeaways

• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on 21 October 2026. Updating is the only complete fix, according to the PHP advisory.
• The two flaws are CVE-2026-109618 (remote code execution via out-of-memory corruption) and CVE-2026-109619 (remote code execution via stale global state), each rated 9.2 (Critical) on CVSS v4.0.
• Any PHP setup that serves web requests is exposed, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates mod_php as the highest risk.
• PHP 8.1 and older get no official releases. PHP published minimal source backports for 7.4, 8.0 and 8.1; otherwise you need a distribution or LTS vendor package, or an upgrade.
• Official temporary workarounds exist, including session.upload_progress.enabled=0 and a strict post_max_size, but PHP says they "reduce exposure" and do not make an installation safe.

Which PHP versions fix CVE-2026-109618 and CVE-2026-109619?

Sources: php.net security advisory and release notes, Canadian Centre for Cyber Security AL26-026, php.net supported versions. Linux distributions and LTS vendors received the patches in advance, so their packages may carry different version numbers; check your distribution's security tracker.

How to check your PHP version

1. On the command line, run php -v and compare the result with the fixed releases in the table.
2. Check the build that actually serves web traffic too. The CLI and the web SAPI (PHP-FPM or mod_php) can be different installations; a temporary phpinfo() page or php-fpm -v shows the web version. Remove any phpinfo() page afterwards.
3. List bundled copies: control panels, appliances, Docker images and CMS packages often ship their own PHP. The Canadian Cyber Centre specifically asks organisations to find third-party products and containers that bundle vulnerable PHP.

Official workarounds if you cannot update yet

The php.net advisory lists measures that lower exposure while you schedule the upgrade. It stresses that none of them makes a server safe.

• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini, the FPM pool or server configuration, then restart every worker. PHP says not to rely on ini_set() or FPM .user.ini. On PHP 8.5, also set fatal_error_backtraces=0.
• For CVE-2026-109618: set a low post_max_size (8M if the site needs no uploads, 32M if it does) with upload_max_filesize below it, and enforce request-size limits at the web server or proxy. The advisory also describes setting memory_limit=-1 through php_admin_value, combined with a container or cgroup memory limit, and warns against using RLIMIT_AS or RLIMIT_DATA.
• Edge filtering: Cloudflare says it has deployed temporary WAF rules against known php2shell exploit methods, according to BleepingComputer and Help Net Security.
• Last resort: the UK's NCSC has urged organisations to take systems offline if they cannot be patched right away, as reported by Help Net Security.

What the PHP project announced

On Tuesday, 20 October 2026 at 19:33 UTC, PHP release manager Jakub Zelenka posted a notice to the project's official php.announce mailing list titled "Upcoming Critical PHP Security Release". The notice says the release will address "two critical vulnerabilities (both rated CVSS v4.0 9.2, Critical)" and gives the release time as 14:00 UTC on Wednesday, 21 October 2026.

The announcement is short. It does not name the affected branches, the vulnerable components, or any workaround. It asks users to prepare now so they can update as soon as the release is available, and it notes that the team reserves the right to publish sooner if the details leak further or if attackers start exploiting the bugs. The same advance notice appears on the php.net front page, which says affected and fixed versions will be listed with the release.

Pre-announcing a security release is unusual for PHP. Its regular security updates normally ship with little advance publicity. The most recent ones arrived on 24 September 2026 as PHP 8.5.11, 8.4.26, 8.3.35 and 8.2.34. A separate heads-up with a fixed hour indicates the maintainers expect a fast, broad response from server operators.

Why the warning came early

According to timelines published by the security firms Sansec and Huntress, a post on the Hacker News forum at about 15:20 UTC on 20 October described two upcoming PHP remote code execution disclosures. The post was later removed, but screenshots circulated. Huntress and Sansec both report that the security firm watchTowr confirmed the flaws were real, and Huntress says watchTowr reproduced one of them, CVE-2026-109618. Sansec reports that the scheduled date was a day earlier than originally planned.

The EU's cybersecurity service for its institutions, CERT-EU, issued Security Advisory 2026-018 for the two CVEs. It says they "could lead to remote code execution" and that the scores point to possible unauthenticated exploitation. CERT-EU adds that no technical details are public yet.

Which versions and features may be affected

This is the biggest open question, and the official answer will come only with the release. What the sources say so far:

• PHP (official): affected and fixed versions will be published with the release.
• CERT-EU: citing another source, says the flaws could affect all PHP versions from PHP 5 onwards.
• Sansec: says a leaked screenshot of an exploit tool called "PHP2Shell" claims to work against every release from PHP 5.4.0 onwards. That claim comes from the tool's own banner and has not been independently verified.
• Huntress: says reports point to PHP 5 through 8 but that no root cause has been published. It expects fixes only for supported PHP 8 branches.

On the specific component, the Japanese security news site Lilting has compiled researcher analyses that link at least one of the bugs to the handler for session.upload_progress, described as a heap use-after-free. This is a type of memory-corruption bug in which a program keeps using memory after releasing it. One independent researcher places the bug in the php_session_rfc1867_callback function and says the second flaw sits elsewhere, in the multipart request parser. GMO Flatt Security, also cited by Lilting, warns that its own analysis may contain inaccuracies. None of these attributions has been confirmed by the PHP project or CERT-EU, and readers should treat them as provisional.

The session upload progress feature lets PHP record how much of a file upload has arrived, so a web page can show a progress bar. According to the PHP manual, session.upload_progress.enabled defaults to "1" (on) and can be changed per directory (INI_PERDIR). That means it cannot be switched off from inside an application with ini_set().

The numbers: PHP branches and exposure

The W3Techs figures matter because roughly a third of PHP-powered sites in its survey run PHP 7 or PHP 5. Those branches stopped receiving official fixes years ago. If the flaws do reach back that far, those sites will not get a patch from the PHP project.

What server administrators should do now

The only complete fix is to install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (or your vendor's patched package). The guidance from PHP, CERT-EU, the Canadian Cyber Centre, Huntress and Sansec comes down to the following steps. If your team also manages logins for admin panels and hosting accounts, our guide on how to set up passkeys covers a related hardening step.

1. Inventory every PHP installation. Huntress stresses that PHP is often bundled inside vendor appliances, hosting control panels and CMS packages, not only installed as a standalone package.
2. Get ready to patch internet-facing systems first. Watch the php.net front page and the php.announce list for the fixed version numbers. If you rely on Linux distribution packages, check your distribution's security tracker, because backported fixes may carry different version numbers.
3. Talk to your host. Sansec notes the fix happens at the server level and cannot be applied from application code, so store owners on Magento, Shopware or WooCommerce who do not manage their own servers should ask their provider to apply the update as soon as it ships.
4. Deal with end-of-life PHP. Huntress advises upgrading, taking offline, or restricting behind a VPN or web application firewall any server on PHP 5, 7, 8.0 or 8.1. CERT-EU recommends isolating internet-facing applications if patching cannot happen quickly.
5. Use the stopgaps only as a bridge. Setting session.upload_progress.enabled = 0 is now part of PHP's own advisory, but only for CVE-2026-109619, and it must be set in php.ini, the FPM pool or server configuration (not ini_set() or FPM .user.ini), followed by a restart of every worker. File uploads still work; only progress tracking stops. See the official workaround list above for CVE-2026-109618.
6. Watch for compromise. Huntress cites detection researcher Florian Roth, who expects exploitation to show up as "suspicious child processes spawned by PHP". That means PHP workers such as php-fpm or apache2 launching shells or download tools. If a breach is suspected, isolate the server and preserve web and PHP logs before cleaning up.

What is still unknown

Since the release, PHP has published the fixed versions, the root-cause descriptions and official workarounds (see the update above), and the researchers credited include Calif, OpenAI and Wiz, according to BleepingComputer. The scale of real-world exploitation is still unclear: reports from Cloudflare and Amazon point to early attack attempts, while the Canadian Cyber Centre had not confirmed active exploitation on 21 October. The paragraph below describes the situation before the release. For another recent security incident at a widely used online platform, see our report on the Quest Diagnostics Quanum breach.

As of the latest public information before the scheduled release, PHP had not published the affected versions, the root cause, or any official workaround. Huntress said it had seen no in-the-wild exploitation in its partner environments as of 20 October, and no public exploit code was known. Sansec expects mass attacks to begin within about 15 minutes of the release, an estimate rather than an observation. Whether the bugs can be triggered without authentication, and under which server setups (mod_php, PHP-FPM, CGI), also remains unconfirmed.

What it means

PHP is the server-side language behind most of the web, including widely used content management and e-commerce platforms, so a remotely exploitable flaw in PHP itself could have a broad blast radius. Unlike a plugin bug, it cannot be fixed by updating a single application. Every server has to be updated at the runtime level. The pre-announcement gives operators a narrow window to line up maintenance and contact hosting providers. The bigger long-term risk lies with the large number of sites still on unsupported PHP versions, which may stay exposed after today unless they upgrade or are shielded. Administrators should treat the official PHP release notes, not leaks or social media claims, as the authoritative record of what is affected and fixed. The same urgency applies to other platform changes that force quick action from users, such as the Arc browser shutdown, and to new attack surfaces created by AI agents logging into customer accounts.

Sources

• PHP.net security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)
• PHP.net: PHP 8.5.12 release announcement
• Canadian Centre for Cyber Security: AL26-026, critical vulnerabilities impacting PHP
• BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws
• Help Net Security: PHP2Shell vulnerabilities patched
• PHP php.announce #509: Upcoming Critical PHP Security Release (20 Oct 2026)
• PHP.net front page: news and security announcements
• PHP.net: Supported versions
• PHP manual: Session runtime configuration
• PHP manual: Session upload progress
• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Huntress: Rapid Response, php2shell leaked critical PHP vulnerabilities
• Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619
• Lilting: Disabling session.upload_progress before the php2shell patch lands
• W3Techs: Usage statistics of PHP for websites