Hero image: Conceptual AI-generated illustration of software-memory diagnosis, not a real exploit screenshot or a depiction of a physical hardware fault.
AI-assisted research helped demonstrate serious weaknesses in PHP. The useful story is how those weaknesses became exploitable, how the fixes reached users, and what website owners should check.
26 October 2026. Based on the public advisories available at publication preparation.
“AI has broken the internet” is an attention-grabbing way to frame a security story. It is also a poor starting point for deciding what to do about it.
The questions that matter are more practical: what failed, what was demonstrated, which systems are exposed, and who is responsible for the fix?
PHP2Shell deserves attention. It does not require an apocalyptic explanation.
First, PHP is software, not a network protocol
PHP is a programming language and its server-side runtime. WordPress is an application that depends on that runtime, alongside other hosting components. That distinction matters: updating an application does not, by itself, establish that the underlying PHP installation has been patched. WordPress lists PHP separately among its hosting requirements.
What actually went wrong?
A PHP worker handles requests and uses memory to keep track of what it is doing. Two failures in that housekeeping sit behind the original PHP2Shell advisories.
1. An interrupted operation left unfinished data behind
CVE-2026-109618 concerns out-of-memory handling. PHP could abandon an operation while some internal data was only partly prepared. Later, its cleanup process could treat that unfinished data as valid.
Think of an interrupted assembly job: the problem is not simply that work stopped, but that the next stage assumes the unfinished component is safe to use.
The advisory confirms remote code execution without authentication, using the web worker’s account. A complete attack was validated against Apache’s mod_php integration with default PHP input and memory limits. Reliability and portability still depend on details including the build, extensions and memory layout. This is serious evidence, not proof that every PHP deployment is equally exploitable. PHP’s out-of-memory advisory.
2. A worker retained a reference to memory it had released
CVE-2026-109619 concerns stale internal state. A worker could retain a reference to data belonging to an earlier request after that request’s memory had been freed. A later request reaching the same worker could use that reference before normal initialisation replaced it.
This is a use-after-free problem: software acts on memory whose original lifetime has ended. The advisory describes confirmed and conditional paths, rather than one identical attack that applies to every configuration. It also explains why hiding error messages cannot repair the underlying state-management fault. PHP’s stale-state advisory.
Remote code execution means an attacker can make the affected process run code. It does not automatically mean unrestricted administrator access to the entire machine. Equally, a compromised web worker can be a substantial security incident. “Not automatically root” is no reason to dismiss it.
Myth: AI suddenly invented a new way to destroy PHP
OpenAI says security firm Calif identified a critical flaw using GPT-5.6 Sol through its Patch the Planet initiative. It also credits Wiz with independently discovering and reporting both vulnerabilities. PHP’s maintainers led the fixes and release, supported by researchers and infrastructure providers. OpenAI’s disclosure account.
That describes AI-assisted security research and a coordinated defensive response. It does not establish that an autonomous system attacked ordinary websites at random.
An exploit demonstration shows that a weakness can be used. Whether the work is legitimate also depends on authorisation, scope and disclosure. The presence of the word “exploit” does not, on its own, turn responsible research into criminal activity.
Myth: this was already known, so there is no real news
The PHP Foundation’s account gives a more useful timeline:
- 2024: work following an external audit exposed early signs of the out-of-memory problem. Exploitation was theorised, but concrete routes had not been established.
- 30 July 2026: Calif began its PHP audit.
- 11 August: Calif reported remote code execution with that root cause. Further independent work made the impact clearer.
- 21 October: the fixes became publicly available, a day earlier than originally planned after disclosure arrangements were disrupted.
The Foundation explicitly calls the earlier delay a “structural failure”. It describes difficult compatibility and availability trade-offs, a consensus process that struggled to choose a fix, and too few engineers with the necessary expertise. The PHP Foundation’s retrospective.
There is a meaningful difference between suspecting a failure mode and demonstrating a working attack. The age of the warning signs is part of the story; it does not make the evidence or the release irrelevant.
Myth: a headline proves your website has been compromised
A vulnerability advisory establishes a risk, not the incident history of an individual site. Neither a frightening headline nor a functioning homepage tells you whether your installation is protected.
The useful evidence is specific: the runtime serving requests, the applicable vendor fix, confirmation that the protected build is in use, and any signs of compromise requiring investigation.
What website owners should check
PHP’s 21 October fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Some vendors provide backported fixes, so a version number alone may not settle the question. Follow your distribution or hosting provider’s guidance, rather than copying emergency settings from social media. PHP warns that interim configuration measures do not provide a complete substitute for the original patches. PHP’s official security announcements.
For a managed website, ask who maintains the runtime and look for a statement covering these exact CVEs. For a self-managed server, have the responsible administrator verify the actual serving environment, not only a command-line installation or an available update.
WordPress.com, for example, says all sites hosted on its platform are protected against the original pair, even where an older PHP version is displayed. Its statement does not apply to every website merely because it uses WordPress or Jetpack. WordPress.com’s provider bulletin.
The 23 October follow-up needs its own check
PHP subsequently described a separate, unlikely remote-code-execution route, CVE-2026-115560. It requires an unusual combination of runtime session-serializer changes and enabled session upload progress. PHP recommends disabling upload progress pending the next regular bugfix release, while explaining that applications which never switch serializer at runtime can leave it enabled. The 23 October advisory.
Administrators should assess that follow-up separately. It is not evidence that the original patches were pointless, nor a reason to assume an earlier hosting statement covers every later finding.
The Hardware Ledger view
The strongest lesson is about the whole engineering process. Finding a fault, demonstrating its impact, choosing a repair, testing compatibility and getting the repair deployed are different jobs.
AI can help with that work. It does not remove the need for experienced maintainers, adequate resources or accountable decisions.
For readers, the response should be proportionate: take demonstrated remote code execution seriously, check the evidence relevant to your hosting, and resist the idea that every AI-assisted discovery signals the collapse of the internet.
Less mythology. More verification.