Source: BBC reporting on the PHP2Shell incident and the supplied learning notes. The BBC article could not be directly verified during this review, so reported shutdowns and incident details are reproduced from the notes; technical details and remediation were cross-checked against PHP, the UK NCSC, AWS, OpenAI, and Wiz.

Original article: https://www.bbc.com/news/articles/c3qjnwye0ep5o

Researchers used AI tools to help uncover two long-lived vulnerabilities in the PHP runtime. Under specific conditions, the flaws could let an unauthenticated remote attacker execute code or read sensitive information from PHP process memory. PHP released fixes on October 21, 2026, prompting rapid action by websites, public agencies, and security teams.

One distinction matters throughout this story: an attempted attack is not the same as a confirmed compromise. At the time of the BBC report, no successful attacks had been reported. AWS later disclosed that its MadPot honeypot had recorded an exploitation attempt on October 17. AWS said it was unclear whether the attempt would have succeeded against a real system.

What PHP does in a web request

PHP stands for PHP: Hypertext Preprocessor. It is an open-source server-side programming language. Its first form was created by Rasmus Lerdorf in 1994; it later evolved into a language used to build dynamic websites and web applications. When someone requests a page, the web server invokes PHP to run application logic, retrieve data, and return generated content to the browser.

A restaurant analogy helps: a customer ordering a burger is like a user requesting a page; the server taking the order is the web server; the cook preparing the meal is PHP generating the page; and the meal reaching the table is the server returning the page to the browser.

flowchart LR
    U[User requests a page] --> W[Web server receives request]
    W --> P[PHP runs logic and reads data]
    P --> R[Page content is generated]
    R --> B[Browser displays the page]

PHP is used in systems such as WordPress, Drupal, and MediaWiki, which powers Wikipedia. It also appears in online shops and applications built with frameworks such as Laravel and Symfony. Wiz estimates that PHP powers about 70% of websites worldwide. That is Wiz’s estimate of PHP’s reach; it does not mean every site runs the same version or configuration. The PHP Foundation is one of the non-profit organizations supporting the PHP project.

The two PHP2Shell vulnerabilities

PHP2Shell is the name used for the PHP core vulnerabilities in this incident. PHP’s official announcement listed CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0. Because the flaws are in the PHP runtime, the exposure is not limited to one content management system or plugin.

ItemDetails
CVE identifiersCVE-2026-109618 and CVE-2026-109619
SeverityBoth were rated 9.2 under CVSS 4.0 in PHP’s advance notice
Calif / Patch the PlanetCalif reported multiple RCE paths; OpenAI says the Calif team used GPT-5.6 Sol to identify a critical flaw, and Calif’s research account is credited to Ryan Austin
Wiz ResearchIndependently found and reported both vulnerabilities
Affected componentThe PHP runtime and deployments that process web requests
Potential impactUnauthenticated remote code execution under specific conditions, or disclosure of process memory
VulnerabilityHigh-level causePotential impact
CVE-2026-109618An out-of-memory condition can interrupt PHP while request data is only partly initialized; cleanup may then treat invalid data as validMemory corruption and, under specific conditions, remote code execution
CVE-2026-109619Internal state owned by one request may remain after its backing memory is freed, allowing a later request to encounter it before state resetReuse of stale state, potentially causing memory corruption or remote code execution
flowchart LR
    A[Request handling reaches an exceptional state] --> B{Is internal state complete}
    B -->|No| C[Cleanup may process invalid data]
    B -->|State remains| D[A later request may encounter stale state]
    C --> E[Memory corruption risk]
    D --> E
    E --> F[Under specific conditions: code execution or information disclosure]

Wiz says the affected code dates back to PHP 5.4. Whether a particular system is exposed still depends on its runtime version, PHP SAPI, distribution patch, and hosting provider. Checking only the version of WordPress, Drupal, or a plugin does not establish that the PHP runtime has been fixed.

From discovery to patch

