PHP2Shell: Your Servers Need an Emergency Patch. Your Users Need an Update.

On Monday evening, nobody had heard of PHP2Shell. By Wednesday afternoon, security teams around the world were patching servers outside every normal maintenance window — and some companies had pulled their products offline entirely rather than wait. Here's what happened, what to do about it, and the part most incident plans forget: telling your users what's going on while you fix it.

What happened

On October 21, 2026, the PHP project shipped emergency security releases for two critical flaws in the PHP runtime itself, together nicknamed PHP2Shell:

• CVE-2026-109618 — memory corruption when PHP handles an out-of-memory condition. A crafted multipart request can trigger it, even within your configured size limits.
• CVE-2026-109619 — a use-after-free where state left over from one request points at memory freed at the end of it, so a later request on the same worker can reach it.

Both are rated 9.2 (Critical) on CVSS v4, and both can allow unauthenticated remote code execution with the web worker's privileges, according to Rapid7's analysis.

This isn't a bug in a plugin or a framework. It's in PHP. That puts essentially every installation that serves web requests in scope — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Apache mod_php is considered the riskiest setup, because exploitation can succeed before your application code even runs.

The disclosure didn't go to plan, either. Details leaked on October 20, ahead of a planned October 22 release, and a proof-of-concept video was accidentally posted that evening, so the patches moved up by a day. Cloudflare reported exploit attempts before the patch was out, and watchTowr reported active exploitation attempts shortly after the release (The Hacker News).

What to do right now

If you haven't already, here's the short version. Your vendor's and distribution's advisories are the authoritative one.

1. Update PHP. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Only a build that contains both fixes counts as remediated.
2. Check distro packages by changelog, not version string. Many Linux vendors backported the fix, so a version number can look old while being patched — and the other way round.
3. On PHP 8.1 or older? Plan the upgrade. Those branches no longer get routine upstream updates. Limited source backports exist for 7.4, 8.0 and 8.1. PHP 8.2 itself reaches end of life on December 31, 2026.
4. Can't patch immediately? The advisories list partial mitigations — such as setting session.upload_progress.enabled=0 and enforcing tight request-size limits at your proxy — followed by a restart of every worker. They reduce exposure; they don't fix it.
5. Look back, not just forward. Signs worth checking in your logs: unusual multipart requests followed by memory-limit errors, bursts of HTTP 500s, oversized PHPSESSID cookies and unexplained worker restarts.

; Partial only. Patching is the real fix.
session.upload_progress.enabled = 0
; PHP 8.5 only:
fatal_error_backtraces = 0

The other half of the incident

Here's what stood out this week. Some teams didn't just patch — they went dark. The Hacker News reported that BambooHR took its service offline as a precaution, and several Dutch government and education sites did the same while they assessed their exposure.

That's a responsible call. It's also a scary one for users. From the outside, “we took the service down to apply a critical security fix” and “the site is broken and nobody knows why” look identical — unless you tell them which one it is.

An emergency patch is an incident even when nothing has gone wrong yet. You may need to:

• restart every PHP worker, which can drop requests or log people out,
• take a service offline for a short window,
• tighten upload limits in a way that breaks a feature some customers rely on,
• or tell enterprise customers, clearly and on the record, whether you were affected.

Each of those creates the same questions: Is it down? Is my data safe? When will it be back? If the answers aren't somewhere public, they land in your support inbox — at exactly the moment your team has the least time to answer them.

How a status page helps during a security patch

A status page won't patch PHP for you. What it does is take communication off your engineers' plates, so they can focus on the fix.

1. Announce the emergency maintenance before you start

Even 30 minutes of notice changes how users feel about downtime. Post a maintenance window that says what's happening, which services are affected and roughly how long it will take — or, for work that can't wait, open an incident with maintenance impact straight away. Subscribers are notified by email, Slack or webhook. Our guide on announcing scheduled maintenance covers the details.

2. Say “precautionary” out loud

Users assume the worst when a service disappears. One sentence — “We're applying an urgent security update. There is no evidence of impact to customer data.” — turns a mystery outage into a sign that you're on top of things. Only say what you know is true; if you're still investigating, say that instead.

3. Answer “were you affected?” once, publicly

After a high-profile vulnerability, customers and their security teams ask every vendor the same question. A clear public update — which component used PHP, when you patched, what you checked — answers hundreds of tickets at once and gives procurement teams something to link to.

4. Have the words ready before you need them

At 3 a.m. during an emergency patch, nobody wants to wordsmith. Incident templates for “security maintenance”, “investigating” and “resolved” let you post a calm, accurate update in seconds, and the AI writing assistant can tighten the wording when you're tired.

5. Meet users where they're already looking

When a vulnerability trends, people check X before they check your docs. With the X integration, incident and maintenance updates post there automatically, so the answer shows up in the feed next to the question.

6. Catch it when the fix breaks something

Mass worker restarts and new memory limits can cause their own problems — the fix adds a hard memory limit, so apps that relied on generous settings may start throwing errors. Endpoint monitoring catches a failing health check after the patch, before your customers do.

7. Close the loop

When it's over, mark the incident resolved and, if it was a big one, follow up with a short postmortem. “We patched within hours of the release” is a trust-building sentence. Use it.

A ready-to-use update

Adapt this for this week, or for the next one:

Patch fast, communicate faster

PHP2Shell will get patched and fade from the headlines. The pattern won't. Critical vulnerabilities increasingly arrive with little warning, leak early and come with exploit attempts already in flight. The teams that come out looking good aren't the ones that never go down — they're the ones whose users always know what's happening.

Patch your servers, then tell your users. Create a free Statusentry account and have a status page ready before the next emergency, or see what your users would see on our demo status page.

Sources: Rapid7, The Hacker News, watchTowr, Google Cloud. Details reflect reporting as of October 22, 2026; check your vendor's advisory for the latest.