Attack Attempts Preceded the PHP2Shell Patch: What It Means for Third-Party Risk

On October 21, the PHP Foundation released fixes for two critical flaws in PHP, a programming language used by roughly 70 percent of websites, by W3Techs’ count. The BBC reports the flaws are now called PHP2Shell. The critical flaws were found by AI-assisted research, reported AP, and the UK’s National Cyber Security Centre (NCSC) says organizations using any version of PHP are affected. Governments and companies in the UK, US, Japan, Finland and Germany took sites offline as a precaution while they patched, and the NCSC’s chief technology officer called the scale “unprecedented.”

Key facts, last updated October 23, 2026

• CVEs: CVE-2026-109618 and CVE-2026-109619, two PHP flaws rated CVSS 9.2 that could allow unauthenticated remote code execution, per CERT-EU.
• Earliest known attack attempt: October 17, 2026, an attempt against an AWS honeypot sensor, per AWS.
• Fixes released: October 21, 2026, a day ahead of the planned October 22 date, per the PHP Foundation.
• Who is affected: organizations using any version of PHP, per the NCSC, including products that embed it.

Cloudflare CEO Matthew Prince said in a social media post, quoted by The New York Times, that the company saw “thousands of attempts to exploit” the flaw in the hours before it was publicly announced. On Thursday, a day after the release, Infrawatch scans reported by the BBC put the share of systems patched worldwide at 4.21 percent.

When did PHP2Shell exploitation start?

The PHP Foundation’s first external security audit surfaced early signs of the memory problem in 2024; AWS recorded the earliest exploitation attempt on October 17, the CVE IDs leaked on October 20, and fixes were released on October 21, a day ahead of the planned October 22 date. The 2024 audit found no concrete way to exploit the problem, and it was fully understood only after reports from three research teams in August and September 2026, according to the PHP Foundation.

Amazon’s threat intelligence team, in a post by CJ Moses, CISO of Amazon Integrated Security, recorded that October 17 attempt four days before the embargo lifted. AWS says it does not know whether those attempts would have worked against real systems, and the Foundation said it found no functional exploits at the time of disclosure. Attempts preceded the release; whether any succeeded is not established.

AWS’s guidance is that “defenders should not assume the public disclosure date is the earliest date of exploitation.” CERT-EU, in an advisory issued on release day, said circulating proof-of-concept code “raises the likelihood that attackers are already exploiting the vulnerabilities.“

A questionnaire that asks vendors how fast they patch after release measures the wrong interval. The interval that matters runs from the earliest known exploitation to remediation, and a point-in-time assessment cannot show it. To measure the correct interval requires companies monitoring vendors between assessment cycles.

Which products are affected by PHP2Shell?

The UK’s National Cyber Security Centre (NCSC) states that organizations using any version of PHP are affected. The EU’s joint statement, issued by the European Commission, ENISA, CERT-EU, Europol’s EC3 and the CSIRTs network, goes further into the supply chain. “Many commercial and open-source products rely on PHP in the background,” it says, and “some may be affected by these vulnerabilities even if they do not appear to use PHP directly.”

Charl van der Walt of Orange Cyberdefense told AP that the “potential blast radius” is “frankly, enormous.” Fixing it requires companies to recognize they run the software, “identify the systems where it’s being run, identify who owns those systems and do a risk assessment about when and whether it can be patched.” He estimated it could be “months or years” before all the stragglers are weeded out.

The effects reached well beyond government sites. The BBC reported that Japanese companies including ANA, Asahi Group Holdings and Tokio Marine Holdings suspended some websites and services as a precaution, and that French telecommunications company Orange suspended access to certain services globally while it deployed security patches. 

What does PHP2Shell show about fourth-party risk in open-source software?

A vendor’s risk includes how well the open-source software under its product is maintained. A 2024 audit surfaced early signs of the memory problem behind PHP2Shell, and fixes shipped in October 2026. The PHP Foundation attributed the gap to “a structural failure, caused by both the security team’s decision process and its lack of resources,” and said it created its Ecosystem Security Team in May 2026.

