PHP2Shell checklist for managers

Who this is for

You are responsible for websites or a digital service, but you do not need to read the exploit details. You need to know whether the organisation has a defensible answer, who owns the work and what remains unresolved.

This is a coordination checklist, not an incident-response procedure. If you suspect a host was compromised, involve your security team or provider’s incident process.

The short answer

Do not accept “patched” as a status. Ask for four things:

1. Scope. Which sites, services, environments and vendors are in the list?
2. Runtime. Which PHP version and package or image serves each one?
3. Evidence. What shows that the package contains the fix and that the workers were restarted?
4. Exceptions. What is not fixed, who owns it, what interim control is in place and when will it be removed?

If those four answers are not available, the organisation has an ownership or evidence gap, even if the technical work is partly done.

Scope. This guide addresses CVE-2026-109618 and CVE-2026-109619. PHP also published a separate 23 October advisory for CVE-2026-115560 with narrow configuration conditions; it does not change the four PHP2Shell fixed releases. See the 23 October update.

1. Build the service list

Start with the domains and applications the organisation depends on, not with a list of servers. Include:

• public websites and customer portals;
• WordPress, Drupal, Joomla, Laravel or custom applications;
• forms, intranets and extranets that may be less visible;
• staging, preview and disaster-recovery environments;
• sites run by agencies or shared-hosting providers;
• appliances or packaged applications that embed PHP.

For each item, record a business owner and a technical owner. A vendor can be the technical owner, but someone inside the organisation still needs to own the follow-up.

2. Ask for the runtime, not the application version

The flaws are in PHP itself. A current CMS, theme or plugin does not fix them. Ask each owner:

• Which PHP branch and exact package version or image digest serves the service?
• Is it the host’s default runtime or a dedicated pool?
• Does the package contain the upstream fix or a distribution backport?
• When was the PHP service or container restarted after the package changed?
• Are there other environments or domains on the same runtime?

The fixed upstream releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Older branches need a distribution or vendor support path. Do not compare only the first two version numbers; a package revision and a restart matter.

3. Set an evidence standard

A status update should be short enough to review and specific enough to verify:

A screenshot of a version string is weak evidence because it may show the CLI, a control-panel default or a package before restart. A ticket that names the runtime, the patch and the restart is stronger.

4. Track exceptions explicitly

Some services will not be fixed on day one. That is a risk decision, not a reason to stop reporting. For each exception, record:

• the business service and its owner;
• why the update cannot happen yet;
• the interim control in place;
• the residual exposure;
• the removal date and the person accountable.

Interim controls reduce specific paths; they do not replace the upstream fix. If a provider says a WAF or a configuration setting is “enough”, ask for the scope and the exit date. The mitigation guide explains the limits.

5. Ask what “done” means

A service is not done because a package appears in a dashboard. Ask for:

• the runtime evidence from the serving process;
• the restart or rollout record;
• confirmation that other environments on the same account were checked;
• a named owner for any remaining exception;
• a date for the next review.

For a hosting provider, the hosting checklist turns those questions into a short message. For a WordPress site, the WordPress runtime check explains why a CMS update is a different layer.

6. Communicate without overclaiming

Use bounded language in updates to leadership or customers:

• “The fixed PHP package is installed and the service was restarted at [time]” is a factual statement.
• “The service is secure” is not supported by a version check.
• “No compromise has been confirmed” is not the same as “no compromise occurred”.
• “All sites are patched” needs a scope list and an evidence source.

Do not publish victim counts, attack totals or a remediation percentage unless the organisation has its own measured data. Public reports describe attempts and exposure estimates; they are not a count of your systems.

7. Keep the record

Retain the service list, evidence, exceptions and review dates in one place. This is useful for audit, customer questions and the next vulnerability. It also prevents the common failure in which one team believes a vendor has patched everything while another team is still running an old pool.

The PHP2Shell dossier has the technical overview and the official sources. The verification guide is for the engineers who need to prove the runtime state. The contact page is for corrections or additional sources, not for incident response.

Boundaries

This checklist does not determine whether a service was exploited, does not replace legal or regulatory advice, and does not certify that a host is secure. CISA said it had not observed exploitation at publication; that statement has a time boundary and does not cover later activity. Patch status, exploitation evidence and KEV status are separate.

Sources: PHP security advisory, CERT-EU 2026-018, NCSC UK and CISA. Last verified 23 October 2026.