The short version
On 20 October 2026, details of two critical vulnerabilities in PHP itself leaked online ahead of a planned coordinated disclosure. Together they are known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). The PHP project shipped emergency fixes the following day.
If your business runs anything built on PHP, and that includes WordPress, Drupal, Joomla, Magento and a great deal of bespoke software, this one matters:
An attacker can potentially run their own code on your web server without logging in and without anyone clicking anything.
It affects PHP versions going back over a decade, to PHP 5.4.
Attack attempts were observed before the patches were even released.
PHP 8.1 and older will not receive an official fixed release. That is where the real problem lies for many organisations.
The UK's National Cyber Security Centre has issued an alert urging organisations to take immediate action, and advises that where a system cannot be fixed straight away, organisations should consider taking it offline until it can be. The NI Cyber Security Centre has published the same guidance for Northern Ireland organisations.
If you only have two minutes: ask whoever looks after your websites and web applications which PHP version each one runs, and whether it has been patched since 21 October. If the answer is "we're not sure" or "it's on PHP 7", read on.
What is PHP2Shell?
PHP is the programming language behind a huge share of the web. Most of the time, security problems are found in the applications built on top of PHP: a plugin with a flaw, a form that doesn't validate input. PHP2Shell is different. The flaws are in PHP's own runtime, the engine that sits underneath every PHP application.
In plain terms, both vulnerabilities come down to how PHP tidies up after itself when a web request ends abnormally:
CVE-2026-109618 concerns what happens when PHP runs out of memory part-way through setting up an incoming request. The request data is left half-built, and PHP's clean-up routine then treats that half-built data as if it were valid. A carefully crafted request can turn that into code execution.
CVE-2026-109619 concerns information from one request lingering after its memory has been released. If the same server process handles another request, PHP can reach back into that stale information. This can be used to read memory and, again, to run code.
The PHP project rates both as critical (9.2 out of 10 on CVSS v4.0). Some security firms have scored them at the full 10.
Because the flaws sit in PHP itself, your application does not have to have done anything wrong to be exposed. Every common way of running PHP for the web is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team consider mod_php the highest risk, because a demonstrated exploit fires before any of your application code has even started.
How it unfolded
17 October: Amazon's threat intelligence honeypots recorded an exploitation attempt, days before public disclosure.
20 October: Details leaked on Hacker News ahead of a coordinated release planned for 22 October. The PHP security team issued an advance warning and brought the release forward.
21 October, early hours: Cloudflare switched on protective firewall rules for its customers, having already seen attack traffic.
21 October, 14:00 UTC: PHP released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The NCSC published its alert for UK organisations the same day, and researchers published technical write-ups, including working attacks against WordPress, Drupal and Joomla.
Why this one is a sign of things to come
The underlying weaknesses had been present in PHP for many years. What changed is that the research teams involved (Wiz, Calif and OpenAI) used frontier AI models to work through an exploitation chain that had previously been at the very edge of what human researchers could practically manage.
AI is making it faster and cheaper to find and weaponise old, deep flaws in mature software. The gap between "vulnerability exists" and "vulnerability is being exploited" is shrinking, and old software that nobody is actively looking after is the most exposed of all.
What could the impact be?
For a business, "remote code execution" translates into some very concrete risks:
Data exposure. An attacker running code on your server can read your database, customer records and files. Researchers also showed that the memory disclosure route alone could leak passwords, API keys, access tokens and certificates.
A foothold into everything else. Credentials and keys lifted from a web server are frequently the way into cloud accounts, payment providers, email systems and internal tools.
Website defacement or malware. Compromised sites are routinely used to serve malware or phishing pages to your own customers, which damages trust and search rankings.
Ransomware and downtime. A web server is a common first step in a wider attack.
Regulatory consequences. If personal data is involved, you may have reporting obligations under UK GDPR, and contractual obligations to clients.
The risk is highest for anything internet-facing, and for anything running an end-of-life version of PHP. One analysis counted roughly 884,000 internet-facing servers advertising a PHP version that the PHP project no longer patches.
What business leaders should do now
You don't need to understand memory corruption to manage this well. You need clear answers to a small number of questions. Put these to your internal IT team, your hosting provider, or your software supplier:
What do we run on PHP? Include the obvious (the website, the customer portal) and the less obvious (booking systems, intranets, control panels, and vendor products that quietly bundle PHP).
Which version of PHP is each one on? Anything below 8.2 should be treated as a priority.
Has each one been patched since 21 October, and how do we know? Ask for evidence, not reassurance.
For anything that can't be patched straight away, what is protecting it in the meantime? For example, a web application firewall, restricting access, or, as the NCSC advises, taking it offline until it can be fixed.
Have we checked for signs that we were compromised before we patched? Patching closes the door. It doesn't tell you whether someone already walked through it.
Who owns this application? If nobody can answer that confidently, that is a finding in itself.
If a supplier can't give you straight answers to these, that tells you something important about the support arrangement you're paying for. If you would like an independent view, our technical audit gives you exactly that.
What technical teams should do now
The NCSC's alert sets out the priority actions: identify every PHP system, prioritising internet-facing ones; monitor them for malicious activity; and apply the updates. The steps below expand on that.
1. Inventory every PHP runtime
Start with web servers, then hunt for the less obvious places: containers and base images, control panels such as cPanel and Plesk, vendor appliances, and Windows software that bundles php.exe or php-cgi.exe. As the NCSC points out, don't limit discovery to outdated versions: every unpatched branch is affected. Record the PHP branch, the SAPI (mod_php, PHP-FPM, CGI and so on) and whether the host is internet-facing.
2. Patch supported branches immediately
Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, matching the branch you are on. Internet-facing systems first, mod_php hosts at the top of the list.
If you install PHP from your operating system's packages, use your distribution's updates rather than upstream builds. Red Hat, Debian, Ubuntu, AlmaLinux, Rocky Linux, cPanel EasyApache 4 and CloudLinux have all shipped fixes. Be aware that distributions often backport the fix into an existing version number, so php -v may still show an older-looking version once patched. Check the package changelog rather than relying on the version string.
3. Deal with end-of-life PHP: the low-hanging fruit
The PHP project does not issue releases for PHP 8.1 or older. That does not mean you are without options. In rough order of preference:
Your distribution or platform vendor. Several have backported fixes to older streams they still ship, for example PHP 7.4 and 8.0 on Red Hat-based systems, and ea-php74, ea-php80 and ea-php81 on cPanel. Check this first.
Commercial extended support. Vendors such as TuxCare offer patched builds for end-of-life PHP branches.
PHP's own minimal source backports for 7.4, 8.0 and 8.1. Given the severity, the PHP security team published these on GitHub for organisations that build PHP from source or have no LTS vendor. They are not full releases, but they come from the people who wrote the fix.
Community patches for even older versions. Independent researchers have published unofficial patches for PHP 5.6 and 7.x on GitHub. Some are explicitly marked as untested candidates. Treat these as a last resort: review the patch yourself, build and test in staging, and understand that nobody is vouching for completeness.
All of these are worth doing, and quickly. But be honest about what they are: a patch applied to a runtime that otherwise gets no security fixes at all. They close PHP2Shell. They do not close the next one. The NCSC's own advice is that organisations on older versions should move to a fully supported release.
4. Apply interim mitigations, but don't rely on them
Where you cannot patch today, the PHP advisory describes temporary measures to reduce exposure to specific attack paths, including setting session.upload_progress.enabled = 0 and restarting every worker. Put internet-facing legacy systems behind a web application firewall with PHP2Shell rules enabled, or restrict access to known users or a VPN. If none of that is possible, follow the NCSC's advice and take the system offline until it can be properly fixed.
The PHP team is clear that no configuration change fully closes these vulnerabilities. Mitigations buy time; they are not a fix.
5. Look for signs of compromise
Exploitation is most likely to show up as PHP doing things it shouldn't. Alert on and review:
PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells, interpreters or download tools such as sh, bash, python, curl or wget.
Reverse shell patterns and quick reconnaissance commands (whoami, id, uname -a) run from the web server.
New or modified files in the web root, unexpected cron jobs, scheduled tasks or user accounts.
If you find something, isolate the host, preserve web server and PHP logs, and rotate every secret that host could see: database passwords, API keys, tokens and certificates. Given the memory disclosure path, rotating secrets on any exposed host that ran unpatched is sensible even without evidence of compromise.
The harder conversation: legacy applications
Here is the uncomfortable truth PHP2Shell exposes. Most organisations still running PHP 5 or 7 are not doing so by choice. They are doing so because:
the application was built years ago by a supplier who has since moved on, or by someone who has left the business;
nobody fully understands how it works any more, so nobody wants to touch it;
upgrading PHP breaks things, and there is no test suite to show what;
it still does its job, so it never makes it to the top of the priority list.
Those applications are often business-critical: the pricing engine, the client portal, the system the operations team lives in every day. And they are exactly the systems that AI-assisted vulnerability research is now making easier to attack.
Patching the runtime is the right first move this week. The right move this quarter is a plan for each legacy application, which usually falls into one of four options:
Upgrade in place. Bring the code up to a supported PHP version, with tests added around the risky areas. Often less painful than people fear, particularly with modern tooling. For Laravel applications, see our Laravel rescue and scaling work.
Re-platform. Move to a supported framework or hosting model while keeping the core logic. This is the heart of our legacy systems modernisation service.
Rebuild. Where the application has drifted far from what the business needs, rebuild the parts that matter.
Retire. Some systems can be switched off or replaced with an off-the-shelf product. That is a perfectly good outcome.
Whichever route you take, the goal is the same: software that has an owner, runs on supported components, and gets patched as a matter of routine rather than as an emergency.
How Scaffold can help
Inheriting other people's software is a core part of what we do. Through our Software Rescue service, we regularly take on applications from suppliers who have stepped away, from teams who have lost key people, and from businesses who simply need someone to take responsibility for a system that matters to them.
Our approach is deliberately calm and structured:
Assess. Through a technical audit, we review the application, its hosting and its dependencies, and give you a clear, honest picture of the risk, including where it stands on issues like PHP2Shell.
Stabilise. We get it onto supported, patched foundations, close the urgent gaps and put proper monitoring in place.
Look after it. We take ongoing responsibility for keeping live platforms secure, patched and healthy, at a fixed monthly price so there are no surprises. Find out more about our support.
Evolve it. When you are ready, we help you modernise, rebuild or retire it, focused on what actually matters to your business.
We are ISO 27001:2022 certified, and we have spent more than 15 years building and looking after software in operationally complex and regulated environments.
If you are not sure where your PHP applications stand after this week, or you have a legacy system that nobody wants to touch, tell us about it or get in touch. We will start with an honest conversation about what you have and what it needs.
