Patching PHP does not tell you whether you were compromised

In my recent post, AI is changing the tempo of cybersecurity, I looked at the PHP2Shell vulnerability and the pressure faster vulnerability discovery puts on organisations. The focus was on getting problems fixed. I did not really cover what needs to happen after the patch has been applied.

That deserves attention, because patching and investigating possible compromise are different tasks.

Amazon Threat Intelligence says attackers began targeting PHP2Shell on 17 October - four days before patches were released, and before vulnerability details reportedly leaked.

Amazon observed exploitation attempts, not confirmed compromise of every targeted system. It could not establish whether the earliest attempts would have succeeded against real-world systems. But the timeline makes the governance issue clear: applying the patch does not establish what happened before it.

The disclosure date was not the start of the risk

PHP2Shell comprises two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution on vulnerable systems. Both have a CVSS v4.0 severity score of 9.2. PHP released emergency patches on 21 October.

Details leaked before the planned coordinated disclosure, prompting PHP to accelerate its release schedule. However, Amazon’s first observed exploitation attempt predates that public leak. Amazon says it remains unclear how the attacker obtained the information. The public leak does not explain the earlier activity.

For an affected organisation, “When did we patch?” is only the first question. The next is “What happened while we were vulnerable?”

That second question requires investigation, not another confirmation that the update was installed.

Taking a service offline is not evidence of a breach

The UK National Cyber Security Centre advised organisations to update affected PHP servers immediately or take them offline until they could be patched. Precautionary shutdowns and disruptions affected services worldwide, including Finnish government websites, the Netherlands’ cybersecurity agency website and parts of Wikipedia.

Taking a service offline can be a precaution, not evidence of a breach. Reporting these shutdowns as confirmed compromises would misrepresent both the incidents and the decisions organisations made.

Nor is this simply a WordPress problem. PHP sits beneath widely used applications, including WordPress, Magneto, Drupal, Joomla among many. The relevant question is where vulnerable PHP deployments exist - not just which content management system runs the main website.

For governance purposes, the scope of that question should include applications operated internally and services managed by suppliers.

“Patched” is an incomplete executive briefing

An executive briefing that says “patched” reports an action. It should also explain what was investigated, what the evidence shows and what remains unknown.

The distinction is between remediation and assurance. Remediation addresses the vulnerability. Assurance requires a defensible account of the organisation’s exposure, the investigation undertaken and any uncertainty that remains.

Amazon’s findings show why the investigation period cannot automatically begin on the public disclosure date. In this case, observed attempts were already under way.

The questions for management are straightforward:

• Where were we exposed, including through suppliers?
• What period did we investigate, and why?
• What does the evidence show - and where are the gaps?
• Who owns any remaining investigation or remediation?
• What supports the decision to restore the service or close the incident?

Those questions also make the limits of the response visible. If relevant logs are unavailable, supplier confirmation is outstanding or the investigation is incomplete, the briefing should say so.

“Patched” and “investigated” are different statuses. Executive reporting should keep them separate.

Closing the vulnerability should not quietly become closing the incident.