--- title: "PHP2Shell (CVE-2026-109618): Patch Fast, Tell Users Faster | Statusentry" description: "Two critical PHP RCE flaws forced emergency patches and precautionary outages. What to update now, and how a status page keeps users informed while you fix it." url: https://statusentry.com/blog/php2shell-emergency-patch-status-page updated: 2026-10-22 --- [All posts](https://statusentry.com/blog) Best practices # PHP2Shell: Your Servers Need an Emergency Patch. Your Users Need an Update. Two critical PHP flaws leaked early and sent teams scrambling to patch — some took their services offline entirely. What happened, what to patch, and why the update your users see matters as much as the one on your servers. Oct 22, 2026 6 min read by Statusentry team 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. **In short:** two critical flaws in the PHP runtime (CVE-2026-109618 and CVE-2026-109619) allow unauthenticated remote code execution. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now — and treat the patch as an incident, with a public update your users can follow. ## 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](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/). 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](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html)). ## 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. Temporary mitigation (php.ini or FPM pool — then restart all workers) ``` ; 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](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html) 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**](https://statusentry.com/blog/how-to-announce-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**](https://statusentry.com/blog/incident-templates) for “security maintenance”, “investigating” and “resolved” let you post a calm, accurate update in seconds, and the [**AI writing assistant**](https://statusentry.com/blog/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**](https://statusentry.com/blog/x-twitter-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**](https://statusentry.com/blog/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**](https://statusentry.com/blog/postmortem-template). “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: Urgent security maintenance Status: In progress · Impact: maintenance Title: Urgent security update We're applying a critical security update to our platform in response to newly disclosed vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619). During this window you may see brief interruptions or be asked to log in again. We have no evidence that customer data has been affected. We'll post an update here as soon as the work is complete. Resolved Status: Resolved The security update is complete and all services are operating normally. Thank you for your patience. If you notice anything unusual, please contact our support team. ## 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](https://app.statusentry.com/signup) and have a status page ready before the next emergency, or see what your users would see on our [demo status page](https://demo.statusentry.com/). *Sources:* [Rapid7](https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/), [The Hacker News](https://thehackernews.com/2026/10/php-issues-emergency-patches-for-two.html), [watchTowr](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/), [Google Cloud](https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619). Details reflect reporting as of October 22, 2026; check your vendor's advisory for the latest. ## Keep reading [All posts](https://statusentry.com/blog) Product 5 min read ### [X (Twitter) Integration: Post Status Page Updates Automatically](https://statusentry.com/blog/x-twitter-integration) Statusentry can post your public incidents and scheduled maintenance to X automatically. Why status updates belong on X, how to connect your accounts, and how to write updates that work in a busy feed. Best practices 7 min read ### [Status Pages in the Age of AI Search: Making Your Uptime Answerable](https://statusentry.com/blog/geo-status-page-ai-search) People now ask ChatGPT and Perplexity whether a service is down. What generative engine optimization (GEO) means for status pages, what makes one answerable, and how we made statusentry.com readable for AI search and agents. Try Statusentry ## Communicate incidents calmly, transparently, instantly. Start with a 30-day Enterprise trial. Afterwards, keep the free plan with no time limit. [Start free](https://app.statusentry.com/signup) [View demo status page](https://demo.statusentry.com/)