Home / Insights / Critical PHP Vulnerabilities (PHP2Shell):CVE-2026-109618 and CVE-2026-109619 Explained

Insights

Critical PHP Vulnerabilities (PHP2Shell):CVE-2026-109618 and CVE-2026-109619 Explained

Posted in Blog Posts
on October 22, 2026
by George Chapman

On the 21^st of October 2026, the PHP project released emergency security updates for two critical vulnerabilities in PHP core, tracked as CVE-2026-109618 and CVE-2026-109619 and referred to collectively as “PHP2Shell”.

Both are Remote Code Execution vulnerabilities, rated as Critical under the CVSS v4.0 rating system with scores of 9.2. The UK National Cyber Security Centre (NCSC) has urged organisations to take immediate action, and CERT-EU issued its own advisory.

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The PHP team has also published source backports for 7.4, 8.0 and 8.1, although those branches no longer receive routine support, so organisations relying on them should confirm their position with their distribution or hosting provider.

What the vulnerabilities allow:

Both flaws sit in the PHP runtime itself, which means an application is exposed even when its own code is well written. The two issues work in different ways.

CVE-2026-109618: involves PHP’s handling of out-of-memory conditions. If the interpreter is interrupted while request data is only partially prepared, the subsequent cleanup can treat that invalid data as though it were valid, leading to memory corruption.

CVE-2026-109619: concerns internal state that can persist after the memory backing it has been freed. A later request handled by the same worker process can then act on that stale data. Beyond remote code execution, this flaw can also allow an adversary to read live memory from PHP worker processes, which may expose passwords, session tokens, API keys and certificates belonging to other users’ requests.

Any code the adversary runs executes with the privileges of the web server worker. The PHP security team has identified the Apache mod_php configuration as the highest risk, as an unauthenticated request can trigger the problem before any application code runs.

PHP-FPM and other setups are affected through certain paths. The underlying code has been present in PHP for more than a decade, and the NCSC’s position is that organisations should treat every version of PHP as potentially affected, including current releases.

The business risk:

The practical concern is twofold. The first is remote code execution on internet-facing systems, which gives an adversary a foothold on the server. The second, less obvious, is the potential exposure of secrets held in memory, which could undermine other systems well beyond the PHP host itself.

VirusTotal has estimated that more than five million PHP hosts are reachable online making the scale of exposure is significant. The disclosure was also disorderly: details leaked whilst the vulnerabilities were still under embargo, and Cloudflare reported observing early exploitation attempts against both flaws before the patches were even published.

At the date of publication of this advisory, researchers had not confirmed a successful compromise in the wild, but the window between disclosure and patching means exposed systems may already have been targeted by attackers.

What the NCSC recommends:

The NCSC’s guidance for UK organisations is available, and its main points are:

Identify all systems running PHP, prioritising internet-facing services, and include software and appliances that bundle PHP from third parties. The NCSC is explicit that discovery should not be limited to outdated versions, because all versions may be affected.
Update to the latest fixed version and continue to monitor for further vendor updates to bundled products.
Where an immediate update is not possible, apply the temporary mitigations published by the PHP team. These reduce exposure to specific attack paths but do not replace the patch.
Where neither an update nor a mitigation can be applied in reasonable time, consider taking the affected system offline until it can be fully addressed.
Where a system cannot be updated or taken offline promptly, check it for signs of compromise and for backdoors. The NCSC advises engaging an NCSC-assured Cyber Incident Response provider if you are not confident carrying this out yourself.

Practical steps to take now:

Patch to a fixed version. Update affected systems to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 as appropriate for your branch. Internet-facing services should be first.
Account for versions that are out of support. If you are running PHP 8.1 or earlier, confirm whether your Linux distribution or LTS vendor has backported a fix, and plan to move to a supported branch. Some distributions ship fixes under version numbers that still look old, so check the package changelog for the CVE references.
Review if any secrets may have been exposed. Given the memory disclosure risk, consider rotating credentials, API keys and tokens used by any system you believe may have been exposed before patching.
Follow official mitigation guidance if you cannot patch at once. The PHP team’s advisories set out temporary measures, including stricter memory handling for CVE-2026-109618 and disabling the session upload progress feature for CVE-2026-109619. Treat these as interim steps and apply the update as soon as you can.
Check your logs. Review web server and application logs for unusual requests, for a web server process launching a shell or download utility, and for unexpected files or outbound connections. Confirm that logging is enabled and centralised, as those records support any later investigation.

If you suspect a compromise

Because exploitation attempts began before the patch was available, patching alone does not confirm that a system is clean. If you find evidence of exploitation, or you cannot rule it out on an exposed system, treat it as an incident.

Preserve the evidence, avoid wiping affected systems, and seek expert support early. Acting on assumptions, or rebuilding a server before it has been examined, can lead to the loss of information that may be required to understand what happened.

How Prism Infosec can assist

Prism Infosec helps organisations identify exposed internet-facing systems through penetration testing and attack surface monitoring, helping you locate potentially vulnerable PHP services before attackers do. If you need support, we can carry out a focused attack surface assessment to help you understand your organisation’s exposure and prioritise further investigation.

If you suspect a system may have been compromised, our Incident Response team can help you establish what happened and recover with confidence. Prism Infosec is an NCSC Assured Provider for Cyber Incident Response, which is the standard the NCSC itself points organisations towards in its PHP guidance.

If you need support apply the necessary fixes but are unable to do so yourself, we offer Remediation Services whereby we can support this activity for you.

Call Prism Infosec on +44 (0) 1242 652 100 or contact your account manager if you need support now. If you are unsure whether your estate is exposed, or you have seen activity you cannot account for, please get in touch.

Sources

About the author

George Chapman

George Chapman is a Senior Security Consultant with a background spanning red teaming, incident response, penetration testing, and vulnerability research. His work bridges offensive and defensive disciplines, enabling him to deliver robust security evaluations and strategic guidance that help organisations identify weaknesses and improve their overall cyber maturity.