Published 22 October 2026
# PHP2Shell: Two Critical Bugs, One Unavoidable Truth
The PHP project released emergency patches on 21 October 2026 for two critical vulnerabilities that allow unauthenticated remote code execution on any server running PHP. The bugs, CVE-2026-109618 and CVE-2026-109619, are rated CVSS v4.0 9.2 and affect every supported PHP version from 8.2 through 8.5. They are collectively known as PHP2Shell.
This is the kind of incident that makes the hair on the back of your neck stand up. An attacker does not need a username, password, or valid session. They do not need to trick a user into clicking a link. A single unauthenticated web request, sent to a default Apache mod_php installation, can hand over control of the server before a single line of application code runs. The PHP Foundation confirmed full remote code execution was demonstrated with default settings.
What the bugs actually do
CVE-2026-109618 is an out-of-memory corruption flaw. PHP enforces its user-configurable memory_limit by aborting requests that exceed it. If the abort happens at the wrong moment, while internal request data is only partially initialised, cleanup code can treat invalid data as valid and free memory that was never properly set up. That memory may still contain data from earlier attacker-controlled allocations.
CVE-2026-109619 is a use-after-free bug. When a fatal error occurs, internal state owned by one request can survive after its backing memory is freed. A later request handled by the same worker can then use that stale state before normal initialisation resets it. The PHP Foundation confirmed remote code execution against a real-world application running on Apache with mod_php.
Both flaws live in the engine core: memory management and error handling. That is what makes them dangerous, and what makes them hard to fix without breaking compatibility or hurting performance across the enormous PHP extension ecosystem.
Current status and exploitation
Patches are available now: PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Linux distributions and long-term support vendors received the fixes in advance. The PHP Foundation says updating is the only complete mitigation.
CISA, CERT-EU, and ENISA have all issued urgent advisories. Finnish government services and Dutch parliamentary websites were taken offline as a precaution. Security vendors have reported exploitation attempts in the wild, and the PHP Foundation confirmed that proof-of-concept code began circulating within hours of the disclosure.
The disclosure itself was messy. Two days before the planned release, the CVE IDs leaked on social media with an incorrect CVSS score of 10.0. A security firm, Calif, accidentally published a proof-of-concept video. Chainguard published fixed container images more than six hours before the coordinated release. The PHP Foundation described the leak as accelerating attacker capability beyond the intended timeline.
What you should do right now
If you run PHP, update to one of the patched versions immediately. Restart every PHP worker afterwards. If you use containers, rebuild your images with the patched base and redeploy.
If you cannot patch today, the interim advice from CERT-EU and the PHP Foundation is to isolate internet-facing applications from public networks until you can. Temporary configuration changes reduce exposure to specific attack paths but do not make an installation safe. Set memory_limit=-1 at the administrator level, lower post_max_size, disable session.upload_progress.enabled, and on PHP 8.5 set fatal_error_backtraces=0. But treat these as buying time, not as a fix.
End-of-life PHP versions, 8.1 and older, do not receive official patches. The PHP security team published minimal source backports for 7.4, 8.0, and 8.1, but if you run an unsupported branch, the only safe path is to upgrade to a supported release or take the application offline.
What this means
PHP powers roughly 76 percent of websites with a known server-side language, including most WordPress, Drupal, and Joomla installations. A vulnerability of this severity, with a demonstrated unauthenticated exploit path, is not a niche problem. Hosting providers, WordPress agencies, and internal IT teams that have deferred PHP upgrades need to treat this as an emergency maintenance window.
The PHP Foundation used the incident to acknowledge structural problems in its security resourcing and decision processes. It has since added an Ecosystem Security Team, hired dedicated triage staff, and integrated AI-assisted validation tools. Whether that is enough to prevent the next PHP2Shell remains an open question.
The cost of delayed patching is not theoretical. An unauthenticated request to a default configuration can hand an attacker a shell before any application logic runs. Update, restart, and verify.
Sources
PHP Foundation — “Today’s PHP Security Release, and How We’re Strengthening PHP Security” — 21 October 2026 — https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
CERT-EU — “Critical Vulnerabilities in PHP” (Security Advisory 2026-018) — 21 October 2026 — https://cert.europa.eu/publications/security-advisories/2026-018/
ENISA — “Joint statement on critical PHP vulnerabilities” — 21 October 2026 — https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
CISA — “Critical Vulnerabilities in PHP Require Immediate Patching” — 21 October 2026 — https://content.govdelivery.com/accounts/USDHSCISA/bulletins/42ff5ac
PHP Security Advisory — https://www.php.net/archive/2026.php#2026-10-21-5
Related Reading
More cybersecurity analysis and AI coverage at philiphall.com
How this analysis is researched, sourced and corrected: Editorial standards and corrections. Spotted an error? Contact Philip Hall.
