PHP2Shell and frontier AI: what UK financial firms should do now

On 21 October 2026 PHP shipped emergency fixes for two critical flaws that let an attacker run code on a web server without logging in. AI labs and researchers using frontier AI models were among those who found and reported them. Within hours, governments, cyber agencies and large websites across Europe, Australia and Japan were taking sites offline as a precaution. Seven weeks earlier the FCA warned that AI-driven vulnerability discovery is outpacing firms’ ability to respond. PHP2Shell is that warning in practice. This piece sets out what happened, who was affected, what the NCSC, NSA and other agencies said, and the operating model UK financial firms need for the next one.

What happened

PHP is the language behind WordPress, Drupal, Magento and a large share of the web. On 21 October the PHP project released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two flaws, CVE-2026-109618 and CVE-2026-109619. Both score 9.2 on the CVSS v4 scale. PHP’s advisories describe the confirmed impact of both as unauthenticated remote code execution.

• Who is exposed. PHP says the risk covers “all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.” It considers the risk highest for mod_php.
• How far back it goes. Google Cloud gives the vulnerable range as every version from 5.4 to 8.5.11. PHP 8.1 and older no longer receive updates from the PHP project, though source backports were published for 7.4, 8.0 and 8.1.
• How it was found. According to the PHP Foundation, security firm Calif reported the root cause on 11 August during an audit run under OpenAI’s “Patch the Planet” programme, and OpenAI independently reported the same root cause that day. Wiz Research reported further vectors on 24 August and credits frontier models, including Gemini 4 Argon, with finding the flaws and building exploits.
• Why it went early. The CVE identifiers leaked on 20 October. PHP brought its release forward by a day, and the PHP Foundation says one vendor published patched images more than six hours before the coordinated release.

Our own SME guide, PHP2Shell: what UK small businesses should do now, covers the basics for firms without a security team. This piece is for regulated firms and their suppliers.

Who has been affected so far

As of the morning of 22 October, in the public statements we reviewed, no organisation had confirmed a breach through PHP2Shell. Several security firms, including watchTowr, Datadog and Patchstack, reported exploitation attempts on 21 October. CISA and Canada’s Cyber Centre said at the time of publication that they had not observed exploitation, and neither flaw was on CISA’s Known Exploited Vulnerabilities list. That picture can change quickly.

The visible impact so far is disruption, not compromise. Organisations took their own services offline while they patched:

Treat other outage lists with care. Some widely shared names, such as the Internet Archive and Asana, have not been directly linked to PHP in the reporting we reviewed.

In our view, the list makes one point clearly. Public bodies with mature security teams chose to switch services off rather than run exposed. For a bank or insurer, that choice touches impact tolerances, customer harm and possibly incident reporting. It needs to be pre-agreed.

What the NCSC, NSA and other agencies said

The advice was unusually consistent across countries: find every PHP installation, update immediately, apply the temporary mitigations if you cannot, and consider isolating or switching off systems you cannot fix.

One gap is worth noting. As of 22 October we found no PHP2Shell statement from the FCA, PRA, Bank of England or UK Finance. That is normal for a fast-moving technical alert, and it does not mean supervisors will not ask later how you responded.

Why this is the FCA’s review in real life

In September the FCA published a multi-firm review of how firms use and prepare for frontier AI in cyber resilience. Its headline finding reads: “Vulnerability discovery is accelerating faster than firms’ ability to respond.” The FCA also said frontier AI “is revealing whether firms have the right governance, risk ownership, engineering capacity and remediation processes needed to act on AI-generated vulnerability discovery.”

PHP2Shell shows both halves of that. Discovery was fast and AI-assisted. The PHP Foundation says its team has published 15 CVEs since 1 July and “worked through more than 100 reports that turned out to be invalid, duplicates, or not reproducible.” That is the validation load the FCA describes, landing on a volunteer-heavy open source project. The response then fell on every firm that runs PHP, in a single day.

Be precise about status. The FCA says its review “does not introduce new rules, guidance or regulatory expectations.” The May 2026 joint statement from the FCA, Bank of England and HM Treasury is framed the same way. Both sit on rules you already have: operational resilience under SYSC 15A and PRA SS1/21, and from 18 March 2027 the PRA’s incident and third-party reporting policy in PS7/26.

