On 21 October 2026 the PHP project released emergency updates for two critical flaws in PHP itself, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell". Both can let an attacker run code on a web server without logging in. The UK's National Cyber Security Centre (NCSC) published an alert the same day. If your website, customer portal, SaaS product or internal tool runs on PHP, this one needs action this week, not next quarter.
What has actually happened?
Details of the two vulnerabilities leaked online on 20 October, before the planned coordinated disclosure and before any fix was available. The PHP project brought its release forward and shipped fixed versions on 21 October: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
Both flaws carry a CVSS v4.0 score of 9.2 out of 10. CVSS (Common Vulnerability Scoring System) is the standard way of rating how serious a vulnerability is, and anything above 9 is treated as critical. The PHP advisory describes them as allowing unauthenticated remote code execution. In plain terms, someone on the internet could send a crafted request to your server and run their own commands on it.
Does this apply to you?
Probably, if you use PHP anywhere. According to the PHP project, every PHP installation that serves web requests is affected. That includes the common ways of running PHP: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP advisory singles out Apache with mod_php as the highest risk, with a demonstrated exploit that can trigger before any of your own application code runs. That last point matters: good coding practice in your app does not protect you here.
PHP also sits underneath many products you may not think of as "PHP". WordPress, Drupal, Magento and many hosted control panels, plugins and appliances use it. The NCSC asks organisations to check suppliers that bundle PHP, not just the servers they manage directly.
One more catch: PHP 8.1 and older no longer receive official project updates. If you are on an older branch, check whether your Linux distribution or long-term support vendor has issued a patched package. If not, upgrading is the real fix.
Is it being exploited?
The picture was moving quickly on 21 October. Security firm watchTowr reported seeing active exploitation attempts against both flaws, according to The Hacker News. Huntress reported later that day that it had not yet seen in-the-wild exploitation across its partners' systems. At the time of those reports, neither flaw was on the US Cybersecurity and Infrastructure Security Agency's (CISA) list of known exploited vulnerabilities.
Attempts are not the same as successful break-ins. But a leaked bug, a public fix and a working exploit for one configuration is the pattern that usually leads to mass scanning within days. Treat it as urgent.
Can a configuration change buy you time?
The PHP project lists temporary mitigations, such as disabling session upload progress tracking and tightening memory and upload limits. It is clear that these reduce exposure but do not make an installation safe, and that "updating is the only safe choice". The NCSC's advice follows the same order: update first; if you truly cannot, apply the mitigations or take the system offline; and if neither is possible, check it for signs of compromise.
What should you do this week?
- Find every PHP installation. Include websites, APIs, admin panels, staging servers, containers and old "temporary" boxes. The NCSC says to look at all installations, not only the ones you know are out of date.
- Start with what faces the internet. Prioritise anything reachable from outside, then internal systems.
- Update to a fixed version. That means 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package. Rebuild container images rather than patching running containers.
- Restart PHP after updating. Confirm the running version (for example, via your monitoring or a protected status check), not just the installed package.
- Apply the PHP project's mitigations only as a stopgap where an update is blocked, and set a date to remove that blocker.
- Ask your suppliers. Hosting providers, managed WordPress or Magento platforms and SaaS tools that hold your data should be able to confirm they have patched.
- Check for compromise on anything that was exposed and unpatched. Look for unexpected files in web directories, new admin accounts, unusual outbound connections and changes to scheduled tasks.
- Record what you did. A short log of systems, versions and dates is useful evidence for ISO 27001, SOC 2 and Cyber Essentials, and for customer security questionnaires.
Where does this leave you?
Most teams can close this out quickly once they know where PHP is running. The hard part is usually the inventory: the forgotten staging server, the marketing microsite, the plugin inside a vendor appliance. That is exactly what an external infrastructure test is designed to surface.
If you would like an independent check that nothing internet-facing has been missed, our penetration testing covers external infrastructure, web applications and APIs, with known vulnerabilities verified by hand and a retest of your fixes included.
Sources
- PHP: Security advisory: Critical remote code execution vulnerabilities, update now (21 Oct 2026)
- PHP: Upcoming Critical PHP Security Release (20 Oct 2026)
- NCSC: Critical security issue affecting PHP
- CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
- The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge
- Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities
- nevatech: Penetration testing
Enterprise-grade testing at SME prices. Executive summary, evidenced findings and a retest in every engagement.
