PHP2Shell emergency patching checklist for businesses

What the urgent advice means in practice

The NCSC’s PHP alert prioritises identifying affected services, updating the runtime and using vendor guidance where immediate updating is not possible. CERT-EU likewise recommends urgent correction and considering isolation of public applications when a fix cannot be applied and verified. This checklist turns those high-level priorities into an accountable business change; it is not a replacement for the current supplier advisory.

Use the latest official information at the time of action. The position checked for this article is 22 October 2026, and fixed package availability or provider coverage can change. Keep an advisory link and checked date in the incident or change record. Avoid circulating an old screenshot as though it were a live status feed.

Assign people who can make and verify the change

One person can hold more than one role in a small business, but no deliverable should be ownerless. If the developer cannot access runtime packages, name the provider who can. If the provider can patch PHP but cannot test your booking integration, name the developer who will. A short responsibility table often removes more delay than another general message telling everyone to update.

Build a service inventory that includes the overlooked systems

1. List the public websites, APIs and applications used by the business.
2. Add staging, old subdomains, direct origins and administration services that still accept traffic.
3. Identify packaged products or appliances that may embed PHP and check their vendor notices.
4. Map each service to its host, PHP handler, runtime supplier and responsible administrator.
5. Record the fixed-build reference, current deployment state and next action for each row.

Prioritise exposure and business impact without forgetting the remaining services. An internet-facing enquiry handler and an internal reporting job need different containment decisions, but both need an accountable maintenance position. Discovery should include recent-looking versions as well as obviously old ones. Do not assume that a current application release implies its server runtime has been corrected.

Where the inventory is incomplete, make that visible. Assign a person to reconcile billing accounts, DNS records and deployment configuration with the service list. A retired campaign site can still be an active attack surface if nobody removed its hosting or route.

Select the supported correction, not an improvised shortcut

For upstream builds, the PHP project identifies fixed releases in the supported branches. For maintained distribution or hosting builds, use that supplier’s documented revision or backport. PHP 8.1 and older no longer receive normal PHP-project updates; a distributor or extended-support supplier may provide a specific correction. Require actual coverage evidence, and plan migration rather than interpreting one emergency backport as permanent maintenance.

Do not install a patching script, extension or repository merely because it promises an immediate answer. The business needs to know who maintains the artefact, what it changes and how it will be verified. A rushed new supplier can create a second security and support dependency.

Prepare maintenance and rollback that preserve the security goal

Write a brief plan: what will change, which functions may pause, who performs it, how the active processes will be replaced and how failure will be handled. Confirm a working management route and recoverable configuration. Use a backup or snapshot for recovery planning, but do not assume a snapshot is clean merely because it predates the latest alert.

Choose a fallback that does not reopen an unverified interpreter. Options can include a tested corrected alternative, a trusted static information page or temporary isolation of the affected dynamic function. Be specific about enquiry and order handling during the pause. A business continuity plan is more useful when it tells staff which channel to use than when it promises “no downtime” that the team cannot guarantee.

• Maintenance owner and decision-maker available during the change.
• Backup recovery route and access verified.
• Known application dependencies and PHP extensions recorded.
• Corrected fallback or isolation option agreed.
• Test cases and expected outcomes ready before the first update command.

Execute, then verify the runtime and the business result

Apply the correction through the identified supplier, retain transaction output and replace the appropriate processes. A controlled FPM restart, panel-managed handler replacement or container rollout must match the actual request path. Monitor completion and do not return a failed or unchecked node to the public pool simply because the others are healthy.

1. Match the installed package or image to the supplier’s fixed-build statement.
2. Confirm process replacement for each service and deployment node in scope.
3. Use a protected web-runtime observation to connect the domain to that corrected service.
4. Test dynamic pages, forms, accounts, integrations and scheduled tasks as applicable.
5. Review errors and initial live behaviour, then record acceptance or a clearly owned exception.

Use non-sensitive test data and payment-provider test modes. A success page alone does not prove the intended message or transaction arrived. Conversely, a mail-delivery failure can be an application configuration issue even when PHP is correctly patched; distinguish security acceptance from functional defects so each receives the right response.

Keep exceptions visible and trigger investigation when needed

An exception should name the affected service, why correction is incomplete, the containment currently applied, who owns resolution and when it will next be reviewed. “Waiting for the host” is not a complete exception unless it explains what happens to public exposure in the meantime. Escalate overdue decisions to the business owner rather than letting the same unverified service roll into normal operations.

Open an incident-response workstream if there are suspicious changes, unauthorised accounts, unexpected activity or insufficient confidence in system integrity. Patching prevents continued exposure to the corrected runtime defect; it does not establish that no intruder remains. Preserve evidence and get competent help where the team lacks the ability to assess the situation. Any customer or regulatory communication must reflect the facts and uncertainties, not a blanket assumption that every exposed site was breached.

Example: a short business status that is useful and honest

Status: public enquiry service temporarily limited.
Scope: main website and two staging services.
Completed: provider runtime correction confirmed for production.
In progress: staging worker replacement and integration tests.
Temporary measure: staging isolated from public access.
Incident assessment: no conclusion yet; relevant logs retained.
Next update: [agreed time and time zone].
Owner: [named responsible person].

This hypothetical update tells colleagues what they can rely on without exposing technical secrets or claiming more than the evidence supports. It is more helpful than saying “all secure” while tests or an investigation remain open. For a customer-facing update, remove internal details and explain the service impact and practical next step in ordinary language.

Close with evidence and a small follow-up plan

The business owner should receive the final scope, supplier references, installed or deployed identities, runtime verification, functional results and any investigation still open. Record which services were removed or isolated. Keep credentials and full diagnostic dumps out of the summary; link authorised readers to private evidence where necessary.

Then address the causes of delay: missing inventory, ambiguous agency responsibilities, untested backups, unsupported applications or no safe way to restart a service. Give each improvement an owner and a realistic date. A good emergency response should leave the organisation better able to prove its next update, rather than merely producing another completed maintenance ticket.