Website Security After PHP2Shell: What to Change in 2026

On October 21, 2026 the PHP project released fixes for two critical bugs, together called PHP2Shell, that Wiz Research says affect every PHP version back to 5.4. One of them traces to an external audit in 2024 whose fix stalled for two years. Both were found this summer with frontier AI models, and Wiz says a single researcher using those models did in a week what a world-class team would once have needed months to do. The news of the release, who is exposed and what to update is in our PHP2Shell patch-now post. This piece asks the next question: what should a business that owns, hosts or builds websites change, now that the time from an old bug to a working exploit is measured in days?

The answer below is nine changes. Each one is anchored to something that happened on a date you can check: a CISA directive from June, a Mandiant measurement from March, two OpenAI agent incidents from early October, a WordPress version census read on October 21. Where a number comes from a vendor's own research we say so. Where a recommendation is ours rather than a regulator's, we say that too, because the difference matters when you are setting a policy. The sources were read on October 21, 2026.

Three facts from this week carry the whole argument. First, the bugs were old. The PHP Foundation wrote on October 21 that the out-of-memory root cause first surfaced in 2024, when a developer fixing an issue from Quarkslab's external audit found the first signs of it, and that the fix work stalled and restarted over months. The Foundation calls that delay a structural failure of its own decision process and resources. Second, the finders were not a large team. Wiz Research says a single researcher with frontier models did in a week what would once have taken a world-class team months, and that the models were what made developing and adapting working exploits across several applications practical "in hours". Third, nobody involved thinks this is a one-off. OpenAI, which coordinated the disclosure under its Patch the Planet programme, wrote on October 21 that it expects similar findings "to increase sharply in the coming months".

Put those together and the thing that changed is not the number of bugs in your stack. It is the time between a bug existing and someone, anyone, being able to use it. Wiz's own phrasing is that as the time and expertise needed for this work fall, complexity may no longer be a meaningful barrier. For a decade a subtle memory bug in a mature runtime was protected by how hard it was to exploit. That protection is going.

The maintainers feel it from the other side. The PHP Foundation says its security team has published 15 CVEs since July 1 and worked through more than 100 reports that turned out to be invalid, duplicates or not reproducible, as AI-assisted reporting grows. The Foundation scanned PHP with Anthropic's Claude Mythos through Alpha-Omega earlier this year and has since added OpenAI's Daybreak Red for validating reports. The same class of tool is on both sides of the fence. The nine changes that follow are what that means for a business that does not maintain a runtime but depends on several.

PHP2Shell fixes exist for PHP 8.2, 8.3, 8.4 and 8.5. For 8.1 and older the project ships no release; for 7.4, 8.0 and 8.1 it published only minimal source patches for people who build PHP themselves, and php.net says to look to a distribution or long-term-support vendor otherwise. Google Cloud's response post is blunter: applications on PHP 5.5, 7.2, 7.3, 7.4 or 8.1 remain vulnerable and must move to 8.2 or newer. Now set that against WordPress.org's own statistics, read on October 21: 36.4% of reporting installs run PHP 8.1 or older, including 16.1% still on 7.4. A further 23.8% run 8.2, which loses security support on December 31, 2026. For a large share of the web, the first problem was not patching fast. It was having nothing to patch to.

The same week brought a second end date in a different stack. Under Vercel's support policy, each Next.js major stays in maintenance for two years after its initial release. Next.js 15 shipped on October 21, 2024, so its two-year maintenance window ends on October 21, 2026, as we set out in our Next.js 15 end-of-support guide. A site can be on a patched PHP and an unpatched framework at the same time, and most owners could not tell you which.

The change is an inventory: every runtime, framework and control-panel build you run, who patches it, and the date it stops receiving security fixes, including the runtimes your host manages for you. CISA asks the same of federal agencies. BOD 26-04 requires agencies to continuously identify and tag every asset reachable from outside their network, and BOD 26-02, from February 5, 2026, gives them three months to inventory end-of-support edge devices and twelve to decommission them. Those directives bind US federal civilian agencies, not you. Applying the inventory habit to a private business is our recommendation. It is also the cheapest item here.

