Operations

Should I take my website offline because of PHP2Shell?

PHP Site Audit · Updated 2026-10-25

The direct answer

First confirm which system runs PHP and whether it is in scope. If an affected PHP system cannot be updated immediately, the NSA recommends taking that system offline until it is fully mitigated. The responsible operator should establish the system boundary and decide how to meet that guidance; do not assume a route-level filter is sufficient. A PHP vulnerability alone does not prove compromise.

Start with verified scope

Identify the hostnames, application owners, and runtime evidence. Ask the provider which PHP build serves production and whether the relevant vendor fix is available for the deployed branch. If it has applied a backport, request its advisory and confirmation that serving workers were restarted. A banner or scan is not proof of vulnerability or compromise.

If PHP is not confirmed, do not assume the site is affected or safe. Ask the deployment owner to map services and APIs. A managed platform may control its own runtime, while a custom integration may be hosted elsewhere. A downtime decision should apply to the specific service whose exposure and operational role are known.

If there is no confirmed compromise and the provider can apply a fix, coordinate a planned change with a short user-impact check. If there is credible active abuse, prioritize the incident lead's containment advice and evidence preservation over an informal website-status guess. The same technical advisory can lead to different operational choices depending on runtime exposure, business criticality, and the operator's ability to contain risk.

Compare options with the right people

The NSA's October 21 advisory recommends taking the affected system offline until it is fully mitigated if an immediate update is not feasible. First confirm which system is actually in scope, then have the system owner assess how to apply that recommendation while coordinating service impact and dependencies. Do not assume that restricting an admin route, adding a generic WAF rule, or keeping only the catalog online is sufficient: the PHP issue concerns the runtime, and the PHP project's advisory says mitigations address only specific paths rather than fully securing an installation.

If an immediate update is feasible, coordinate the vendor-supported patch and worker restart with the host, then check key site functions. If the update cannot happen now, discuss offline status and a concrete path to full mitigation with the incident/change owner. Record who made the decision, which services were included, the remaining exposure, and when the decision will be reviewed.

Use conditional escalation

Escalate urgently to the hosting or security team if the provider confirms an exposed vulnerable runtime and cannot patch promptly, if there is evidence of unauthorized server changes, or if the team cannot contain a credible active incident. The NSA's conditional offline recommendation applies when an immediate update is not feasible; the responsible operator should identify the affected system boundary and carry it through until the system is fully mitigated.

Do not make a shutdown decision from an unsolicited scanner alone or a public version banner that may not reflect the loaded package. Verify the contact and package evidence independently. When the runtime is confirmed in scope, treat the conditional NSA guidance seriously and have the operator document the patch or offline plan and timeline.

Keep patching and incident response distinct

A PHP vulnerability means a weakness may be present; it does not prove an attacker used it. Applying a patch reduces future exposure; it does not prove there was no earlier access. If logs, alerts, unexplained files, or account changes raise concern, preserve evidence and have the hosting/security team investigate under its incident process.

For a public update, state only what is confirmed: affected service, patch status, availability impact, and next update. Avoid claiming either ‘we were hacked’ or ‘there was no impact’ without incident evidence.

Taking an affected system offline does not necessarily mean closing every part of a business. The operator can identify independent services that do not use the affected runtime, such as a separately hosted status page. That separation needs architecture evidence. Hiding a login page, leaving the same PHP engine serving catalog requests, or placing a maintenance message inside the vulnerable application is not evidence that the affected system is isolated.

Agree on a review point for any temporary measure: who checks whether the vendor patch is available, when the decision will be revisited, what evidence permits reopening, and who communicates status. A mitigation left in place indefinitely may create operational issues or false reassurance. Keep the record factual, including uncertainties and the reason for the chosen availability decision.

Decision checklist

Confirm runtime and hostname.
Ask for package/backport status and patch timing.
Review direct access, sensitive routes, business impact, and containment options with the operator.
Decide downtime through the incident/change owner.
Investigate separately if compromise indicators exist.

Common questions

Should every PHP site be taken offline immediately?

The NSA recommends taking an affected system offline if an immediate update is not feasible, until it is fully mitigated. First have the operator confirm the system and package in scope; a public banner alone does not establish that scope.

Does a vulnerable version mean someone hacked my site?

No. It indicates a possible weakness, not evidence of exploitation. Investigate indicators separately.

Can I rely on a WAF while deciding?

It may reduce some exposure if correctly deployed, but it does not replace the runtime fix or prove every path is covered.