PHP2Shell and the end of the once-a-year pen test

On October 21, 2026, PHP shipped emergency fixes for two flaws that let anyone on the internet run code on a PHP web server, with no login. The weakness behind them had been flagged in 2024 and then sat, partly because nobody had proved it was exploitable.

In 2026, researchers working with AI models proved it within days. Exploit attempts started before the fix shipped, and details leaked a day ahead of schedule.

That sequence is the real story of PHP2Shell. The bug matters, but speed matters more. It shows what security testing has to look like now that both sides have AI. And if your mobile app talks to a PHP backend, it’s your story too.

What broke inside PHP

PHP2Shell is the name for two flaws in the PHP engine itself: CVE-2026-109618 and CVE-2026-109619. The PHP project rates both 9.2 (critical) on CVSS v4.0. The score marks them as high complexity, but they need no login and no user interaction, and PHP has validated working remote code execution. Both live in the same place: what PHP does when a request dies of a fatal error, most often running out of memory.

CVE-2026-109618 (out-of-memory corruption). When PHP hits its memory limit, it drops what it is doing at once. If that happens while internal request data is only half built, the clean-up at the end of the request treats that broken data as valid. An attacker who can shape that memory can turn the crash into code execution. The memory pressure comes from the request body itself, as PHP parses form fields and uploads, so the application does not need to accept file uploads for the path to be reachable.

CVE-2026-109619 (stale global state). A PHP worker handles one request after another. A fatal error can cut a request short before some shared state is reset, and the next request on the same worker can use a pointer into memory that has already been freed. One request plants the condition; the next one triggers it. PHP's advisory names the session upload progress feature, which is on by default, as one confirmed trigger.

The key detail for defenders: application-level controls cannot stop this. The flaws sit in the engine that handles the request, not in your code. On Apache with mod_php, which PHP rates the highest-risk setup, a demonstrated exploit completes before any application code runs, so login checks, input validation and framework security features never get a chance to act. Other setups are not safe either: every PHP install that serves web requests is in scope, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The oldest affected code path goes back to PHP 5.4.0, released in 2012.

Why a server bug is a mobile problem

PHP2Shell is a server flaw. It does not touch an app binary. But mobile apps are thin clients: the logins, KYC documents, profile photos and payment requests they collect all land on backend APIs, and some of those APIs run on PHP, often through frameworks such as Laravel and Symfony.

That makes the usual mobile defenses irrelevant to this attack. Certificate pinning, obfuscation and root detection protect the app. They do nothing for the server it talks to. An attacker who sends crafted requests to your API host does not need to break your app at all; they go after the server where your app's data ends up.

And mobile backends rarely stand alone. The admin panel, the content service behind the app's news feed and the old upload endpoint from three releases ago all count. If any of them runs an unpatched PHP, it is a way in.

Flagged in 2024, proven in 2026

According to the PHP Foundation, a developer it had contracted found the out-of-memory root cause in 2024. A separate external audit that year turned up a related bug. Exploitation was unproven, the possible fixes each had real costs, and the work stalled for months. The Foundation itself calls the delay a structural failure.

What changed in 2026 was proof. Researchers at Calif, working inside OpenAI's Patch the Planet program, used OpenAI's GPT-5.6 Sol to help find and prove remote code execution, and reported it to PHP in August. Wiz found the flaws independently later in August, using its own AI research system with Google's Gemini 4 Argon and GPT-5.6 Sol. One researcher told CNBC that, with AI, reproducing the exploit locally was quick, where it once would have taken his team multiple weeks.

The models’ role is worth getting exactly right. They did not invent a new class of bug. Calif's researcher started from a hunch that relatives of an old PHP memory-limit bug were still in the code. The models made it cheap to go from "this looks risky" to "here is a working exploit." That step, proving exploitability, is what turned a known weakness into an emergency release.

The same speed works for attackers

AI does not care who is holding it. If a model can help a researcher turn a suspicion into a working exploit in days, it can help an attacker turn a published patch into one in hours.

PHP2Shell showed what that looks like in practice:

• Exploit attempts came before the fix. Amazon Threat Intelligence reports an exploitation attempt on its honeypots on October 17, four days before disclosure, and says it is unclear how the attacker got the information.
• The embargo broke. CVE numbers circulated on October 20, and PHP moved its release up a day.
• Governments did not wait. Reuters reported that public bodies in the Netherlands, Finland, France and Denmark took websites and services offline as a precaution while they patched.
• Reports on exploitation disagree. Amazon, based on its honeypot network, describes the flaws as broadly exploited. CISA said on October 21 that it had not yet seen exploitation. No breach through PHP2Shell had been publicly confirmed as of October 22.

The lesson is not that every PHP server was hacked. It is that the gap between disclosure and attack is now very short. Amazon's advice is to measure patch and mitigation timelines in hours, not in the 7- or 30-day windows many policies still assume.

What to do this week

1. Find every PHP server behind your app. List every host your mobile app calls, plus the admin panels, CMSs and internal tools around them. Ask one question of each: what version of PHP is it running? Include vendor appliances and container images that bundle PHP; Palo Alto Networks, for example, has confirmed that all PAN-OS and Panorama versions are affected.
2. Upgrade, then restart every PHP worker. The fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. A running worker keeps the old code in memory, so the fix only takes effect after a restart. Check container images and base images, not just hosts.
3. Treat PHP 8.1 and older as an emergency. PHP published source backports for 7.4, 8.0 and 8.1 for teams that build from source. Versions older than 7.4 get no fix. CISA advises taking systems that cannot be updated offline until they can be.
4. Use workarounds only to buy time. PHP lists interim mitigations, such as disabling session upload progress and capping request sizes at the proxy. PHP is clear that only the update is a complete fix. WAF rules from cloud providers help as one layer, but one of the two flaws sits largely outside what a web application firewall can inspect.
5. Look back to October 17. Since attempts started before disclosure, check logs from that date for unusual multipart requests, bursts of memory-limit errors or HTTP 500s, and PHP processes spawning shells. PHP warns that a clean error log does not prove a server is safe.

Testing has to move at the same speed

PHP2Shell is a warning about how most security testing is still scheduled. A yearly or quarterly pen test checks an app at one moment. Between those moments, a dependency changes, a runtime turns out to be vulnerable, or a new release adds an endpoint, and nobody re-checks until the next cycle.

Attackers no longer work on that calendar. With AI, they can probe, chain findings and build working exploits continuously. Defenders need testing that does the same: tools that act like an attacker, prove which findings are actually exploitable, and run again after every change.

This is what we’re building at Appknox: an agentic offensive pen testing module. AI agents probe mobile apps and the APIs behind them the way an attacker would, and show which weaknesses can really be exploited, release after release, not once a year.

The PHP flaw sat for two years because nobody proved it was exploitable. AI has made that proof cheap, for both sides. The teams that keep up will be the ones that test continuously and prove their own weaknesses before someone else does.

Your app talks to more servers than you think. See which of them an attacker can actually reach: book a demo and we’ll test your app and the APIs behind it.