CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell, are flaws in the PHP interpreter itself. Every application on an affected build inherits the exposure regardless of framework, CMS or plugins.
The PHP security team scored both at 9.2 on CVSS v4.0. A remote attacker with no credentials can run code as the web server worker account. PHP2Shell also includes an unauthenticated path that discloses live worker memory without executing any code.
Exploitation started before the patch. Amazon Threat Intelligence recorded an attempt against its MadPot honeypots on October 17, four days ahead of disclosure, and now describes PHP2Shell as broadly exploited in the wild.
Working exploits exist. Calif and Wiz each demonstrated pre-authentication RCE against current application releases. Most publicly circulating proof-of-concept code crashes workers rather than achieving execution, so attacker capability in the wild is unknown.
Patching is the only complete fix. Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, with source backports for 7.4, 8.0 and 8.1. PHP states its interim settings do not make an installation safe.
Exploitation attempts and the memory-disclosure path leave almost no web telemetry. Workers stay up, responses return HTTP 200 and application logs stay clean because no application code runs. Code execution does leave host artifacts. Hunting starts at October 17, not at the disclosure date.
No victim has been publicly named, no incident report with post-exploitation detail has been published, and no tracked threat actor has been attributed. The traffic observed so far looks opportunistic and multi-sourced rather than targeted.
Howler Cell assesses with high confidence that exploitation attempts against internet-facing PHP are now routine, and with moderate confidence that a publicly documented compromise with post-exploitation evidence, and a KEV listing, follow within days. Vendor reports of confirmed incidents already exist. What does not yet exist is a published case with technical detail. Patch under emergency change.
The chain below is a request-parsing chain. Steps 2 through 4 complete before any application code executes, which is why application-layer authentication does not stop it.
Any internet-facing host serving PHP. There is no authentication to bypass, no session to steal and no specific vulnerable endpoint to discover. PHP rates Apache mod_php highest risk because a working exploit was demonstrated there and it runs before any application code. On PHP-FPM, exploitation is possible but depends more on the application.
A multipart/form-data POST carrying upload-progress fields, or a body with no usable Content-Length, sent to any endpoint whether or not that endpoint accepts uploads. PHP parses it during request setup.
CVE-2026-109618: memory exhaustion interrupts PHP mid-initialization and cleanup then processes partially initialized request data. CVE-2026-109619: session or decoder state from an interrupted request survives and a later request on the same worker consumes it. Wiz also identified an OPcache type confusion where a partially persisted script leaves stale shared metadata that another worker resolves to a pointer of the wrong type.
Code execution as the web worker account, or memory disclosure. The disclosure primitive returns an attacker-sized region of live worker memory through a malformed PHPSESSID response cookie, including passwords, tokens and API keys, with no code execution and without the application ever calling session_start().
Web shell written to the web root, shell or script interpreter spawned from the PHP worker process, cron entries and accounts created by the worker account, then lateral movement. A web server compromised this way often has network reach to application databases and internal services.
Figure 1: PHP2Shell attack chain with detection break points A through E.
|
Branch |
Status |
Fixed version or action |
|
8.5 |
Supported |
8.5.12 |
|
8.4 |
Supported |
8.4.27 |
|
8.3 |
Supported |
8.3.36 |
|
8.2 |
Security fixes only, end of life December 31, 2026 |
8.2.35 |
|
8.1, 8.0, 7.4 |
End of life |
Minimal source backports from PHP. Vendor or distribution builds may be available |
|
5.4 to 7.3 |
End of life |
No fix from the PHP project. Upgrade or remove from the internet |
Distribution packages often keep the original upstream version number. Confirm the fix by searching the package changelog for the CVE identifiers rather than relying on php -v. The finders trace the oldest affected code to PHP 5.4.0.
Howler Cell compared the official PHP 8.5.11 and 8.5.12 source releases, focusing on the request-memory and session-handling changes in Zend/zend_alloc.c and ext/session/session.c.
For CVE-2026-109618, 8.5.11 can enter fatal-error handling the moment an allocation exceeds the configured limit. That interruption can land while request data is only partly initialized, and ordinary cleanup then runs over inconsistent internal state. 8.5.12 defers out-of-memory handling, separates soft and hard memory limits, and terminates the worker without ordinary cleanup when safe recovery is not possible.
Figure 2: CVE-2026-109618. Immediate bailout in 8.5.11 against deferred out-of-memory handling in 8.5.12.
For CVE-2026-109619, 8.5.11 begins multipart upload-progress processing before normal request initialization and without first clearing session globals. 8.5.12 adds an early call to php_rinit_session_globals plus additional session-initialization checks, so a new request cannot consume session or decoder state left behind by a previous interrupted request.
Figure 3: CVE-2026-109619. Session globals are now cleared before upload processing begins.
The detection problem with PHP2Shell is silence. Worker processes remain stable, responses return HTTP 200 and application logs record nothing, because no application code ran. Often the only server-side trace is a single memory-limit fatal in the web server error log, which most teams treat as noise. Signatures catch the known payload shapes, and attackers are already varying payloads around them. The table below maps each break point in Figure 1 to what is actually observable.
|
Point |
Chain step |
Detection and break-point opportunity |
|
A |
1. Target identification |
Inventory every PHP runtime, including copies inside appliances, hosting panels and container images. Confirm which are internet-reachable and which run mod_php. Exposure data is the only control available before the request arrives. |
|
B |
2. Crafted request delivery |
Unusually large or complex multipart/form-data POSTs, especially to endpoints that do not accept uploads. Upload-progress fields (default PHP_SESSION_UPLOAD_PROGRESS) where no upload handler exists. Requests with no usable Content-Length or a value that does not match the body. |
|
C |
3. State corruption |
Clusters of "Allowed memory size of N bytes exhausted" errors in PHP logs. Unexplained worker crashes, restarts or segmentation faults in Apache or PHP-FPM logs. Bursts of HTTP 500 responses to one source followed by normal requests from the same source. |
|
D |
4. Outcome fork |
Unusually long or malformed PHPSESSID values in Set-Cookie response headers, which indicate the memory-disclosure primitive rather than code execution. Outbound response sizes that do not match the requested resource. |
|
E |
5. Post-exploitation |
PHP worker processes (php-fpm, php-cgi, httpd, apache2, lsphp, frankenphp) spawning shells, interpreters or network tools. Reverse shell patterns such as /dev/tcp/, mkfifo, fsockopen and nc -e. New PHP files in web roots. New cron entries or accounts created by the web worker account. |
|
F |
Containment |
Treat any host that was internet-reachable and unpatched at any point since October 17 as in scope for compromise assessment. Where point D indicators were observed, or where the disclosure path cannot be ruled out from available telemetry, rotate the credentials, tokens and API keys reachable by that worker. The disclosure path requires no code execution and leaves no host artifact. |
Point F is the step most organizations will skip. Memory disclosure produces no file, no process and no log entry, so absence of evidence is not evidence of absence. Where telemetry cannot rule the path out, treat the secrets that worker could reach as exposed. Scope the rotation to those hosts rather than the whole estate.
This is where hunting earns its place. Detection content built from the indicators above will catch the loud attempts. The quiet ones, and the ones that already succeeded before signatures existed, are found by hunting backward through process-ancestry, web-root file creation and error-log telemetry from October 17 onward. Security stacks have gaps by design. Hunting is how the gap between what a platform can alert on and what actually happened gets closed, and DFIR readiness is what turns a hunt finding into a scoped, contained incident rather than an open-ended investigation.
Updating PHP is the only complete fix. The settings below follow the interim guidance in the PHP advisory. They narrow specific attack paths, and PHP states plainly that they do not make an installation safe. Apply them in php.ini, the FPM pool or the web server configuration so they take effect before request parsing, then restart every PHP worker.
|
Setting |
Applies to |
Notes |
|
memory_limit = -1, enforced so applications cannot override it (for example php_admin_value) |
CVE-2026-109618 |
Removes the PHP memory cap. Use a container or cgroup memory limit to protect availability. Do not use RLIMIT_AS or RLIMIT_DATA. |
|
Low post_max_size (8M where uploads are not needed, 32M where they are) |
CVE-2026-109618 |
Keep upload_max_filesize below it. Also cap request size, field count and nesting at the web server or proxy, including requests without a usable Content-Length. |
|
session.upload_progress.enabled = 0 |
CVE-2026-109619 |
Blocks the confirmed session paths only. Do not rely on ini_set() or .user.ini. |
|
fatal_error_backtraces = 0 (PHP 8.5) |
CVE-2026-109619 |
Blocks the confirmed backtrace path only. |
|
WAF or CDN rules |
Known request patterns |
Short-term measure. Attackers are already adjusting payloads to get past new signatures. |
|
Network isolation |
End-of-life and unpatched hosts |
Remove direct internet exposure until patched. |
Do not run public proof-of-concept code outside an isolated lab. Roughly 100 repositories referencing PHP2Shell appeared within a day of disclosure. Quality varies, some only reproduce a crash, and JFrog has documented fake proof-of-concept code and prank malware published to GitHub under the PHP2Shell name. For exposure testing, Searchlight Cyber released php2shell-scanner as open-source tooling on October 22.
Source: Amazon Threat Intelligence MadPot telemetry. AWS warns that the identified addresses include shared anonymization infrastructure and are not exclusive to this activity. Investigate observations involving these addresses rather than blocking them.
|
IP address |
Observed date |
|
103[.]216[.]220[.]92 |
2026-10-17 |
|
31[.]223[.]184[.]166 |
2026-10-21 |
|
37[.]19[.]200[.]5 |
2026-10-21 |
|
134[.]209[.]159[.]64 |
2026-10-21 |
|
103[.]114[.]163[.]188 |
2026-10-21 |
|
95[.]217[.]98[.]37 |
2026-10-21 |
Howler Cell has identified no published file hashes for this activity as of this time. Payloads are request-borne, and the post-exploitation artifacts reported so far are commodity web shells and reverse shells rather than a distinct malware family.
|
Date (UTC) |
Change |
|
2026-10-22 14:00 |
Initial publication. Exploitation status reflects Amazon, watchTowr, Patchstack, Cloudflare, VulnCheck, Censys, JFrog and Huntress reporting as of this time, plus NCSC guidance. Amazon assesses broad in-the-wild exploitation. No confirmed compromise has been publicly named and neither CVE is in CISA KEV. |