php2shell: Two Critical PHP RCEs, a Pre-Patch Leak, and the PHP You Didn't Know You Had

The PHP project released patches today for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, named php2shell by Huntress and adopted in NCSC-NL's coordinated tracking response. Both are rated CVSS v4.0 9.2. What makes today different from a routine critical patch is that the technical details leaked to social media on October 20, the day before the coordinated disclosure was scheduled to close. Screenshots circulated before posts were removed. Researchers on both sides of the equation had a head start before the patches shipped.

That accelerated timeline is why this is a patch-now situation, not a patch-this-week situation. PHP powers an enormous share of web infrastructure: WordPress, Drupal, Joomla, Laravel applications, and a long tail of vendor dashboards, appliances, and admin interfaces that organizations don't always track carefully. The surface area is large, aging in many places, and partly outside your team's direct control.

TL;DR

• PHP released patches today (October 21, 2026 at 14:00 UTC) for two critical RCEs in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12.

• Technical details leaked on October 20, closing the preparation window before attackers could begin research. This is patch-now, not patch-this-week.

• The highest-risk configuration is Apache prefork with mod_php. PHP-FPM deployments have a different exposure profile due to process isolation differences.

• PHP 8.1 and all older versions receive no patches. Those deployments need isolation, WAF coverage, or retirement. Not a waiting position.

• Active scanning with php2shell-specific tooling was observed from 08:36 UTC today, 5.5 hours before patches shipped; OOM exploitation attempts followed at 16:05 UTC. This is active, not theoretical.

• If patching today is impossible: disabling

  session.upload_progress.enabled

  in php.ini provides partial mitigation for CVE-2026-109619, but it does not make an installation safe.

What Broke and Why It Matters

Both vulnerabilities trace back to how PHP handles memory state across web request processing.

CVE-2026-109619, the one with the clearest technical path, involves what the PHP advisory calls stale global state: request-owned internal state that survives after its backing memory has been freed, leaving a later request on the same worker operating on memory PHP has already reused. Jackalsyn's technical analysis identifies the specific component as PHP's serialization layer. During session upload progress tracking, a feature that's enabled by default, PHP can hit memory exhaustion before it finishes initializing a worker process. If that happens, the next request handled by the same worker lands on that freed memory. Researchers have confirmed heap corruption under this condition on Apache prefork with mod_php.

CVE-2026-109618 involves a related out-of-memory edge case where PHP's request cleanup code can misinterpret partially-initialized data, though public analysis suggests its exploitation path may be structurally limited (more on that below). The PHP project treats both as critical and patches both in today's release.

What an attacker does with this: craft a multipart form upload designed to exhaust the memory limit, trigger the incomplete teardown, then send a follow-up request that lands on the same worker process. The freed memory becomes a write primitive. Getting to reliable code execution from there requires additional heap manipulation: the kind of work attackers invest in when a high-value target is available and the technical starting point is already public.

One nuance worth naming: the most detailed public technical analysis published on October 21, by researcher Jackalsyn (jackalsyn.com/posts/php-up-2026.html), concludes that CVE-2026-109618 may have a structural path limitation preventing reliable exploitation, and that CVE-2026-109619 requires Apache prefork with glibc 2.39 to reproduce heap corruption consistently. That's a more constrained picture than CVSS 9.2 implies at first read. The PHP project and NCSC are still correct to treat this as critical and recommend immediate patching. "Not yet demonstrated as reliable" isn't a safe operating position, especially when the technical starting point is already public and the research community has had more time to work with it than the vendor intended. Patch it like it's 9.2, because the alternative is making an operational bet against day-zero analysis while attackers have the same data and no patch cycle to wait on.

Your Exposure Depends on How PHP Runs in Your Environment

The key variable is which Server Application Programming Interface (SAPI) mediates between your web server and PHP, because that determines whether worker processes are isolated from each other and from the web server itself.

Apache prefork with mod_php is the highest-risk configuration. PHP processes share address space with the web server, which means memory corruption in one request's handling can affect the broader process environment. The public research before the patch drop focused here. If your stack runs Apache prefork with mod_php, assume this is the scenario the advisories are describing.

