Critical vulnerability in PHP: how we handled it, and what we take away from it
The PHP vulnerabilities that became public this week had been sitting in the code for years. The weakness behind them was known, but nobody had managed to show how it could be exploited. That changed when security researchers started using AI as a tool and found a chain of flaws that together gave full control of the server. When the fix arrived on Wednesday 21 October, we had 24 hours to update, shield or shut down the solutions we run. We did it. Even so, PHP2Shell is unlikely to be a one-off. When AI makes it faster to find old flaws, it also makes it faster to exploit them, and we have to expect incidents like this to come more often.
Exponential growth, time is critical (Cloudflare CEO, 22 October):
A flaw that hid for years
The vulnerabilities have been named PHP2Shell. They are rated 9.2 out of 10 for severity and, in the worst case, let an attacker run their own code on the server without logging in. The most instructive part, though, is how long they had been there rather than what they do.
The weakness has a long history. As early as 2004, security researcher Stefan Esser showed that PHP could be attacked when a program ran out of memory. In 2020 a related bug was reported to PHP, and in 2024 OSTIF and Quarkslab found a similar problem without being able to show it was exploitable. The oldest of the new attack paths goes back to PHP 5.4, released in 2012.
Why did it take so long to find them? Because no single flaw is dangerous on its own. An attack requires several things to happen in the right order. The attacker has to make the server run out of memory with a request that still stays within the size limits. PHP has to stop with an error at a very specific moment, while internal data is only half set up. Finally, a new request to the same server process has to pick up the leftovers. Which attack paths work also depends on how PHP is configured on the server.
The new round began in August, when security firm Calif found the first attack path through OpenAI's Patch the Planet initiative. Wiz and OpenAI are also credited as discoverers. AI was an important tool, but Calif itself stresses that the discovery required deep knowledge of PHP's history, and that no language model finds flaws like these from simple prompts. The bug was reported to PHP on 11 August. The fix came on 21 October.
The complexity applies to defence too. A firewall rule can stop known attack patterns, but not necessarily every variant. The PHP project was therefore clear that only an update gives full protection.
How we responded
When a critical vulnerability becomes known, there are in practice three options. You can shut the solution down, you can limit the risk with temporary measures, or you can update. Only the last one solves the problem, but it is not always possible right away. We used all three.
We set clear priorities. Frontkom PaaS, the platform we are responsible for ourselves, came first, and Platops handled it together with our hosting partner. Solutions on other platforms followed. There, the project teams were responsible for their own solutions, Solution Engineering followed up projects and clients, and Platops helped where needed.
To keep track, Platops set up an internal status page early on with every affected project. For each solution it showed the hosting environment, PHP version, chosen measure and status. The page became the single source of truth for the whole organisation, and it made it possible to steer the work through the day, evening and night without anything falling through the cracks.
- Tuesday 20 October: PHP announces a critical security update for Wednesday at 16:00 Norwegian time. Details are withheld.
- Wednesday 05:43: Our hosting partner for Frontkom PaaS starts work on platform-level measures.
- Wednesday 09:11: Internal alert on our side. All projects outside Frontkom PaaS report their environment and PHP version by 15:00, and everything running PHP 8.1 or older is flagged.
- Wednesday 12:51: A virtual patch in the firewall is active for all sites on Frontkom PaaS. They are shielded before the fix has even been released.
- Wednesday afternoon: Old solutions we cannot secure quickly are taken offline in agreement with the clients. Solutions on end-of-life PHP versions get temporary settings that make the attack harder.
- Wednesday 16:00: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are released.
- Wednesday evening: The whole world updates at the same time. GitHub and the package repositories are overloaded.
- Wednesday 21:22: New base images for Frontkom PaaS are ready. We roll out the update to every site on the platform, in both production and development environments.
- Overnight and Thursday morning: Our own servers, AWS environments and clients' own infrastructure are updated one by one.
- Thursday morning: All known solutions are updated, shielded with temporary measures or shut down.
- Thursday and Friday: Further clean-up. Client follow-up. Summary.
These were the measures we and our partner carried out:
- Virtual patch in the firewall. Our hosting partner added a rule to the web application firewall that blocked known attack patterns for all sites on Frontkom PaaS, several hours before the fix arrived.
- Shutdown. Old solutions that could not be secured quickly were switched off in agreement with the clients. For some, it was a natural time to retire the solution for good.
- Temporary PHP settings. Where updating was not possible right away, we changed PHP's settings for memory use, request size and upload progress, as the PHP project recommended. The settings were built into the images themselves, so they would not disappear on the next deployment.
- Upgrades from end-of-life versions. Solutions on PHP 8.1 were upgraded to a supported version and deployed the same evening or the following morning.
- Updates. On Frontkom PaaS we rolled out new base images. Elsewhere we rebuilt Docker images with a patched PHP version, or updated PHP directly on the servers.
- Verification. We checked the PHP version in production for every solution, and went through the solutions that could only be shielded for signs of compromise.
So far we have found no sign that the vulnerabilities have been exploited against solutions we run. We are following the situation closely.
One problem, many environments
The incident showed clearly how much the hosting environment matters. On Frontkom PaaS, our hosting partner provides monitoring and incident response around the clock, all year. A single firewall measure protected every site on the platform at once, and the update was rolled out centrally as soon as the new base images were ready. It took time because the whole world was waiting for the same images, but the work was predictable.
Outside the platform, the picture was more mixed. Some solutions run on their own servers, where we had to wait for the operating system vendor to publish patched packages. Others use Docker images with a fixed PHP version locked into the build process, and each of them had to be updated and rebuilt. Some clients run their infrastructure themselves. There we could advise and help, but the update itself was theirs to make.
A version number does not always tell the whole story either. At one hosting provider, the fix was applied to the existing PHP version, so the server still reported the same version number as before. We had to check the build date to know the solution had in fact been patched.
Up-to-date technology is the best preparedness
The most important lesson is about how unevenly the vulnerability hit, depending on how up to date the technology was beforehand, more than about the vulnerability itself.
Solutions running a supported PHP version on Frontkom PaaS only needed a new deployment. Solutions on PHP 8.1, which no longer receives security updates, had to be upgraded to a newer version the same evening, with testing and deployment under time pressure. For solutions on PHP 7.4 or older there was no quick route to a full fix, only temporary measures that reduce the risk. There, the real solution is a bigger upgrade or a move to a new platform.
None of the solutions left without a full fix were running a supported PHP version.
The next deadline is close. PHP 8.2 gets no security updates after 31 December 2026, in just over ten weeks. A security update should be routine. When it turns into a rush job, it is usually because upgrades have been put off for too long.
What should you check now?
Ordinary web users do not need to do anything. If you are responsible for a website, this is where to start.
- Find out which PHP version the site runs. PHP 8.1 and older receive no security updates and must be upgraded. PHP 8.2 only receives them until the end of the year.
- Check that the update from 21 October is installed. The patched versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If your hosting provider uses its own packages, the fix may sit in an older version number. Ask for confirmation.
- A firewall is a good extra layer, but none of the temporary measures give full protection. The update has to be installed regardless.
- Ask for a review of the logs for unusual activity over the past week.
- Clarify who is responsible for updates, and whether they can act on the same day next time.
If you need help, get in touch.
When flaws are found faster, testing has to keep up
PHP2Shell shows that AI is changing the pace of security work, on both sides. The same tools that helped the researchers find the flaw can help attackers build exploits from a security update. A security test once a year cannot keep up with that.
We use a tool of our own that we keep developing. It tests web solutions and APIs with AI agents and language models running on Frontkom's own hardware, so no information about the client or the vulnerabilities leaves Frontkom. The tool cannot guarantee it will find flaws like PHP2Shell, but it uses the same approach: the agents map the solution, follow the leads and chain weaknesses together.
The tool can test from the outside without logging in, with test accounts or with access to the source code (black box, gray box and white box). The simplest place to start is regular external tests against production, monthly or quarterly. The tests do not write data, and they back off if the solution shows signs of load. The other two forms require more preparation and closer collaboration with the client, but give more depth in return.
We test the tool regularly against OWASP Juice Shop, a deliberately vulnerable online shop that OWASP built for practising on and testing security tools. In a white box test, the tool found all 10 known vulnerabilities we used as the answer key, from SQL injection and XSS to XXE, NoSQL injection and open redirect.
If you are unsure whether your site is up to date, or want to know more about how we test proactively, I am happy to talk. Get in touch at erlend@frontkom.com.
Erlend Strømsvik, CTO and partner at Frontkom
Sources
- Oppdatert varsel: To kritiske sårbarheter i PHP, Norwegian National Security Authority (NSM), 21 October 2026 (in Norwegian)
- PHP October 2026 Security Release, php.net, 21 October 2026
- php2shell, Calif, October 2026
- Critical PHP security release, amazee.io status, 21 October 2026
- OWASP Juice Shop, OWASP
- Nettsider nede etter sikkerhetsalarm, NRK, 21 October 2026 (in Norwegian)
- PHP-oppdatering ute: Installer snarest!, kode24, October 2026 (in Norwegian)
Transparency note: This article is based on Frontkom's own handling of the vulnerabilities and publicly available sources. AI has been used as an editorial aid for language and structure.