W3Techs puts PHP at 69.3 percent of websites whose server-side language is known, so a maintenance gap in one project becomes an exposure for everyone downstream. That is concentration risk. The 2024 CrowdStrike outage is a precedent for concentration risk at this scale: a CrowdStrike executive told a US House subcommittee that a faulty content update, not a cyberattack, affected 8.5 million Windows devices.

Fourth-party mapping that lists only the companies in a vendor’s supply chain will not show how well their software is maintained. It needs to reach the open-source components a vendor’s product runs on, and record who maintains them and how they are resourced.

Why did governments take services offline after PHP2Shell?

According to AP, the FBI’s cyber division recommended that operators take websites offline if they could not update immediately. The NCSC lists taking a system offline as an option until it is mitigated, and the joint EU statement advises considering isolating exposed applications from public networks. CERT-EU is more direct: only an update fully fixes the vulnerabilities.

Government responses varied in scale. In the UK, technology minister Baroness Lloyd of Effra told the House of Lords that 32 government services were unavailable and four partially unavailable, and that no large public-facing critical services were affected. Germany’s Federal Office for Information Security said it had received no reports of compromised federal IT systems, but added that “successful attacks cannot be ruled out at the moment.” In Japan, Prime Minister Sanae Takaichi encouraged businesses to take sites down and said her own official website had been briefly suspended, The New York Times reported.

For government sites, the guidance made the call easy. For a vendor-hosted system your own operations depend on, the vendor may make the call for you, on its own timeline. A third-party incident response plan that names who decides, who gets notified and what the manual fallback looks like gives a business continuity plan the input it needs for systems you do not host.

What five questions should you ask critical vendors about PHP2Shell?

Add these five questions to your vendor questionnaire and ask for written answers.

1. Where does PHP run in the service you deliver to us, and on which versions? Cover bundled products, appliances and subcontractors, since ENISA and CERT-EU both warn that products can embed PHP without saying so. The NCSC-NL inventory lists products that may be affected. PHP 8.1 and older are end of life with no upstream fix, according to CERT-EU, so a vendor on those branches needs to show the backport that covers it.
2. What are the timestamps? Ask when the vendor learned of the flaw, when it applied mitigations and when it finished patching, in hours rather than dates. Start the investigation at the earliest known exploitation, which AWS puts at October 17, instead of the October 21 release.
3. Has anyone checked for compromise, or only applied the patch? The NCSC advises that systems which cannot be updated or disabled immediately be checked for signs of compromise and backdoors. NCSC chief technology officer Ollie Whitehouse told BBC Radio 4 there were “no indications” of successful breaches, and Germany’s cyber-security authority said successful attacks could not be ruled out. Patching closes the exposure, and a separate check establishes whether anyone used it first.
4. Who decides to take the service offline, and what do we get when you do? Contracts should specify notice, a named escalation path and the manual fallback, the pen-and-paper equivalent for your own processes.
5. Which of your vendors does this touch? Ask the vendor for its own fourth-party exposure, including the open-source components underneath the product and who maintains them.

Three of these questions replace a release-based check with one that starts the clock earlier. The comparison below shows the shift.

What should third-party risk programs build before the next PHP2Shell?

Officials are treating PHP2Shell as a pattern, not an anomaly. Ollie Whitehouse, the chief technology officer for the UK’s National Cyber Security Centre, told BBC Radio 4 it is “reasonable to expect that this will not be the last.” Baroness Lloyd told the Lords that organizations should sign up for early warning systems and understand their supply chains fully. Neither is a patching instruction. Both are asks about visibility, which makes them the parts of the response a third-party risk program can build ahead of time.

Customers with third-party risk management systems already in place, such as Mitratech Prevalent, were able to act as soon as the threat became known. To see how continuous vendor monitoring, fourth-party mapping and incident workflows fit together, request a demo of Mitratech’s third-party risk management software.