PHP-FPM (FastCGI Process Manager) is the more common configuration in modern deployments and separates PHP workers from the web server entirely. According to the official PHP advisory, PHP-FPM workers exit on startup failure rather than continuing to process requests with partially-initialized state. That's a meaningful architectural difference from mod_php. Current guidance still recommends patching FPM deployments, and that's the right call. But the risk profile for FPM is different from prefork, and understanding that distinction helps you sequence your response.

CGI and other server-managed configurations have process separation properties similar to FPM for this vulnerability class.

If you don't know which SAPI your PHP applications use, that's the first thing to determine. Organizations running cloud-managed PHP (managed WordPress hosting, PHP cloud functions, SaaS products with embedded PHP) may have their providers patch on their behalf, but only if the provider runs current supported versions and moves quickly. Verify; don't assume.

The EOL Problem Nobody Manages Well

PHP 8.1 reached end of life in November 2024. PHP 7.x, 5.x, and all older versions have been out of support for longer. For CVE-2026-109618 and CVE-2026-109619, there are no patches for any of those versions. The PHP project does not backport security fixes to unsupported branches.

This matters because old PHP doesn't only show up in internal web applications that engineering teams own. It appears in:

Content management systems on shared hosting, particularly WordPress installations where the hosting provider controls the PHP runtime. This is the one that surprises the most teams: your WordPress site can run current core, current plugins, and a current theme, and the PHP interpreter underneath can still be 8.1 because the hosting provider controls that layer and moves it on their own schedule. The application being current doesn't mean the runtime is current.

Commercial and open-source appliances, where vendor products embed PHP as part of their application stack and maintain their own patch cycle, which can lag the upstream PHP project by weeks or months. Security appliances, network management interfaces, monitoring dashboards: many of these run PHP and update on vendor schedules that have no relationship to today's advisory.

Legacy applications where PHP upgrades require significant refactoring effort and have been deferred because the app "works." Those deferrals typically result in PHP 7.x or early 8.x deployments that now have no patch path.

NCSC's guidance is direct: if you can't patch a system running PHP, consider taking it offline until it can be fully mitigated. That's a significant operational decision for production systems. It reflects the actual risk of running an unpatched, internet-facing PHP installation once exploitation techniques mature.

For vendor appliances specifically, you need to know where PHP lives in your supply chain right now. NCSC-NL has published a GitHub tracking repository at github.com/NCSC-NL/php2shell to catalogue affected products as vendor advisories arrive. Get your vendor contacts active and watch that repository through the week.

What to Do Right Now

The response sequence is clear. The inventory step is where most organizations will find surprises.

Patch immediately for PHP 8.2, 8.3, 8.4, and 8.5 deployments. The patched versions are 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Check your Linux distribution packages: most distributions maintain their own PHP packages, and availability of updated packages varies by distro and branch. Don't assume patched upstream means patched in your distribution's package repository.

Build a complete PHP inventory. This means direct PHP installations and PHP embedded in third-party software and appliances. The question isn't just "do we run PHP" but "where does it run, what version, what SAPI, and who is responsible for patching it." Prioritize internet-facing systems first; internal systems second. Most organizations underestimate how many places PHP appears once they actually look.

Apply emergency mitigations for systems that can't patch today. The PHP advisory (php.net/archive/2026.php#2026-10-21-5) documents these explicitly. For CVE-2026-109619: disabling session upload progress tracking (session.upload_progress.enabled = 0 in php.ini, followed by a worker restart) closes the primary attack path researchers have documented publicly. For PHP 8.5 specifically, the advisory also calls for setting fatal_error_backtraces=0. See the advisory for the complete list. For CVE-2026-109618: setting memory_limit = -1 via php_admin_value in FPM pool or Apache configuration, combined with low post_max_size values, reduces the OOM trigger surface. The advisory is direct: these measures reduce exposure but do not make an installation safe. Patching is the only complete solution.

