Organisations must now uncover hidden compromises, close lingering security gaps and ensure attackers haven’t already found another way in.

Look back before declaring recovery

There is a concrete reason to look beyond the patching window. Amazon Threat Intelligence reported a PHP2Shell exploitation attempt against its MadPot honeypot network on 17 October, four days before public disclosure. That observation does not prove that any particular organisation was compromised. It does show why an investigation starting when the advisory arrived could miss relevant activity.

If attackers gained entry earlier, they may have changed files, stolen credentials or created another route into the environment. Closing the original vulnerability would not automatically remove those footholds. Nor would it reveal whether attackers reached a database or another connected system.

The next step is to examine activity across the period of exposure. Security teams should look for suspicious web requests, unexpected processes, unusual connections and changes to files or accounts. Findings should determine how far the investigation extends. Where a compromised application could access other services, the review needs to follow those connections.

Teams also need to preserve evidence while completing urgent repairs. Google Cloud guidance notes that updated packages leave vulnerable PHP code in running processes until the relevant services restart. On suspect hosts, it advises capturing memory evidence first. Coordinating those steps will help teams avoid destroying potential clues during remediation efforts.

Take stock of the remaining exposure

Conducting investigations into possible intrusion should be done alongside a broader stocktake.

This needs to establish where PHP runs, which installations were affected and whether each fix has taken effect. That includes software embedded in vendor products and services maintained by hosting providers. Just updating the most visible website is insufficient if another exposed installation remains vulnerable.

This is where vulnerability management and exposure management need to work together. Vulnerability management identifies affected software and tracks remediation. Exposure management adds the context needed to judge what matters most: which systems attackers can reach, what access those systems hold and which business services depend on them.

That context helps IT teams prioritise their remaining work. An exposed application with access to sensitive records deserves attention according to both the likelihood and consequences of compromise. If investigators find stolen credentials or unauthorised access, those findings must feed into remediation too. A completed PHP update cannot close an incident that still has unresolved access paths.

Third-party supplier assurances will need the same scrutiny as internal remediation. Ask which affected components were updated, whether the changes are active and what checks were performed for earlier compromise. If responsibility is split between a hosting provider and an application vendor, establish who covers each part of the investigation. Otherwise, each party may complete its own task while a gap between them remains unexamined.

Verification matters throughout. Teams should confirm that corrected software is running, investigate suspicious findings and monitor restored services for further activity. Where logs are missing or checks are incomplete. The people responsible for reopening must understand that uncertainty.

Prepare for the next major disclosure

The PHP episode also raises a longer-term challenge. AI helped researchers uncover these flaws, and OpenAI has said it expects similar discoveries to increase sharply in the coming months. Organisations should prepare for more occasions when a major disclosure commands urgent action across systems they rely on.

Preparation starts with maintaining an accurate inventory, retaining useful activity records and agreeing responsibilities with suppliers. Response exercises should test whether teams can identify affected services, deploy and verify fixes, and investigate suspected compromise while managing pressure to restore access.

Those decisions become easier when organisations have agreed in advance who can suspend a service, what evidence supports reopening as well as who accepts any remaining risk. The experience should also inform improvements to monitoring and remediation, so the next response begins with fewer blind spots.

Patching PHP was urgent. Now we have to establish whether attackers used the opening and address whatever exposure remains. Organisations should carry that investigation through, then use what they learn to strengthen their response for when, not if, the next emergency arises.