EXECUTIVE SUMMARY
Critical Security Threat: PHP Vulnerabilities “php2shell”
(CVE-2026-109618 & CVE-2026-109619)
Two critical remote code execution (RCE) vulnerabilities in PHP, collectively referred to as “php2shell,” have been disclosed with confirmed proof-of-concept (POC) exploitation in the wild. A working exploit demonstrates that an unauthenticated attacker can execute arbitrary code prior to any web application execution.
Threat Overview
The advisory highlights two severe internal state handling flaws:
- CVE-2026-109618 (RCE via OOM Corruption): Out-of-memory handling can interrupt PHP while internal request data is only partially initialized, causing subsequent request cleanup to treat invalid data as valid.
- CVE-2026-109619 (RCE via Stale Global State): Request-owned internal state can survive after its backing memory has been freed, allowing a subsequent request handled by the same worker process to access stale state before normal initialization resets it.
Every PHP system processing web traffic is vulnerable, regardless of handler (including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed), with Apache environments running mod_php facing the highest threat level. Over 5 million internet-facing IP addresses worldwide are estimated to be running exposed PHP instances. Affected web infrastructure and application profiles include:
- Web Servers: Apache (2.9M hosts), Nginx (1.48M hosts), and LiteSpeed (90K hosts).
- Applications: WordPress (538K hosts), Laravel (141K hosts), Nextcloud (107K hosts), alongside Roundcube Webmail and phpMyAdmin (25K combined hosts).
1. Apply Software Updates:
Upgrade immediately to PHP versions 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Source downloads and Windows binaries are available on the official PHP downloads page.
2. Check Linux Vendor Packages:
Most Linux distributions and LTS vendors received patches in advance; check your package manager for updated releases.
3. Address EOL Versions:
PHP 8.1 and older are end-of-life and no longer receive standard security updates. Minimal source-backports have been provided for PHP 7.4, 8.0, and 8.1 for those building from source, or organizations should consult their LTS provider or upgrade to a supported release.
4. Remi Repository Notice:
Users relying on rpms.remirepo.net should switch to distribution packages or build from source, as updates will not be available on that repository immediately.
5. Process Spawning Detection:
Environments seeking standalone process monitoring on Linux servers can utilise tools like process-watcher to directly monitor process spawns (e.g., shells, Python/Perl interpreters, or download utilities like curl/wget)
If an internet-facing PHP server was unpatched at any point after 15:20 UTC on 20th October 2026, treat it as potentially exposed until you have looked. A patch removes the vulnerability; it does nothing about a webshell, a cron job or stolen database credentials planted beforehand.
Three things make this harder than a typical web CVE:
01
No reliable exploit signature in logs
Because these are memory corruption bugs triggered by malformed requests, PHP’s own advisory notes that a clean error log is not proof of safety, as worker failures can occur before PHP writes log entries.
02
Your application controls do not see it
Application-level security mechanisms (e.g., login checks, CSRF tokens, maintenance mode, and WordPress security plugins) run after PHP parses the request body, leaving them blind to exploitation. (Note: Upstream network security controls, such as Web Application Firewalls (WAFs) and reverse proxies, inspect raw HTTP traffic prior to PHP execution and can block anomalous payload structures like malicious PHP_SESSION_UPLOAD_PROGRESS strings or malformed multipart POST requests.)
03
Consider credentials, not just the server
Exploited code runs under the web server user context, which can read .env, wp-config.php, and database configurations. Exposed credentials, including database, SMTP, cloud, and API keys, allow attackers to pivot beyond the compromised web server.
So the detection effort shifts from “did someone send the exploit?” to “did anything happen afterwards?” Post-exploitation behaviour is far easier to spot than the exploit itself.
05
What to hunt for
Focus your hunt on what an attacker does after getting code execution, scoped from 20th October 2026 onwards. The first three rows are the highest-signal; the last two are leads that need corroboration.
| Area | What to look for | Signal |
|---|---|---|
| Process lineage | Web processes (apache2, httpd, php-fpm, frankenphp) spawning shells (sh, bash), utilities (curl, wget, nc, base64), interpreters (python, perl), or reconnaissance commands (id, whoami). | High |
| Web root and config | New or modified .php files (especially in upload, cache, and temp directories); unauthorised modifications to .htaccess, .user.ini, auto_prepend_file, or FPM pools. Verify against Git, package, or CMS checksums rather than file timestamps. | High |
| Persistence and egress | Cron entries or authorized_keys for the web user, rogue binaries in /tmp or /dev/shm, new systemd units, and outbound network connections originating from web servers. | High |
| Crash and memory noise | Bursts of “Allowed memory size exhausted”, Apache segfault messages (SIGSEGV), or FPM child worker crashes tied to anonymous POST requests. Cross-reference crash timestamps directly with unexpected incoming POST traffic. | Lead only |
| Request patterns | Multipart POST requests to non-upload routes, repeated multipart submissions from single sources, anomalous Content-Length headers, or unauthorised PHP_SESSION_UPLOAD_PROGRESS values in HTTP request bodies. | Lead only |
If high-signal activity is identified, immediately audit database logs for new administrative users or bulk data reads, and review cloud, SMTP, and API logs for unauthorised use of server-stored keys.
06
If you have been impacted
Assume the attacker had everything the web user could read, rebuild rather than clean, and rotate every secret on the box.
1. Contain without destroying evidence.
Isolate the host at the network layer (security group, VLAN, firewall) rather than powering it off. Note that restarting PHP to patch also wipes in-memory evidence, so on high-value systems capture volatile data first if you can do it quickly. Never let forensics delay containment of a box that is still being used.
2. Preserve.
Take a disk image or snapshot, and collect web server, PHP-FPM, WAF, load balancer and EDR logs before rotation overwrites them. Record your timeline in UTC from the start.
3. Scope.
Establish first access, what ran, and where it went next. Check for lateral movement from the web tier into databases, internal services and cloud control planes. Shared credentials and flat networks are what turn one compromised site into a wider incident.
4. Rotate credentials.
Every secret the web user could read is burned: database passwords, .env and config file keys, SMTP, payment, cloud and third-party API tokens. Invalidate application sessions and reset admin accounts.
5. Eradicate by rebuilding.
Redeploy from a known-good image and source control onto patched PHP. Cleaning a webshell out of a live web root leaves you guessing about what you missed.
6. Recover and watch.
Bring services back with the interim settings still applied and heightened monitoring on process creation, file integrity and egress for at least several weeks.
7. Learn.
The questions worth asking afterwards: did we know where all our PHP lived, how long did patching take, could the origin be reached around the WAF, and could the web server talk to the internet at all?
If you suspect a breach, require assistance with threat hunting, or need emergency Incident Response, contact our Security Operations Centre immediately.