php2shell (CVE-2026-109618 / CVE-2026-109619): A Practical Response Playbook for On-Call Teams

What are the php2shell vulnerabilities?

Both bugs are in the PHP engine itself, not in a framework or plugin. Updating application code doesn't fix them. You have to update the runtime.

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): RCE via out-of-memory corruption. If a request hits an out-of-memory condition while PHP's internal request data is only partly initialized, request cleanup can treat that invalid data as valid. Several multipart (form/file-upload) parsing behaviors can push a request into OOM while it still looks like it's within PHP's limits.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): RCE via stale global state. After a fatal error, request-owned state can outlive its memory. A later request on the same worker can then use the freed memory (a use-after-free).

The PHP project rates both at CVSS v4.0 9.2 (Critical), and NVD lists the same score from php.net (CVE-2026-109618, CVE-2026-109619).

Who's affected

The PHP security advisory says the risk covers all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk setup: it has a demonstrated exploit where an unauthenticated request triggers the attack before any application code runs.

Affected branches and first fixed versions

Exploitation status

CISA's October 21 alert said it had not observed exploitation as of publication, and neither CVE was in the KEV catalog when we checked. Other vendors have reported activity: Amazon Threat Intelligence (as relayed by Tenable) saw an attempt on October 17, before disclosure, and watchTowr reports exploitation attempts in its honeypots. Researchers also note that many public "PoCs" don't work, and that fake exploit repos can carry malware (Tanium). Treat this as urgent, but there's no need to panic.

Step 1: Check your PHP exposure

1. Inventory PHP everywhere. CISA notes that PHP is often bundled inside other software, so you may not see it directly. Check hosts, container base images, appliances and vendor products.
2. Get versions. Run php -v on hosts, check package managers (dpkg -l | grep php, rpm -qa | grep php) and scan image manifests. Remember the CLI and the web SAPI can be different builds.
3. Identify the SAPI. Find out whether you run mod_php, PHP-FPM, php-cgi, FrankenPHP or LiteSpeed. Put internet-facing mod_php first.
4. Check managed platforms. Cloud providers are publishing their own guidance. AWS, for example, has a bulletin covering Elastic Beanstalk, Lightsail and Amazon Linux.

Step 2: Patch, or mitigate while you patch

• Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your distro's patched package. Distros and LTS vendors got the patches in advance. The PHP project says updating is the only complete fix.
• If you can't update right away, php.net lists partial mitigations. None of them make an installation safe:
  • For CVE-2026-109618, set memory_limit=-1 in a way applications can't override. Lower post_max_size and enforce request-size and multipart limits at the proxy.
  • For CVE-2026-109619, set session.upload_progress.enabled=0 and restart every worker. On 8.5, also set fatal_error_backtraces=0.
• Can't update immediately, or on an unsupported branch (8.1 and older)? CISA advises taking PHP-based systems offline until they're patched or updated. A WAF may help in the meantime, but it doesn't replace patching.
• Hunt: Look for PHP workers spawning shells or downloading tools. Check for unexplained worker crashes and unusual multipart requests. Amazon (as relayed by Tenable) recommends starting your review from at least October 17.

Step 3: Run the incident response well

The technical fix is the easy part. Most of the friction comes from coordination.

Page the owner, not a channel. Map each PHP service to an owning team and an on-call rotation before you need it. Post the CVE in a busy channel and everyone assumes someone else has it. Page the person on call for the service.

Set escalation timeouts that match the severity. For a critical, internet-facing issue, a short acknowledgement window followed by an escalation to a secondary or a manager keeps a missed page from turning into a missed day.

Make acknowledgement mean ownership. An ack should say "I'm on it." Ask responders to post what they're checking, so two engineers don't patch the same fleet while a third service gets missed.

Keep stakeholders informed on a schedule. Security, support and leadership will ask "are we affected?" Agree on a regular update cadence, such as every 60 minutes until you've confirmed exposure, then at each milestone. Pull them into the incident's update feed so they stop pinging responders directly.

Track it as one incident with clear sub-tasks: inventory, patch per service, mitigation where patching is blocked, and the hunt for signs of compromise. Close each one explicitly.

Run a blameless post-incident review. Ask how long it took to get a complete PHP inventory, which services had no clear owner, whether any pages went unacknowledged and why, and which hosts couldn't be patched quickly. Turn the answers into rotation, ownership and patching improvements before the next advisory lands.

Where OpsPing fits

If this week showed gaps in how your team gets paged, OpsPing is built for this kind of response. Pages use iOS Critical Alerts and Android Do Not Disturb bypass, so they actually wake the on-call engineer at 3 a.m. Team and Business plans add a voice-call fallback. Stakeholder seats are free, so leadership and support can follow updates without paying for a license. OpsPing is free for up to 5 responders, Team is $8/responder/month and Business is $15/responder/month.

If you're on Atlassian's Opsgenie, which reaches end of support on April 5, 2027, OpsPing has an Opsgenie-compatible API that makes moving existing integrations simpler. OpsPing is an independent product and is not affiliated with, endorsed by, or sponsored by Atlassian.

Whatever tool you use: patch first, then fix the paging gaps this week exposed.

Sources

• PHP security advisory and release announcements (Oct 20–21, 2026): php.net/archive/2026.php
• PHP Foundation, "Today's PHP Security Release…": thephp.foundation
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618): github.com/php/php-src
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): github.com/php/php-src
• NVD, CVE-2026-109618: nvd.nist.gov
• NVD, CVE-2026-109619: nvd.nist.gov
• CISA alert (Oct 21, 2026): cisa.gov
• CISA Known Exploited Vulnerabilities catalog: cisa.gov
• CERT-EU security advisory 2026-018: cert.europa.eu
• AWS security bulletin 2026-143-AWS: aws.amazon.com
• Tenable FAQ: tenable.com
• Tanium response guide: tanium.com
• watchTowr FAQ: watchtowr.com

Opsgenie and Atlassian are trademarks of Atlassian. They are named here only to identify the product.

— The OpsPing team