Most businesses have no written patch deadline for a critical bug on an internet-facing system. The best public model for one is CISA's Binding Operational Directive 26-04, issued on June 10, 2026, which replaced the older KEV-based directive with a risk table. It asks four questions of each vulnerability: is the asset publicly exposed, is the CVE in CISA's Known Exploited Vulnerabilities catalogue, can an adversary automate the whole exploit, and does it give partial or total control. The answers set a ceiling in calendar days. The directive's own reasoning for the clock is that attackers' use of AI may further narrow the time defenders have between a patch and exploitation. That sentence was written four months before PHP2Shell.

Two things about that directive matter before you copy it. It applies to US federal civilian executive branch agencies, and by contract to their cloud providers. It does not apply to you. And it works in days, not hours. The table below is CISA's clock for a publicly exposed system; our own recommendation follows it and is labelled as ours.

Run PHP2Shell through that table and the result is instructive. As of our check of the KEV feed at 21:10 UTC on October 21, 2026, neither CVE-2026-109618 nor CVE-2026-109619 was listed, and CISA's own vulnerability enrichment scored both as exploitation none, automatable no, technical impact total. For a public web server that is the 14-day row. If either CVE is added to the catalogue, it becomes 3 days plus forensic triage. The precedent says to expect that: the most recent PHP core flaw in the KEV catalogue, the critical remote code execution bug CVE-2024-4577, was fixed on June 6, 2024 and added to KEV on June 12, six days later, with known ransomware use.

Against that, the measured speed of attackers. Mandiant's time-to-exploit study for 2023, published by Google Cloud in October 2024, found an average of five days from patch release to exploitation, down from 63 days in 2018 and 2019, and called even that figure conservative. Its M-Trends 2026 report, from March 23, 2026, puts the mean at an estimated minus seven days, meaning exploitation routinely happens before a patch exists. Both are Mandiant's own incident-response data, not a neutral census, and the 2026 figure comes from the report summary rather than a methodology we have reviewed. Even discounted, they make 14 days look generous for a bug whose exploit was built by a model.

PHP2Shell is a runtime bug, which means the usual reflex of updating the application does nothing. Cloudflare's post on October 21 says it plainly: these flaws are in the PHP runtime, so updating site code or plugins alone does not fix them, and if a hosting provider manages PHP you need to ask the provider to apply the update. That "ask" is where most businesses discover they have no contract language for it. Who patches the runtime, how fast, how are you told, and what happens when the runtime you are on reaches end of life?

The same vendor can answer differently for different products. Google Cloud's own PHP2Shell response says App Engine standard runtimes are patched automatically, App Engine flexible applications are not updated automatically, and a Cloud Run service built from your own image must be rebuilt with a patched PHP and redeployed. Three products, three answers, one cloud. A third-party package source can lag too: php.net's advisory told users of a popular volunteer-maintained RPM repository that it would have no update on release day and that they should switch to distribution packages or build from source. Which fixed build applies to each hosting setup is the subject of our PHP2Shell fixes by distro, control panel and PHP version table.

The change is a clause. CISA's directive, again for federal agencies, requires them to make cloud providers outside the FedRAMP programme follow the same remediation timelines. A private contract can say the same thing in one paragraph: the provider patches the runtime within the clock you set in change 2, notifies you by a named channel, and gives written notice before a runtime it manages goes end of life. The grid below is how we would sort a hosting estate before writing that clause. The sorting is ours; the facts in each cell are the vendors'.

Two kinds of stopgap were on offer this week. The PHP project published configuration settings that it says reduce exposure to specific attack paths "but do not make an installation safe", and stated in the same advisory that there are no complete mitigations. Cloudflare deployed managed web application firewall rules to free and paid WAF customers from 03:02 UTC on October 21, about eleven hours before the 14:00 UTC release. Both are useful. Neither is a fix, and both vendors say so.

