PHP2Shell: two critical PHP flaws and what to do

What was released and why action matters

Updated 22 October 2026. PHP published security updates on 21 October for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, collectively called PHP2Shell. This is not merely a content-management plugin issue: it concerns the PHP engine serving web requests. Exploitation can allow unauthenticated code execution on a vulnerable server. This warrants urgent action, but does not prove any particular website has already been compromised. Keep the potential impact separate from an actual incident finding and follow the primary advisory rather than assuming every application has an identical exposure.

The official notice includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed among installations needing review. PHP assesses risk as highest for mod_php and documents demonstrated exploitation before application code runs. A small website, absence of a login form or updated plugins is therefore insufficient reassurance. Identify the PHP actually serving requests and confirm its correction. Exposure depends on version, provider and configuration; this article determines no individual server’s status. Reviewing the underlying runtime is a separate task from merely checking whether the application’s own code has recently changed.

The two flaws and corrected releases

At a high level, CVE-2026-109618 involves memory corruption during out-of-memory handling. CVE-2026-109619 concerns internal state surviving its backing memory and being reused by another request on the same worker. The PHP Foundation explains both problems and their remediation process. This distinction prevents reducing the incident to one universal configuration recipe. You do not need to reproduce an attack to decide to update. This guide provides no exploit tests against public services or commands deliberately triggering failures. Authorized maintenance can proceed based on the published vulnerability and provider guidance.

The 21 October releases identify PHP 8.5.12,8.4.27,8.3.36 and 8.2.35 as fixed in their respective branches. Check the current advisory before changing systems because later revisions may appear. Distribution packages may backport fixes without adopting those exact base numbers; Ubuntu lists specific packages in USN-8948-1. Do not compare only the interpreter string with an online list. Confirm the package and vendor advisory. PHP 8.1 and older are outside upstream support; a distributor correction does not itself restore upstream support. Record the applicable provider evidence rather than inferring patch status from a number alone.

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

What to ask hosting and administrators to verify

For managed hosting, request confirmation for both CVEs: installed package, affected service and verification that active processes use the fix. Ask about all domains, pools, containers and products embedding PHP, not only the main shell. A command-line version does not necessarily establish what serves the website. If administering the system, use the documented distribution or vendor update channel and preserve recovery access and suitable backups before changes. Do not obtain supposed patches from unverified messages or repositories. The maintenance plan should identify the actual component and its authorized update path.

After installing updates, renew processes as the provider instructs and verify the running version or package. Test essential application functions and record when remediation occurred. Updating only the CMS or clearing cache does not replace runtime patching. If intrusion indicators exist, preserve evidence and activate incident response: patching alone does not undo changes an attacker already made. These are operational closure checks, not remote diagnosis. A restored homepage still requires patch confirmation and functional validation. Keep evidence of installation, active runtime and intended service behavior distinct rather than treating a successful page view as proof of all three.

When immediate patching is impossible and WikiURL’s limits

PHP warns that updating is the only complete solution. Temporary mitigations reduce particular attack paths but do not make an installation safe. Do not copy memory or session changes without understanding effects and scope. ENISA recommends prioritizing exposed systems and considering isolation from public networks if immediate remediation is impossible. Coordinate with the administrator to retain secure management access and communicate interruptions. A WAF rule or apparently working application is neither a substitute for patching nor proof of comprehensive protection. Use the official technical guidance for the actual environment rather than a generic workaround.

WikiURL’s URL checker can help review HTTP response and detected destination of a public address after maintenance. It does not identify the actual PHP runtime or prove these CVEs fixed. Status 200 or an HTTPS padlock is not a vulnerability assessment. Do not submit secrets or publish phpinfo files as patch evidence. Preserve provider confirmation, process verification and service tests as separate records. The news calls for urgent updates and verification, avoiding both unsupported claims of compromise and false reassurance from a page that simply opens. This article explains the response; it does not certify WikiURL or another individual installation as patched.