On 21 October, websites belonging to UK councils, the Metropolitan Police and governments across Europe went offline within hours of each other (Insurance Business). Their own operators had switched them off as a precaution, following advice from the National Cyber Security Centre to update PHP immediately or consider taking sites offline until they could (NCSC). PHP is the language running on the server behind around 70% of websites, including those built on WordPress, Drupal and Magento.
Two critical flaws in PHP, known as PHP2Shell, could let an attacker run their own code on a web server without logging in. PHP released the fix at around 3pm UK time that day, and major hosting providers had applied it by the following morning, which closed the window of risk for the sites they host (Insurance Business, Flow Ninja). What remains is a short list of exceptions that site owners can check against their own setup.
Key takeaways
- On 21 October 2026, PHP released fixes for two critical flaws, known as PHP2Shell, that could let an attacker run code on a web server without logging in.
- Councils, government bodies and the Metropolitan Police took websites offline as a precaution, following NCSC advice to patch or consider disconnecting.
- Researchers found the flaws with the help of AI, in code that dates back to PHP 5.4, released in 2012.
- Major hosts applied the fix within hours, and visiting an affected site never put a visitor’s own device at risk.
- Every affected Roar-managed site was patched and safe on 21 October, and none was offline for longer than six hours.
- A lower-risk third flaw, sites on PHP 8.1 or older and servers that have not been updated are what remain to resolve.
What happened on 21 October?
PHP released emergency security updates on 21 October for two critical vulnerabilities in its core interpreter, CVE-2026-109618 and CVE-2026-109619, both rated a level 9.2 for severity.
Either flaw could allow an attacker with no login to run code remotely on an affected web server.
The flaws affect every PHP installation that serves web requests. The fixed versions were released at around 3pm UK time.
Why did websites go offline?
The outages were a precaution taken by site operators while they prepared to patch. The NCSC told organisations to update to the fixed version and to consider taking websites offline if they could not upgrade straight away. Thankfully, no successful break-ins had been confirmed by the afternoon of 21 October.
In the UK, the websites of Edinburgh and Oxford councils and the Metropolitan Police went down, and error messages appeared on the Bristol, Lambeth and Barnet council sites. The Office for Budget Responsibility also took its site offline, although No 10 said no large public-facing critical services were affected.
Across Europe, government websites in France, Denmark, Finland and the Netherlands were temporarily taken down, including the site of the Dutch national cyber security agency. The scale of the response reflects how widely PHP is used, since it runs on the server behind around 70% of websites.
How were the flaws found?
Researchers at Calif, OpenAI and Wiz found the flaws with the help of AI. Calif’s team used OpenAI’s GPT-5.6 Sol, and Wiz used its own Wiz Atlas agent alongside Google’s Gemini 4 Argon and GPT-5.6 Sol.
The vulnerable code dates back to PHP 5.4, released in 2012. A team working on an audit two years earlier had found a vulnerability with the same root cause and alerted the PHP Foundation, but a fix was never rolled out, and the Foundation has since described the delay as a structural failure caused by its security team’s decision process and lack of resources.
PHP had planned the release for 22 October, but details began circulating publicly on 20 October, so the project brought the release forward by a day. AI helped find the flaws, and people at PHP and the hosting companies wrote, released and installed the fix, a division of labour covered in more detail in why AI still needs people.
Is it safe now?
A server running one of the fixed PHP versions is protected against both PHP2Shell flaws, and the NCSC has confirmed the issue is fixed. The PHP security team has said that applying the official update is the only permanent defence.
Major hosting providers moved within hours, with SiteGround putting mitigations in place across all its servers seven hours before PHP released the fix and applying the official update the same day (SiteGround). WP Engine finished patching at 01:19 UTC on 22 October, and Automattic said sites on WordPress.com, WordPress VIP and Pressable were already protected.
Early attack attempts also appear to have failed. The PHP security team said none of the proof-of-concept exploits leaked before the release were functional, and Cloudflare, Amazon, watchTowr and Patchstack all tagged the attempts they detected before disclosure as unsuccessful. On 27 October, Wiz said it had still not seen a successful end-to-end exploitation in its own telemetry.
Browsing an unpatched website cannot compromise a visitor’s own computer or phone, since the risk sits with the site and the data stored on it. Ordinary internet users have nothing to patch on their own devices.
How we handled it at Roar
We manage websites built on PHP, and four of them were affected: three main client sites and our own. Our development team took control as soon as the issue broke, taking the sites offline, monitoring them, and then applying and testing the fixes as soon as PHP released them. Every affected site was patched and safe on 21 October, and the longest any of them spent offline was six hours.
Customers still got through while the sites were down. Phone calls and emails to the affected businesses rose during that window, so enquiries kept arriving through other channels.
What’s still being fixed?
A third flaw was disclosed on 23 October and will be fixed in PHP’s next regular release. The PHP Foundation says it needs a very unlikely combination of configuration and application code, and a single specific setting. No attacks targeting it have been reported, and servers that applied that setting on 21 October need to do nothing more.
Sites on older PHP versions face a larger problem. PHP 7.4, 8.0 and 8.1 have no official release, only minimal source backports for those who build PHP themselves, although some vendors and Linux distributions have issued their own patched builds. On 22 October, 35.8% of WordPress sites were running PHP 8.1 or older.
Exploitation of unpatched servers is now confirmed. CISA added both flaws to its Known Exploited Vulnerabilities catalogue on 26 October and gave US federal agencies until 29 October to patch. Of 30,027 sites checked between 21 and 25 October, 59% showed a PHP version from before the fix, although distribution builds can carry the fix under an older version number.
What should website owners check?
Site owners should ask their hosting provider to confirm in writing that the fix is installed on the server behind every site they run, including staging copies. Older projects on separate servers may run a different PHP version and need the same check.
Updating WordPress, plugins or themes does not fix PHP2Shell. WordPress.org says the issues are not specific to WordPress and no WordPress update is required or planned. The fix has to be applied to PHP on the server.
Sites on PHP 8.1 or older need a plan to move to a supported version or onto a vendor’s patched build. PHP 8.2 is fixed but reaches end of life on 31 December 2026, so sites on it face the same decision before the end of the year.
Amazon recorded the first exploitation attempt on 17 October, four days before the fix was released, so sites that were patched late should be checked for signs of compromise from before the update.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, that could let an attacker run code on a web server without logging in. Both are rated 9.2 for severity and were fixed on 21 October 2026. The flaws sit in PHP itself, so they affect WordPress, Drupal, Magento and custom sites running on an unpatched server.
Why did websites go offline on 21 October?
Websites went offline because their operators switched them off as a precaution while preparing to install PHP’s fix. The NCSC advised organisations to consider taking sites offline if they could not update straight away. UK examples included Edinburgh and Oxford councils and the Metropolitan Police.
Is PHP2Shell fixed?
PHP2Shell was fixed on 21 October 2026, and a site is protected once its server has installed the update. Major hosts including SiteGround and WP Engine had applied it by the morning of 22 October. A separate, lower-risk flaw, CVE-2026-115560, will be fixed in PHP’s next regular release.
Does updating WordPress fix PHP2Shell?
Updating WordPress does not fix PHP2Shell, because the flaws are in PHP, the server software WordPress runs on. WordPress.org says no WordPress update is required or planned for these issues. The fix has to be applied to PHP on the server, usually by the hosting provider.
Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both PHP2Shell flaws. Sites on PHP 7.4, 8.0 or 8.1 need a vendor’s patched build or an upgrade, as PHP has published no official release for those versions.
Can visiting an unpatched website put me at risk?
Visiting an unpatched website does not put a visitor’s own device at risk from PHP2Shell. The flaws let attackers target the server and the data stored on it. Ordinary internet users have nothing to patch on their own computers or phones.
What happens next
The NCSC described the scale of the issue as unprecedented and warned it is unlikely to be the last. AI found two flaws that had sat in PHP’s code for more than a decade, after a human audit had flagged the same root cause and the fix stalled. For website owners, the lasting action from 21 October is a simple record of which PHP version each site runs and who updates it, so the next emergency patch can be applied the day it lands.
