Two critical vulnerabilities in the PHP interpreter itself, rather than in a framework or plugin, were announced as CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell. The PHP security team rated them 9.2 under CVSS v4.0. Early leaked reports claimed 10.0, but that score was not verified.

session.upload_progress.enabled = 0

CERT-EU advisory 2026-018 described the impact as unauthenticated remote code execution. CERT-EU and Australia's ACSC said PHP 5 and later might be affected, although PHP had not published an official affected-version range at the cutoff. The planned fixes covered PHP 8.2, 8.3, 8.4 and 8.5. Pre-release reports named versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, pending confirmation in the official announcement.

The disclosure sequence broke the usual security embargo. Around 15:20 UTC on 20 October, an anonymous Hacker News post warned that two critical PHP RCE flaws were about to become public. The post disappeared, but screenshots circulated. The original embargo reportedly lasted until 22 October. PHP then moved the release to 21 October at 14:00 UTC, with permission to release earlier if active exploitation became evident. CERT-EU published advisory 2026-018, watchTowr reproduced one flaw, and a researcher's demonstration video briefly appeared online before being removed.

Early on 21 October, reports linked the issue to PHP's session upload-progress code. GMO Flatt Security said at 05:00 UTC that the configuration change spreading online was incomplete and would likely be bypassed. At 07:43 UTC, Cloudflare CTO Dane Knecht reported early attacks and said emergency WAF rules had been enabled for all customers, including free plans. Huntress, watchTowr and ACSC had not reported confirmed in-the-wild exploitation when their respective updates were published.

Proof-of-concept repositories appeared on GitHub within hours. Some presented themselves as verification tools, others claimed to contain working exploits, and at least one independent audit found that circulating exploit code did not work. Once a patch is available, attackers can compare the corrected and vulnerable code. Sansec expected mass attacks to begin within minutes of the release.

The suspected attack surface is the PHP runtime's handling of multipart form data, which is used by file uploads and parsed before application code runs. If that assessment is correct, application-level login checks, CSRF protection and upload validation arrive too late. Disabling PHP file uploads may not stop the parsing of a multipart request. Any page accepting POST data could therefore be relevant, not only an upload form. PHP had not confirmed the root cause, and researchers disagreed about the precise vulnerable component. The consistent advice was to patch or upgrade rather than rely on a setting.

The most widely shared workaround was `session.upload_progress.enabled = 0`. GMO Flatt later said it was not complete protection. Another researcher said the second vulnerability was reachable through the multipart parser regardless of that option. PHP 8.6 release manager Joe Ferguson likewise rejected reliance on INI settings. The option is PHP_INI_PERDIR, so `ini_set()` cannot change it during execution. A change made in the CLI configuration instead of the PHP-FPM pool, or in `.user.ini` under mod_php, can silently have no effect. Disabling it removes upload progress indicators and may provide an extra layer, but it does not close the incident.

The security gap is largest on unsupported branches. PHP 8.1 reached end of life in December 2025, PHP 8.0 in November 2023, and PHP 7.x and 5.x years earlier. If the reported PHP 5 lineage is correct, those installations receive no upstream fix. Mallory's Shodan analysis found about 1.5 million internet-facing hosts advertising a PHP version on 20 October. Roughly 884,000, or 59 percent, used an unrepaired branch: about 369,000 ran PHP 5.x, 329,000 ran 7.x, and 186,000 ran 8.0 or 8.1. Another 740,000 hosts hid their version, so the real exposure is higher. These are banner counts, not vulnerability counts.

The same data identified about 53,600 PHP hosts in India. Around 19,800 of the hosts that disclosed a version used a branch with no planned fix. Banner data cannot identify the operators. Such old installations commonly include abandoned legacy portals, small-business sites and long-lived shared-hosting systems.

Operators on an end-of-life branch have four practical choices. They can move to a supported PHP version, obtain a backported fix from a distribution or hosting provider, remove the system from the public internet behind a VPN or allowlist, or take it offline. Enterprise distributions and some hosts maintain older packages on their own schedules, so administrators should match the CVE in the provider's advisory rather than trust the PHP version alone. CERT-EU recommended taking systems offline when patching is impossible.

The response plan starts with an inventory of every PHP runtime, including PHP-FPM, Apache mod_php, CGI, containers, CI runners, cPanel, Plesk, XAMPP and appliances that embed PHP. Internet-facing systems and every host running PHP 8.1 or older belong on the emergency list. Teams should prepare the upgrade and agree who can approve a restart. Cloudflare users should configure managed rules to block rather than merely log, and should prevent direct access to the origin.

After release, supported branches need immediate patching through php.net or the relevant distribution. PHP-FPM, Apache, Laravel Octane and queue workers must be restarted because long-running processes retain the old interpreter in memory. Administrators should verify the version used by the serving process, not only the shell output from `php -v`. Managed-hosting customers need to ask when the provider's fixed build is available.

Incident checks should cover new or modified PHP files in web roots and upload directories, new CMS administrators, unexpected outbound connections and crashing PHP workers. Researchers noted that failed exploit attempts can crash a worker, making a burst of 5xx responses to POST requests worth investigating. Any exposed end-of-life server should be treated as potentially compromised until checked. Credentials, API keys and cloud roles present on such a host should then be rotated.