I was already in bed on October 20 when I saw a notice about two critical vulnerabilities in PHP.

The security team planned to release emergency patches the next morning. Both vulnerabilities were rated 9.2, and researchers were discussing the possibility of unauthenticated remote code execution.

One of our clients had an internet-facing PHP application running on its own infrastructure.

After reading what was known, I got out of bed, took the application offline, and emailed the client. It remained inaccessible until we could install the patch the next day. We brought it back online just after lunch.

Later analysis made mass exploitation look less likely than it first appeared. That does not mean the overnight shutdown was the wrong decision. It shows what vulnerability response looks like when the information is incomplete and the patch has not arrived.

The decision came before the full explanation

CVE-2026-109618 and CVE-2026-109619 were in the PHP engine itself. Updating the application, WordPress, or a plugin would not repair the runtime.

The affected code dated back to PHP 5.4. Fixed releases became available for supported PHP branches on October 21: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Older versions depended on operating-system vendors, commercial support providers, or source patches for backported fixes.

At bedtime on October 20, much of that operational detail was still unsettled. We knew the client had a reachable PHP application. We knew the issue could permit remote code execution. We knew public discussion was accelerating. We did not have a patch.

The available choices were not “patch now” or “ignore it.” They were:

Leave the application online until the fix arrived
Add temporary restrictions that might reduce exposure but could break the application
Take the application offline for a controlled period

Because the application could tolerate an overnight interruption, taking it down removed the immediate exposure while we waited.

Later evidence changed the risk estimate

On October 22, Sansec updated its PHP2Shell analysis. Public exploits did not work against a default PHP installation. Many required specific server conditions or another flaw, such as local file inclusion. Sansec concluded that the kind of broad, one-request exploitation seen with Log4Shell was less likely.

That was useful information. It arrived after the decision.

Incident response often works in that order. A firm has to act using the evidence available at the time, then adjust when better information appears. Waiting for complete certainty can leave a known exposure open during the period when defenders understand the least.

The answer is not to take every system offline whenever a severe vulnerability is announced. The decision should consider how exposed the system is, what an attacker could gain, whether a safe mitigation exists, how long the outage would last, and what the interruption would cost.

In this case, the possible security impact was high, the application faced the internet, the patch window was measured in hours, and the temporary business impact was manageable.

A website and a hosted application are different problems

Many law firms and CPA firms use PHP without knowing it. Their public website may run WordPress or another PHP-based platform managed by a host or marketing company.

Those firms still need confirmation that the underlying PHP runtime was patched, but they may have no direct access to the server. The practical task is finding the responsible provider and asking for evidence.

A self-hosted business application is different. The organization or its IT provider may control the operating system, web server, PHP packages, network exposure, backups, and logs. That control creates more options, but it also removes the assumption that a hosting company will handle the update.

This is the same ownership problem discussed in Your Firm’s Website Runs Software. Who Is Responsible for Patching It?. PHP2Shell made the question more urgent because an affected firm might need an answer in hours rather than during the next vendor review.

Someone needs authority to make the outage call

Taking down an application affects users and may interrupt client service. During an emergency, the response team should not spend the first hour figuring out who can authorize it.

For each internet-facing system, document:

The business owner and technical owner
The hosting location and support contact
The underlying operating system and major runtime dependencies
Who installs emergency updates
Who can restrict access or take the system offline
How users and clients will be notified
How the team will test the update and restore service
Which logs should be preserved if exploitation is suspected

The plan should also distinguish between a public website and an operational application. A website may be replaceable for a few hours with a static maintenance page. A portal used for filings, payments, or client documents may require a different continuity plan.

Installing the patch is only part of the return

Once the fixed PHP release became available, we did not treat package installation as the entire job. The application had to be updated, restarted, tested, and made reachable again.

If evidence suggests a system may have been targeted before the update, the firm also needs to decide whether an investigation is warranted. Patching closes the vulnerability. It does not prove that nobody used it earlier.

Available logs, administrator activity, changed files, new accounts, scheduled tasks, and unusual outbound connections may matter. The exact review depends on the application and hosting environment.

The return-to-service plan should answer two separate questions: Is the system fixed, and is there any reason to believe it was compromised?

Make the next decision easier

Most vulnerability notices will not require getting out of bed and taking down a server. The useful preparation is knowing which ones might.

Which applications can the public reach? Which runtimes and frameworks do they depend on? Are any versions unsupported? Who receives urgent vendor notices? Who can approve downtime? How long can each system remain unavailable? Where are the backups and logs?

PHP2Shell became less universal than the earliest warnings suggested. The exposed application still needed the update, and the temporary outage gave us time to apply it without leaving the system reachable overnight.

A controlled outage is a business decision as much as a technical one. Make the authority, contacts, and recovery steps clear before the next late-night notice arrives.

If nobody can quickly identify who patches an internet-facing application or who can take it offline, Artech can help document the ownership, exposure, update, and recovery process.