Isolate or take offline EOL PHP deployments that can't be upgraded or reach a vendor patch. A PHP 7.x or 8.1 instance on the internet with no patch path is the most exposed position right now. The framework for the offline-versus-WAF decision: if you can get a WAF in front of it that blocks or rate-limits multipart form-data POSTs, that's a defensible temporary position. If you can't do that either, offline is the correct answer. An internet-facing unpatched PHP instance with no network-layer coverage isn't a calculated risk. It's an unmanaged one.

Open vendor escalations now. For any PHP-based appliance, SaaS product, or managed service in your environment, ask your vendor directly: what version of PHP does this product run, are you affected, and when is your patch? Don't wait for them to send an advisory. The NCSC-NL tracking repository will help you identify which vendors have confirmed status.

Monitor for exploitation indicators. Huntress recommends watching for PHP or web server processes spawning shells, interpreters, download tools, or reconnaissance commands. These are behavioral signs of PHP exploitation rather than CVE-specific indicators, so compare them with each server's normal activity. If you find suspicious activity, isolate the affected host, preserve available evidence, and coordinate investigation with urgent patching.

Signs You May Have Already Been Impacted

Scanning is already active. Ellio.tech observed php2shell-specific tooling hitting servers from 08:36 UTC today, 5.5 hours before patches shipped, with OOM exploitation attempts confirmed by 16:05 UTC. Technical details became public on October 20 before the patches shipped, making that date a practical minimum starting point for a lookback. It does not establish when exploitation began, so search earlier when your retention and threat intelligence support it. Prioritize internet-facing Apache prefork deployments with mod_php, which PHP identifies as the highest-risk configuration, but include other web-serving PHP installations in the hunt.

Prioritize evidence of execution and persistence. An unexpected shell or reconnaissance command launched by a PHP or web server process, or an unrecognized persistence mechanism, is stronger evidence of compromise than a large multipart request or memory-exhaustion error alone. Treat those lower-confidence events as correlation points that help establish the sequence around higher-confidence activity.

In your request telemetry: Look for unusually large multipart form submissions to PHP endpoints, particularly when they precede a memory-exhaustion error or suspicious process activity. Standard Apache access logs usually record the request line, status, and response size, not multipart filenames or body contents; Apache documents the fields available in its common and combined formats. Inspect filenames or multipart fields only where a WAF, reverse proxy, or other body-aware control already captured them, and account for truncation and privacy controls. For CVE-2026-109619, correlate closely timed requests that may have reached the same worker, but treat the sequence as an investigative lead rather than a required same-IP or same-endpoint signature. Ellio.tech identified several highly specific HTTP signatures in observed scanning traffic. In WAF, reverse proxy, or extended logging: search for User-Agent strings php2shell-scan/109618, php2shell-109618, and php2shell-verify/1.0; multipart boundary strings beginning with ----p2s or ----p2shell; and the form field name PHP_SESSION_UPLOAD_PROGRESS in POST bodies. Matches on any of these are scanner-specific, not generic PHP traffic.

In your PHP and web server error logs: Search for memory-exhaustion errors such as Allowed memory size of X bytes exhausted, especially during request initialization and near large form submissions or anomalous child processes. Datadog's reproduction supports those as investigation leads, while also noting that successful exploitation does not necessarily crash the worker. An OOM event is not proof of exploitation, and no verified warning sequence should be treated as a definitive server-side signature.

In your process tree and EDR data: Huntress identifies the parent processes to watch as php-fpm, php-cgi, php-cgi.exe, httpd, and apache2. Investigate these processes spawning shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl), or network tools (curl, wget, nc, certutil.exe). Also review command lines for reverse-shell patterns such as /dev/tcp/, fsockopen, and mkfifo, and for reconnaissance commands such as whoami, id, uname -a, and ipconfig. These behaviors can have legitimate administrative or application-specific causes, but unexpected execution from a web server process warrants immediate triage. Ellio.tech's payload analysis found the malware masquerading as these process names: telnetd, udhcpc, upnpd, watchdog, syslogd, klogd, uhttpd, and uchttpd — a web server process that has become syslogd is worth investigating. Also search logs for the string JACKALPOC: that is the validation canary the scanning tooling injects to confirm code execution before delivering the payload. Its presence in your logs means code ran.