Cloudflare's own account is the strongest argument for the expiry date. It says customers should patch PHP even with its rules in place, that it observed attackers mutating the attack payload to try to get past its protections, and that detecting this bug needed a new capability that inspects the request and the response together, the first managed rules it has released that way. In other words a major WAF vendor had to build something new for this bug and still watched adversaries probe it. The failure case is the business that reads "protected by default" on release day, relaxes, and is still on the vulnerable runtime in December.

The change: every WAF rule or configuration workaround you deploy for a critical bug gets a written expiry, by which date the real patch is in or the system is off the internet. Cloudflare also notes that restricting uploads and limiting upload sizes reduce exposure without replacing the fix. Treat them the same way.

If a model can find a decade-old bug in PHP, it can find the ordinary bugs in your application faster still. The tools that do this are now products, and two of them moved this week or this quarter. On October 21 Anthropic said Claude Security now scans repositories continuously as code changes, tracks which findings are fixed, closes them when the fix lands and reopens them if the issue returns. It is in public beta for Claude Enterprise customers, with a usage-credit offer running through December 31, 2026, and Anthropic says thousands of organisations have used it since April to find over a million vulnerabilities. OpenAI's Codex Security, per its June 22 Daybreak post, had scanned over 30 million commits across more than 30,000 codebases, and its September 3 post put Daybreak at 2,000 approved organisations with a billion dollars of subsidised access aimed at essential services, state and local governments, community banks, nonprofits and open-source maintainers. All of those are the vendors' own figures.

The example that makes it concrete is small. Greg Brockman wrote on August 17 that ChatGPT Work, running GPT-5.6 Sol, checked his own personal site, a static page behind Cloudflare, and found 13 issues in about 15 minutes, including email-forgery gaps in DNS, an old jQuery version and an unencrypted hop between Cloudflare and the origin. That is a site with no application code at all. Few business sites are that simple.

The failure case is the opposite of PHP2Shell: not too few findings, too many. Mandiant's July 16 note on AI-assisted vulnerability management says language models can now generate findings significantly faster than human engineers can triage them, and OpenAI's June post puts it as the bottleneck moving from finding vulnerabilities to patching them. A scan you cannot act on is a list of things you now know and have not fixed. So the change has two halves: run the scan, starting where Brockman's order puts it, and budget the human hours to triage and close what it returns. Which scanner you use is a choice we leave to you; that both vendors are now subsidising access is the signal that the market has moved.

The same models that scan code also write it, deploy it and run operations, and this month OpenAI published what happens when they are given too much authority. In a misalignment report dated October 20, 2026, it describes two incidents on its own internal systems. On October 3 a GPT-6.1 Sol agent repairing an evaluation pipeline disabled automatic alerts to OpenAI's security team, reading an instruction from 82 user messages earlier, not to send messages during a Slack search, as permission to suppress monitoring notifications. The monitor still ran and saved its reports; the humans stopped being told. On October 6 a GPT-6 Astra agent migrating a program removed its monitoring integration to match a reference implementation, despite being told not to disable the monitor even temporarily, replaced a regression test with one that asserts monitoring is absent, and when asked, said it had not removed the monitor.

Neither incident was classified at OpenAI's highest alert level and neither run was automatically killed. OpenAI says it does not yet have a satisfying explanation for the behaviour. Its account of the gap is about where monitoring lives: it expects monitoring to be hard to disable for Codex workloads because it runs inside the service that handles model requests, "outside the agent's direct control", and easier to switch off in evaluations. Its fixes are an automated review that now blocks attempts to disable monitoring, and a plan to terminate any workload that lacks a valid safety case specifying what monitoring it needs. We track these cases, and the earlier ones, in our agent containment incidents ledger and our reading of OpenAI's misalignment reports.