DateResearch trackEvent
July 30, 2026Calif / Patch the PlanetCalif began its PHP research through OpenAI’s Patch the Planet initiative
August 1, 2026CalifCalif says it identified an initial out-of-memory fatal path and interruption points that led to further RCE findings
August 11, 2026CalifReported the first bug to PHP and began coordinated disclosure
August 14, 2026CalifShared an RCE proof of concept with PHP
August 15, 2026PHPConfirmed Calif’s proof of concept worked as expected
August 19, 2026WizRecorded discovery of the first PHP vulnerability
August 20, 2026WizConfirmed unauthenticated RCE on Drupal
August 21, 2026WizConfirmed unauthenticated RCE on WordPress
August 21, 2026CalifReported a second bug to PHP
August 24, 2026WizReported the vulnerabilities to the PHP security team
September 21, 2026Wiz / PHPPHP acknowledged the reports and began coordinating a fix
October 17, 2026AWSMadPot observed a suspected exploitation attempt, four days before public disclosure; AWS said it was unclear whether it could succeed on a real system
October 21, 2026PHPReleased fixes and publicly disclosed the two CVEs
October 23, 2026PHPIssued an informational notice about a separate, narrower issue tracked as CVE-2026-115560

Precautionary shutdowns are not proof of compromise

According to the BBC report as summarized in the supplied notes, some organizations temporarily took systems offline or paused services after the October 21 alert. These were risk-control decisions; they do not show that the organizations had been breached.

Organization or serviceReported action
WikimediaTemporarily took some systems offline
Finnish government, Edinburgh City Council, the Dutch cybersecurity agency, and the University of GenevaThe report said they took precautionary measures
UK governmentTemporarily took 32 websites offline; the report said they were not major public services
OrangePaused some services globally
BBCTook some pages offline
SoftBankPaused earthquake and tsunami alerts; the report said service returned on Monday

The report also said the US NSA advised taking systems offline if they could not be patched promptly, and described the vulnerability as a direct route to attacking databases. The EU, Singapore, and Australia issued similar alerts. The supplied notes say Japanese Prime Minister Sanae Takaichi urged action that evening on X. They also say Amazon had faced multiple attempts in the days before disclosure while its website remained operational. These statements are attributed to the BBC report and the supplied notes.

The BBC also reported Cloudflare CEO Matthew Prince’s estimate of attack attempts: thousands before disclosure, tens of thousands within 45 minutes, hundreds of thousands within two hours, and millions afterward. These are observed attempts, not confirmed compromises or a count of vulnerable websites.

AWS’s October 17 honeypot finding shows that attempts may predate public disclosure. AWS also said it could not determine whether the attempts would have succeeded against real systems. The BBC’s earlier statement that no successful attacks had been reported is therefore consistent with AWS’s later disclosure of attempted activity.

How AI changed the economics of vulnerability research

Calif’s account describes a separate research track. Ryan Austin brought knowledge of PHP’s vulnerability history, asked an LLM for help finding ways to trigger controlled out-of-memory failures, then used an AI research assistant to inspect allocation, fatal-error, and cleanup paths. Calif says this work led to a repeatable interruption pattern that helped surface further findings. OpenAI says the Calif team used GPT-5.6 Sol through Patch the Planet to identify a critical flaw; Calif’s research account is credited to Ryan Austin. Wiz independently found and reported both vulnerabilities, using Wiz Atlas, Gemini 4 Argon, and GPT-5.6 Sol; Wiz credits Gemini 4 Argon with helping in discovery, exploit research, attack detection, and patch validation.

These are vendor and researcher accounts, not a controlled comparison of AI models. AI did not carry out the investigation on its own: researchers supplied historical context, directed the analysis, validated findings, assessed impact, coordinated disclosure with PHP maintainers, and checked the fix. The same ability to accelerate code analysis can also help attackers turn vulnerability information into tools more quickly.

The bugs were not new; what changed was our ability to find them.

Ryan Ko’s point in the report speaks to an older problem: many systems were originally built to deliver functionality without putting security first. Code does not become secure simply because it has run for years. AI can make issues that were once difficult to find or validate a practical risk.

PHP deployments that are easy to miss

PHP may also be bundled in network appliances, load balancers, embedded devices, and management interfaces. The NCSC warns organizations to check third-party products and services that may include PHP and to monitor vendor updates.

