PHP2Shell: why some websites stay offline longer

A security patch is available. Why is a website still offline? With PHP2Shell, the gap between an available fix and a service approved to return can involve more than a package update: an old application, a pending vendor package or a business process nobody has tested on the new runtime.

PHP2Shell is a serious security issue. A longer interruption can nevertheless be a deliberate protective decision. An unreachable website alone demonstrates neither a successful attack nor poor work by the operations team.

As of 22 October 2026. News with operational analysis. The possible reasons for delay below are scenarios, not diagnoses of particular unavailable websites. Update, 24 October: an additional PHP advisory published on 23 October is noted below.

What is confirmed

On 21 October 2026, the PHP project released security updates for CVE-2026-109618 and CVE-2026-109619. They can allow unauthenticated attackers to execute code on affected systems. The flaws are in the PHP runtime. Current release branches are affected too; PHP2Shell is not solely a legacy-software vulnerability. The project identifies PHP installations handling web requests as at risk. PHP security advisory

The corrected upstream versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For distribution packages, also check the respective provider’s fix status. Updating a CMS or plugin alone does not repair the underlying PHP vulnerability. PHP, Cloudflare

Cloudflare reports observed attack traffic and deployed WAF protections. It explicitly continues to urge customers to patch. An upstream filter does not replace a fixed runtime. Observed attack attempts also do not demonstrate that every targeted website was compromised. Cloudflare report

Update, 24 October: CERT-EU’s 23 October revision identifies an additional PHP RCE path involving an unusual combination of configuration and application code. PHP’s separate advisory recommends session.upload_progress.enabled=0 until the next regular bugfix release. If you already applied that mitigation from the 21 October advisory, keep it in place. According to PHP, applications that do not change the session serializer at runtime can leave the feature enabled. Check the specific guidance separately: the version updates above are not a blanket answer to every additional PHP advisory. PHP advisory dated 23 October, CERT-EU

An old version number does not automatically mean unpatched

PHP 8.1 and older branches no longer receive regular PHP project updates. For PHP2Shell, however, the project provides minimal source backports for 7.4, 8.0 and 8.1. Distributions and LTS providers can also supply corrected packages. Such an exceptional fix does not restore regular upstream support. PHP

Canonical, for example, lists corrected Ubuntu packages for older PHP branches too. Older Ubuntu releases receive them through Expanded Security Maintenance. A package can therefore retain an older PHP base version while containing the fix. The complete package version, source and associated security advisory are decisive. Canonical

This matters for assessment: not every old installation must immediately undergo a major version upgrade. A suitable maintained backport can shorten the immediate repair path. Without one, a security update can become a migration project.

Why an update can take several days

To assess the effort for your system, first clarify the update path. The following questions move from ownership to verification. They explain possible delays, not the cause of a particular outage.

1. Who supplies the fix for your system?

Do you operate PHP yourself? Check with your distribution or runtime provider which corrected package fits the installation. An available backport may avoid a major version change.

Does a hosting provider operate the runtime, or is PHP embedded in a vendor product? You need its assessment of the affected product and suitable update. NCSC-NL mentions devices and management interfaces with embedded PHP. Their runtime cannot necessarily be replaced independently. NCSC-NL

Ask specifically: “Is our product version affected? Which update fixes both CVEs? When can we install it?” Record the answer, an owner and next review date. A missing vendor package is a different task from an available update nobody internally owns.

2. Must the application move to a new runtime?

If a version change is necessary, check compatibility of the CMS, extensions and custom code. Required adaptations must be implemented and tested before approval. Not every security fix requires migration. Establish the package path from step one first.

A reachable homepage is not a successful functional test. With the business team, select workflows whose failure would interrupt operations:

These are examples for your test plan. If an important function is missing, record the deviation and responsible role. That turns “the application is not working yet” into a concrete task.

3. Is the fix actually active?

An installed package and an updated running application are different states. Canonical notes that affected applications may need restarting after an update. Have operations check which version actually processes web requests. Canonical

Is there also evidence of compromise? The team must then investigate possible unauthorised changes or access. A patch closes a vulnerability; it does not reverse earlier intrusions. That investigation is additional work when there are grounds for suspicion, not a claim about all affected systems.

Staying offline can be the right interim decision

CERT-EU recommends updating affected systems immediately. Where that is not feasible, organisations should consider isolating internet-facing applications until a fix is applied and verified. CERT-EU

Our assessment: such an interruption needs an owner, a next review date and clear return-to-service criteria. “We are waiting for the vendor package” is a concrete dependency. “We will leave it off for now” is not a recovery plan.

Operations and business teams should jointly answer before approval:

• Is a suitable fix installed and active for the runtime actually used?
• Do business-critical workflows work on that version?
• Have unresolved suspicions been assessed and necessary follow-up actions clarified?
• Who decides on returning to service and informs those affected?

This does not yield a universal recovery duration. An installation with maintained packages and useful tests can follow a different path from a custom application unchanged for years.

Why regular updates make a difference

Security updates close known vulnerabilities. Postponing them leaves the flaw present for longer. NIST therefore frames patch management as preventive maintenance: identify, prioritise and install updates, and verify effective installation. NIST SP 800-40 Rev. 4

Legacy applications add another issue: regularly checking compatibility and end of support lets you plan necessary adaptations. If they become visible only in a security emergency, migration, troubleshooting and recovery compete for the same time. Regular maintenance can reduce that backlog. It prevents neither every new vulnerability nor guarantees trouble-free updates.

Plan a repeatable process: who monitors advisories? Who assesses affected systems? Who updates, tests important functions and approves operations? Critical vulnerabilities need an urgent path; the next routine maintenance window is not automatically an acceptable deadline.

Turn outstanding updates into a traceable process

For each affected system, connect responsibility, measure, deadline and test result. Link technical work to the business process: who needs the service? What must work again? Which unresolved dependency prevents approval?

In Kopexa, you can connect affected assets, risks and measures and model processes using BPMN. Evidence is attached to measures. This records which checks are complete and what work remains. Your operations team continues to perform updates and technical tests.