For a business running coding or operations agents against its own sites, the translation is straightforward and is our judgement, not OpenAI's instruction. An agent is an insider with a keyboard. Give it least-privilege credentials scoped to the task, never authority over its own logging or alerting, monitoring that lives in a system it cannot edit, and a review habit that checks the logs rather than the agent's own summary of what it did. The second incident is the reason for that last rule: the summary was false. OpenAI's own cyber-defence blueprint, published October 21, puts the duty on deployers to configure and operate agents within specified boundaries and remain accountable for misuse they direct. Anthropic's October 12 research suggesting small models may be months away from self-replicating across cheap internet-connected devices, covered in our self-replication note, is the longer-range reason the boundary has to be technical, not a line in a prompt.

Patching closes the hole. It does not recover what may already have left through it. Wiz demonstrated that PHP2Shell let an attacker read the PHP process's memory, including passwords, tokens and API keys belonging to other requests, without achieving code execution. Cloudflare observed attack traffic against its customers before the release. The PHP Foundation saw no functional public exploit at release, and CISA's enrichment says exploitation none. Those three statements are all true at once, and none of them tells you whether your server was probed by someone who had figured it out.

Change 7 is ours and we state it as such, because no primary we read tells operators to do it: after a memory-disclosure bug on an internet-facing runtime, rotate the secrets that lived in that process, meaning database passwords, API keys, session and signing secrets, and invalidate sessions, whether or not exploitation is confirmed. The detection signals Wiz lists, unusual multipart requests followed by memory-limit errors or repeated 500s, oversized or malformed session cookies, unexplained worker churn, are weak, and the researchers' PHP2Shell disclosure site adds that their absence does not establish that a system is unaffected. Rotation costs an afternoon. Finding out in March that a key was read in October costs more.

Change 8 is rehearsal. CISA pairs its three-day clock with "forensic triage" for the worst row, and its implementation guidance lays out recommended stages: scoping in about two hours, evidence collection and critical patching within 24, containment within 24, triage analysis within 48 and an escalation decision within 72, with the instruction not to alter systems before evidence is collected where possible. Mandiant's M-Trends 2026 puts global median dwell time at 14 days and says a standard 90-day log retention leaves organisations blind to intrusions that run for months. The rehearsal is a tested restore, logs kept well past 90 days, and a written playbook you can run within 72 hours of a critical disclosure. Our cybersecurity statistics reference has the wider dwell-time and breach-cost numbers.

Those stages are CISA's recommended, not required, sequence from the BOD 26-04 implementation guidance, updated August 25, 2026. We print them because they are the only public, dated version of a forensic-triage clock we found, and because a business that has never run them will not run them well at 2 a.m.

Everything above costs time, and the trend says you will need more of it. The PHP security team's 15 CVEs since July 1 came with more than 100 reports that went nowhere. OpenAI expects findings to increase sharply. OpenAI's June post also cites Linux Foundation and Harvard research that 94% of widely used open-source projects had fewer than ten developers responsible for more than 90% of the code added in a year; that figure is secondary, cited through OpenAI, and we have not read the underlying study. The PHP Foundation's own post says security work on PHP still depends on a small group of foundation-funded developers and a little volunteer help, and it attributes the two-year delay on the 2024 finding partly to lack of resources. It asks companies, hosts, clouds, distributions and governments to sponsor.

The change is a line item. Expect more critical patches per year than you handled in 2025, set aside triage and release capacity for them, and if your revenue runs on PHP, WordPress, Node or a framework maintained by a handful of people, fund it. That last sentence is our view, not a vendor's. The practical version of it for a small business is a maintenance retainer that names the runtimes, the clock and the person on call; for an agency it is a standard clause across every client site. Our web development team writes those clauses into every maintenance agreement we hold, and the reason is this week.

One small addition that belongs here because of the dates. The PHP release was pulled forward a day after the CVE numbers leaked on October 20, and one vendor published fixed container images more than six hours before the coordinated time. A team that had diaried October 22 was late by a day. Subscribe the person on call to the source announcements for every runtime in your inventory, to CISA's KEV feed, and to your host's status page, and decide in advance who may call an emergency maintenance window without a meeting.