In your DNS and firewall logs: Ellio.tech confirmed payload delivery from 92.118.112.100 (AS215540) and C2 communication to thunder.godofthunder.st and hackattackkaboom.botlesscucks.st. Outbound connections to ports in the 50000-52000 range from web server processes are a secondary indicator. The payload binary SHA-256 is 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486 (179 KB, statically linked ELF x86-64); run it against EDR and AV telemetry. Note that C2 infrastructure evolves quickly; treat these as starting points, not the complete picture.

In the file system and persistence mechanisms: Review new or recently modified PHP files in web roots, upload directories, and temporary paths, especially files created by the web server account or absent from deployment records. Huntress also recommends checking unfamiliar cron jobs, scheduled tasks, and accounts. These are common signs of post-exploitation activity, although successful exploitation does not require an attacker to leave a web shell on disk.

Preserve available logs and capture volatile evidence before restarting a suspected compromised host where feasible. Isolate that host and engage incident response while patching and containing the rest of the exposed estate. Do not leave a vulnerable server exposed while completing the lookback. Patching closes the vulnerability, but it does not remove persistence or access an attacker may already have established.

Bottom Line

Two critical PHP RCEs landed today with a research head start for attackers because the details leaked before the patch. The technical path to exploitation is more constrained than CVSS 9.2 implies for some configurations, particularly PHP-FPM. But "constrained" and "safe" are not the same word, and the research community now has more working time on this than the vendor originally intended. Patch it like it's 9.2.

The inventory problem is the real work here. Patching the PHP you know about takes an hour. Finding the PHP running in vendor dashboards, shared hosting environments, and appliances you don't actively manage is the longer job, and that's where organizations tend to find two or three times the exposure they expected. Start both today in parallel.

Watch NCSC and NCSC-NL through the week. The affected-software list in the tracking repository is actively growing as vendors confirm status.

FAQ

Is my PHP-FPM deployment as exposed as Apache prefork?

No, but it's not safe either. PHP-FPM's process isolation means workers exit on startup failure rather than continuing with partially-initialized state, which changes the exploitation mechanics for CVE-2026-109619 specifically. The current public research demonstrates heap corruption on Apache prefork with mod_php. That said, FPM deployments should still be patched immediately: the attack surface is different, not absent, and researchers with the leaked technical details are actively working on this.

What if I can't patch until later this week?

Apply the emergency mitigations from the PHP advisory. For CVE-2026-109619, disabling session upload progress tracking in php.ini and restarting workers closes the attack path researchers have documented publicly. For CVE-2026-109618, adjusting memory_limit and post_max_size reduces the OOM trigger surface. These are time-buying measures, not substitutes for patching. The goal is to reduce your exposure while completing the upgrade on the fastest schedule your operations allow.

My hosting provider manages my PHP. Am I covered?

Only if they're running a supported version and have applied or committed to apply the patches. Managed WordPress hosting, shared hosting, and cloud PHP services vary significantly in their patch cadence. Contact your provider directly and ask what PHP version they're running and when they plan to deploy the update. Don't assume managed means patched.

How do I find PHP running in vendor appliances I don't control directly?

The NCSC-NL php2shell tracking repository on GitHub is the best current resource for affected vendor software as advisories are confirmed. Beyond that, audit your vendor relationships: any appliance with a web interface is a candidate, and "web interface" very often means PHP. Your vendor contacts and security subscription services are the escalation path for confirmation and patch timelines.

Is there active exploitation happening right now?

Yes. Ellio.tech observed php2shell-specific scanning beginning at 08:36 UTC today, 5.5 hours before patches shipped, and OOM exploitation attempts by 16:05 UTC. At least 25 distinct source addresses scanned within 13 hours using 4-5 distinct tool families, and php2shell was integrated into polyglot scanning infrastructure by 20:40 UTC. Huntress had not confirmed successful shell access in their monitored environments as of the patch release window, but active exploitation tooling is circulating and working. Patch now.