The recent PHP2Shell headlines have understandably raised questions for businesses that rely on PHP-based websites and software. When a familiar technology suddenly makes the national news, it can be difficult to separate the seriousness of the issue from the scale of the coverage.
Our view is that AI’s role in the research helped bring this story to a much wider audience. It is an interesting and significant part of the story, but the practical response still comes down to familiar work: understanding the issue and applying the appropriate security updates promptly.
What was discovered?
PHP2Shell is the name used for two critical vulnerabilities in PHP, tracked as CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they can allow an attacker to run code on an affected server without logging in. The PHP team released security fixes on 21 October 2026. PHP’s security advisory explains the issue and the updates.
These were longstanding problems, rather than faults suddenly introduced by a recent update. Wiz’s research describes vulnerable code that had been present for more than a decade, and explains how AI helped researchers investigate the flaws and demonstrate how they could be exploited. Read Wiz’s account of the discovery.
Why so much attention?
PHP regularly receives security updates as vulnerabilities are identified. In our experience, much of that work happens quietly, with providers maintaining their systems while businesses get on with using them.
This time, a widely used technology, critical vulnerabilities and AI-assisted research came together in one story. We think that combination helps explain the unusually broad interest. It does not mean that every previous PHP security update was unimportant, or that AI created these underlying flaws.
The PHP Foundation’s account also makes clear that people remained central to investigating the reports, deciding how to fix the problems and coordinating the release. AI supported the work; experienced engineers still had to make the decisions. The Foundation describes that process here.
Keep the timeline in perspective
A flaw having existed for years is not the same as knowing it was exploited throughout that time. Equally, a lack of earlier public reports is not proof that it was never exploited.
That distinction matters here. Amazon Threat Intelligence reported an exploitation attempt against its monitoring systems dated 17 October 2026, before public disclosure. It also noted uncertainty about whether those attempts would have succeeded against real-world systems. AWS’s report sets out what it observed. This was a genuine security issue that warranted action.
The position has continued to develop: both vulnerabilities were added to CISA’s Known Exploited Vulnerabilities catalogue on 26 October, as recorded in the Canadian Centre for Cyber Security’s advisory. Prompt patching remains important.
A precautionary shutdown is a significant step
The decision by some organisations to take websites or systems offline as a precaution was a striking part of the response. In our experience of working with PHP, that is very unusual.
The appropriate response depends on an organisation’s systems, exposure and ability to apply an update promptly. Where an affected service cannot be patched immediately, temporarily taking it offline may be a reasonable precaution.
What CBS did
CBS servers were patched very quickly once the exploit was made public.
Our priority was to apply the security updates promptly, rather than allow the level of media attention to dictate the response.
For businesses, the useful question is whether the systems they rely on are maintained and security updates are acted on. PHP2Shell is a reminder of why that ongoing work matters, even when it usually takes place without a headline.