The next 72 hours: a PHP2Shell response for regulated firms

1. Build one list of everything that runs PHP. Websites and portals, internal tools, and the management interfaces of appliances. Do not stop at outdated versions; the NCSC says all versions may be affected.
2. Check your suppliers against the NCSC-NL inventory. Mark each product behind an important business service as vulnerable, fixed or unknown. Unknown is the common answer today.
3. Update, then restart every worker. The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12, or a distribution backport that includes the fix. Restart so the fixed binary is the one running.
4. Where you cannot update yet, mitigate in configuration. PHP lists session.upload_progress.enabled=0 and enforcing memory_limit=-1, set in php.ini or server configuration, not at runtime. Add WAF rules if your provider offers them. Record that these are partial.
5. Make the offline decision against impact tolerances. For each exposed system that cannot be fixed, the business-service owner decides: run with mitigations, isolate, or switch off. Log who decided and why.
6. Hunt for compromise on anything that was exposed. New files in web roots, web shells, new accounts and scheduled tasks, unusual outbound connections from web servers. Use an NCSC-assured incident response provider if you need help.
7. Check your notification duties. If you find compromise or a material service disruption, follow your existing FCA and PRA notification processes and, for personal data, the ICO’s 72-hour rule.

The operating model for the next one

PHP2Shell will not be the last emergency patch of this kind. The NCSC told organisations in May to prepare for a “vulnerability patch wave”. The FCA’s questions give a ready-made structure for answering it.

1. Ownership: one accountable executive, one queue

Name the executive who owns both the use of AI in vulnerability work and the remediation outcome. Put every source of findings into one queue: AI-assisted discovery, scanners, penetration tests, supplier advisories, NCSC alerts and KEV additions.

2. Review: validate before you count

The FCA notes that models “can generate large numbers of findings that are technically possible but difficult to validate, prioritise or act upon.” Every finding needs a reviewer who can say whether it is exploitable in your environment.

3. Prioritisation: tier on exploitability and service impact

Severity scores still count as an input, but they stop being the deciding factor. A workable tiering, in our view:

4. Bottlenecks: measure capacity and pre-agree the emergency path

Track validated findings in and findings closed with evidence out, every week. If inflow beats outflow for three weeks, that is a capacity problem for the executive owner. Then agree in advance who can accept a short outage for each important business service. The PHP2Shell shutdowns show that “take it offline” is a live option, not a theoretical one.

5. Important business services and visibility

SYSC 15A.2.9R already says a firm “must ensure it can remain within its impact tolerance for each important business service in the event of a severe but plausible disruption to its operations.” In our view, a critical flaw in a common runtime is now a plausible scenario. If your mapping stops at applications and does not reach runtimes, appliances and supplier products, extend it.

6. Suppliers: ask in writing

The FCA found some firms already asking suppliers how they are preparing for AI-enabled discovery. Send these to the suppliers behind each important business service this week:

• Do any products or services you supply us embed PHP, and are they patched for CVE-2026-109618 and CVE-2026-109619?
• How quickly will you tell us about a flaw that affects us, and will you publish mitigations before a patch is ready?
• What is your fix commitment for a flaw exploited in the wild?
• Who is your 24/7 escalation contact, and will you join a joint exercise?

This also prepares you for PS7/26. From 18 March 2027 PRA-regulated firms must notify material third-party arrangements and submit an annual register of them, and incident reports are expected “within 24 hours of the firm determining an operational incident has met the threshold.”

Where PHP2Shell responses go wrong

Four questions for your next board or ExCo

Where do you stand?

A named owner, triage based on known exploitation and exposure, and a pre-approved emergency change route is a Level 3 (Managed) capability. Findings mapped to important business services, with exposure time and remediation capacity reported and suppliers asked, is Level 4 (Measured). AI-assisted discovery run inside a controlled process, surge capacity tested and board reporting in impact-tolerance terms is Level 5 (Optimised).

A TrustOps Framework Assessment scores your vulnerability and resilience operating model against the FCA’s questions and gives your board a sequenced 90-day plan. Or start with the free 15-minute assessment.

General information, current as of 22 October 2026. The situation is moving quickly; check the NCSC, PHP and vendor advisories for updates. Not legal or regulated compliance advice.