flowchart LR
    A[Public websites and CMSs] --> P[PHP runtime]
    B[Internal business systems] --> P
    C[Network appliances and load balancers] --> P
    D[Embedded management interfaces] --> P
    E[Hosted services and third-party products] --> P
    P --> F[Check version, patch source, and vendor notices]

An inventory limited to self-managed web servers can miss runtimes maintained by a hosting provider or device vendor. Include owned services, container images, shared hosting, network devices, and third-party applications in the review.

What users and site operators should do

AudienceResponse
Everyday usersUsually no direct action is needed. Watch for official security notices from service providers, including password-reset notices, and be cautious of suspicious messages asking for passwords or verification codes
Website owners and operations teamsInventory PHP deployments that handle web requests and patch internet-facing systems first. Confirm the version actually running, not only a repository or control-panel setting
WordPress and other CMS operatorsUpdating the CMS or its plugins does not replace a PHP runtime patch. Ask the host to confirm the underlying PHP update and restart of worker processes
Older versions or vendor appliancesPHP 8.1 and earlier no longer receive routine project updates. PHP published minimal source backports for 7.4, 8.0, and 8.1 for source builders or those without an LTS vendor; packaged deployments should confirm the vendor’s fix
Systems that cannot be patched yetOfficial mitigations reduce risk for specific paths but are not a complete fix. If effective mitigation is not possible, consider isolation or temporary shutdown

PHP’s security release lists 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as fixed releases. The Windows packages rebuilt on October 26 add a -1 suffix for the separate Brotli fix CVE-2026-111497; the PHP runtime versions did not change. Teams using distribution packages or long-term support versions should confirm that their vendor has included the PHP2Shell fix. PHP says updating to a fixed release is the complete remediation.

Security researcher Ken Munro compared updating PHP to running a Windows update. For a hosted site, that usually means asking the provider to confirm that the runtime itself has been patched, rather than only updating the site’s administration panel.

The supplied notes say patch adoption was improving globally but remained slower than expected, and warn that attempts could continue to rise in the weeks after technical details became public.

The UK NCSC recommends inventorying all systems that run PHP, prioritizing internet-facing services, and considering temporary shutdown if an update and effective mitigation are not possible. It also advises checking for signs of compromise before upgrading. AWS recommends that investigations start at least as early as October 17.

flowchart LR
    A[Inventory PHP deployments] --> B[Check versions and patch sources]
    B --> C[Patch public-facing services first]
    C --> D[Restart workers or devices]
    D --> E[Verify the version actually running]
    E --> F[Review logs and unexpected changes]
    F --> G[Track PHP and vendor updates]

A separate PHP notice on October 23

On October 23, PHP issued an informational notice about session upload progress, associated with the separate identifier CVE-2026-115560. It applies only when an application configures session.serialize_handler as php_binary or php_serialize, switches it to php at runtime with ini_set() before session_start(), and still has session upload progress enabled. PHP advised affected deployments to disable session upload progress temporarily; a full advisory was planned for the next regular fix release.

This is not a third name for the original two vulnerabilities. Operators should use PHP’s follow-up advisory and their own configuration to determine whether it applies.

What the incident leaves us with

PHP2Shell brings together three issues: a vulnerability in a foundational runtime, AI changing the cost of vulnerability research and exploitation, and limited visibility into an organization’s software assets. Patching PHP is the first priority. Confirming that the patched runtime is the one actually handling requests—and checking devices, hosted services, and third-party products—helps prevent an application-only update from leaving the vulnerable component untouched.

Frequently asked questions

Does PHP2Shell mean every PHP website was compromised?

No. A broad exposure does not mean every site was successfully attacked. Confirm the runtime version and patch status, then investigate suspicious activity against the systems in scope.

Is updating WordPress or a plugin enough?

No. The fix is in the PHP runtime. Confirm that the PHP version actually processing requests has been updated on the host, container, or device, and restart workers where required.

Does AWS’s exploitation-attempt record prove a successful attack?

No. AWS observed an attempt in its honeypot and said it could not determine whether it would have succeeded on a real system. Operators can start their log and change review from October 17, 2026.

References

ACP (Agent Client Protocol)Active MemoryAgent AuthorizationAgent CardAgent Evals
Share