PHP2Shell: How the Two PHP RCE Flaws Work and How to Check If Your Server Is Exposed

Before you read: The ‘were we already inside?’ logic in Edge Appliance Zero-Days applies here too, aimed at PHP servers instead of VPNs and firewalls. Skim it if you have to explain an emergency patch to someone who doesn’t write code.

PHP2Shell is two remote code execution bugs in PHP, and the most uncomfortable part is the calendar, not the code. The PHP project had planned its fixes for 21 October at 14:00 UTC. The embargo broke on 20 October, and Amazon says one of its honeypots logged an exploitation attempt dated 17 October. If you run PHP, the first question isn’t when to patch. It’s whether something got in before you did.

This piece explains how the two bugs work, why a version number tells you less than it seems, what the early exploitation reports do and don’t establish, and how to check a server without trusting one tool’s verdict. One disclosure up front: I did not run the commands in this article on a live host. They are drafts. Each one says what it can prove, and the places that still need a lab run are marked.

Table of contents

• Two bugs, one bad habit
• CVE-2026-109618: the out-of-memory path
• CVE-2026-109619: upload progress and the session that outlives its request
• Why a version check misleads you
• Who is exposed, and how to tell
• The four-day puzzle
• Did the exploits actually work?
• Confirmed or single-source?
• Check a server, step by step
• Mitigations and their limits
• After the patch
• A checklist for the next request-lifecycle bug
• Did you know
• What this says about the bigger picture
• Sources

Two bugs, one bad habit

Both CVEs come from one habit in PHP’s request cleanup. The engine assumes that when a request ends, its state is consistent. If a request dies halfway through, say by running out of memory or hitting another fatal error, the cleanup can be skipped. The memory gets freed, but a global variable still points at it. The next request that lands on the same worker reads that stale pointer.

Picture a kitchen that only wipes the counter after a clean service. One fire during the rush, and the next customer gets seated beside a plate that was already thrown out. PHP rates both CVEs at CVSS v4.0 9.2 and says no complete configuration workaround exists. Its advice is to update.

CVE-2026-109618: the out-of-memory path

The attacker sends a multipart POST that stays under the default 8 MiB post_max_size but is built to exhaust the default 128 MiB memory_limit. Calif’s write-up, the most detailed public account I found, describes two routes. Chunked or lengthless requests can get around the declared-length check. Empty file fields, meaning form parts with an empty filename attribute, don’t count toward max_file_uploads but still create $_FILES entries, and deeply nested field names multiply the array work. Calif says a few hundred of those records can fill the default heap while the body stays well under the size limit.

The core fault is small. PHP increments a hash table’s element count before it allocates the key. If that allocation fails, teardown walks into a bucket that was never initialised and processes it anyway. A counter that is briefly wrong is enough.

Where PHP runs matters as much as the bug. Under mod_php, Apache calls request shutdown even when startup failed, so the malformed $_POST and $_FILES table is destroyed and the stale bucket gets consumed. PHP-FPM exits the child when startup fails, so the bad state dies with the process. That is why PHP ranks mod_php as the highest-risk configuration. Calif validated full RCE over HTTP against mod_php with default limits and prefork, and says extra workers add attempts without removing the condition.

CVE-2026-109619: upload progress and the session that outlives its request

Session upload progress is on by default. It starts a session while multipart parsing is still running, before PHP has activated its modules. If a fatal error hits in that window, multipart cleanup is skipped. Shutdown then skips the session module’s shutdown hook, because the module never activated. The heap gets freed, but the session globals still point into it.

The second request turns a crash into a primitive. A multipart request that carries a session ID and the upload-progress field, but no file part, skips the early reset. Its cleanup then reads the dangling session ID and frees a dangling value. The cleanup code is now acting on memory it no longer owns.

Calif also describes an FPM route. A decoder left at a non-zero nesting level after a fatal error can produce a negative slot count, which lets an attacker write a controlled pointer. That path depends on the application. Calif separately says frameworks that call maybe_unserialize() and session_start() open an unserialize route. Your framework matters about as much as your PHP build.

Why a version check misleads you

The obvious first step is running php -v and looking for 8.5.12, 8.4.27, 8.3.36 or 8.2.35. That’s necessary, but it isn’t sufficient, for three reasons.

The binary in your shell is not guaranteed to be the one answering web requests. Apache, PHP-FPM and container images can each carry their own runtime, so check php-fpm -v and the loaded Apache module as well.

Distribution backports break the test in both directions. PHP says the 7.4, 8.0 and 8.1 branches get no official release, only minimal source backports, and that distributions may ship their own fixes. PHP also says vendors received patches early. A package reporting 8.2.34 may already contain the fix, and a package reporting a fixed-looking number may not. PHP 8.1 and older no longer receive project updates, and PHP 8.2 reaches end of life on 31 December 2026.

The lower bound is fuzzy. The advisories don’t state one. Calif gives PHP 5.4.0 as the earliest affected path, and Krebs and Sansec both say ‘5.4 or later’. Anyone on an old branch is running a runtime that nobody will fix upstream.

A version string is the model number on a lock. It tells you the product line. It doesn’t tell you whether anyone hung the door properly.

Who is exposed, and how to tell

Setup	Why it matters	What to check
Apache with mod_php	PHP’s highest-risk configuration for CVE-2026-109618	Whether the php module is loaded (apachectl -M)
PHP-FPM	The child exits on startup failure, but the FPM route depends on the application	Pool files and php-fpm -v
Upload progress enabled	The default setting and the precondition for CVE-2026-109619	session.upload_progress.enabled in php.ini or the pool
session.serialize_handler changed at runtime	The edge case in PHP’s 23 October advisory	ini_set() calls placed before session_start()

The exposure counts are big and they don’t agree. Krebs says nearly 70 percent of websites need to update core software, and Censys and VirusTotal publish host counts with different denominators. Use those totals to gauge scale. They can’t tell you whether your fleet is in trouble.

The four-day puzzle

Amazon Threat Intelligence says it found one exploitation attempt dated 17 October in its MadPot honeypot telemetry. The source was an address on a commercial anonymization network. That date is three days before the 20 October leak and four before the 21 October release. Amazon says it is unclear how the actor got exploit information before disclosure, and that it cannot tell whether any of those attempts would have succeeded.

The later activity is busier. Amazon reports proof-of-concept code around 02:00 UTC on 21 October, and more attempts between 02:00 and 08:00 UTC from other anonymized infrastructure, with varied payloads that suggest more than one actor. Sansec reports early attacks at 07:43 UTC, and Krebs says Cloudflare deployed WAF rules at 03:02 UTC.

One honeypot hit proves neither a campaign nor a leak. What it shows is that an embargo protects you only until someone else reaches the same bug. Amazon says defenders should measure patch timelines in hours, not 7 or 30 days. I think that’s the right yardstick, and most change processes are still built around days.

Did the exploits actually work?

The reports disagree, and the disagreement is the useful part. Calif validated RCE. watchTowr’s honeypot network observed exploitation of both CVEs, though it reproduced only one bug. Sansec’s 22 October update says mass exploitation is ‘less likely than we expected’ and that the public exploits don’t work against a default installation. Dataminr’s TRACE team, quoted by BleepingComputer, describes scanning, fingerprinting and non-working exploits, with no known compromises. PHP’s team says none of the early proofs of concept were functional.

Both sides can be right at once. A working exploit against a known target under specific conditions is a different thing from a spray that works against everyone. Sansec says exploitation needs specific knowledge of the target and its settings, and Calif says knowing the target mattered more than its AI tooling. ‘No confirmed compromises’ describes what has been reported. It is not a clean bill of health, and it shouldn’t be read as one.

Confirmed or single-source?

Claim	Status	Basis
CVE IDs, CVSS v4.0 9.2, fixed versions	Confirmed, PHP primary	PHP archive and GHSA advisories
Mechanisms: longjmp, upload progress, stale globals	Confirmed by PHP, with detail from Calif	GHSA advisories, Calif
Working RCE against mod_php with default limits	Single source (Calif); PHP’s advisory calls the mod_php exploit demonstrated	Calif, PHP archive
Early public proofs of concept were non-functional	Single source: PHP’s team, via BleepingComputer	BleepingComputer
Attempt dated 17 October	Single vendor (Amazon)	Amazon
Mass exploitation	Disputed	Sansec, BleepingComputer
Nearly 70 percent of websites need core updates	Third party (Krebs)	Krebs

Check a server, step by step

Run these on each host. The first two steps find out what is actually serving requests. The third is the only one that reads live web settings. Each step says what it can prove, and none of them proves exploitability on its own.

1. Find the runtime. Run ps -eo pid,user,args | grep -E ‘php-fpm|httpd|apache2’ to see whether FPM, Apache or both are running, then grep -R ’^[’ /etc/php/*/fpm/pool.d/ to list the pools. This tells you which runtime serves the site. A php -v from your shell doesn’t.
2. Look for overrides. Run grep -R -E ‘php_(admin_)?value|php_flag’ /etc/php/*/fpm/pool.d/ and check the vhost configs too. You are looking for pool or site lines that override upload progress, post_max_size or memory_limit.
3. Read the live settings. Put a temporary phpinfo() page behind an allowlist (an Apache Require ip rule, or nginx allow and deny), load it from an allowed address, and read the Local value rather than the Master value for PHP Version, session.upload_progress.enabled, session.serialize_handler, memory_limit, post_max_size and max_file_uploads. Then delete the file. Phpinfo is a great tool, right up until someone forgets it’s on a public server.
4. Check containers. Run docker inspect —format ’{{.Config.Image}} {{.Image}}’ , then docker exec php -v, then docker run —rm php -i | grep upload_progress. The image can ship a different PHP than the host does.
5. Check distro backports. Run dpkg -l ‘php*’ or rpm -q php, then apt changelog or rpm -q —changelog php | grep 109618. Treat the changelog as the evidence, not the version string.
6. Clean up. Confirm the phpinfo file and the allowlist entry are gone before you close the ticket.

The commands above are not yet verified on a live host, so run them on a lab box first and check the output against your PHP manual. Settings read through phpinfo show configuration. They do not show whether a request would succeed.

Mitigations and their limits

This is where I’d slow down, because each option closes one path or trades one failure for another. The snippets below are drafts. The directive placement is taken from PHP’s advisory wording, and the items marked unverified need checking against the manual before you ship them.

; php.ini: read before request parsing, so per-app ini_set() and .user.ini do not apply here
session.upload_progress.enabled = 0
post_max_size = 8M    ; apps without uploads (PHP suggests 8M); use 32M if the app takes uploads
; memory_limit = -1   ; Calif's temporary option; it does not stop allocation failure

; pool.d/<site>.conf (unverified: confirm php_admin_value accepts this key)
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M

# nginx: the 1 MB default comes from third-party docs (Rackspace, O'Reilly); core docs not checked
client_max_body_size 8m;

# Apache LimitRequestBody: default and scope not checked against httpd docs
LimitRequestBody 8388608

What each option does and doesn’t do:

• Updating is the only option PHP says closes both bugs.
• Setting session.upload_progress.enabled to 0 in php.ini, or in a pool or server config that applies before request parsing, blocks the confirmed session paths of CVE-2026-109619 and nothing else. PHP warns that ini_set() and FPM .user.ini files don’t take effect for this setting.
• On PHP 8.5, fatal_error_backtraces=0 blocks the confirmed fatal-backtrace path.
• Setting memory_limit=-1 removes the limit the attack exhausts, but it doesn’t stop allocation failures. PHP says a failed mmap() can still reach the vulnerable path. It removes a guardrail to fix a bug that lives right at the edge of that guardrail, which is why I wouldn’t leave it on.
• Don’t use RLIMIT_AS or RLIMIT_DATA. PHP says they make mmap() fail, which triggers the vulnerable path.
• Trim post_max_size and enforce decoded-size, part-count and nesting limits at the proxy, as PHP recommends. Amazon suggests blocking multipart uploads at the edge, but warns that this may break the application.

Calif calls the upload-progress and memory-limit changes temporary partial mitigations that don’t replace patching. I agree. Use them to buy hours, not to close the ticket.

One new item from today. On 23 October PHP published an informational advisory about session upload progress. It recommends session.upload_progress.enabled=0 until the next bugfix release, and it describes a rare case in which session.serialize_handler is set to php_binary or php_serialize in configuration and then switched to php at runtime with ini_set() before session_start(). A new advisory, CVE-2026-115560, will follow in the next release. It is a lower-severity edge case, not a new RCE. If you already applied the upload-progress setting, keep it.

After the patch

1. Upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a distribution package whose changelog names both CVEs. For 7.4, 8.0 and 8.1, check distro backports, because PHP ships only source patches for those branches.
2. Restart PHP-FPM or Apache so the running workers load the new code. Verify with the runtime steps above, not with php -v alone.
3. Re-check the mitigations on the live runtime. Upload progress and post_max_size should still be at the values you intended, and upload progress should stay off until the next bugfix release.
4. Search logs for POST bodies that contain PHP_SESSION_UPLOAD_PROGRESS, which Amazon names as an indicator, and for worker crashes or memory-limit hits, which watchTowr describes. As far as I can tell from the sources, that string lives in the request body, so a plain access log won’t show it. You need body logging or a WAF for that search. If you have neither, write it in the ticket as a blind spot.
5. Remove any temporary phpinfo file and any temporary allowlist.

A checklist for the next request-lifecycle bug

This list is my synthesis from the PHP advisories and Calif’s write-up. It is not a published PHP checklist, but I’d run it on the next bug of this shape.

1. Does the bug need a fatal error or an out-of-memory event first? If so, list every cleanup step that event can skip.
2. Does any state survive into the next request on the same worker? Look for globals that still point at memory the request freed.
3. Which SAPI runs the code? mod_php, FPM and the CLI can differ in both exposure and cleanup behaviour.
4. Which settings take effect before request parsing? Per-app ini and ini_set() may not, according to PHP’s advisory on CVE-2026-109619.
5. Did a vendor backport change the code without changing the version string? Read the changelog, not the number.
6. Can each mitigation be read from the running process? A file that says a setting is off proves less than a live reading.

For the embargo side, the lesson is shorter. Assume the release date can move. Treat early hits as possible, not impossible. Measure your patch clock in hours.

Did you know

• By Calif’s timeline, the first bug was reported to PHP on 11 August 2026 and the patches shipped on 21 October, about 71 days later.
• The default post_max_size is 8 MiB and the default memory_limit is 128 MiB. Calif says a few hundred empty file records can fill the heap, so the request stays small while its memory cost stays large.
• Krebs, citing Reuters, reports that government websites in Europe went offline after the disclosure. Rushed patch cycles break things too.

What this says about the bigger picture

PHP resets request state by hand, one subsystem at a time, and every reset that gets skipped on a fatal error becomes its own bug. Both CVEs follow that pattern. I’m not claiming PHP is uniquely bad. The failure mode is structural, and fixing one instance doesn’t remove the structure.

AI shortens the distance. Wiz, quoted by Krebs, says frontier AI models ‘substantially reduced’ the barrier to turning these flaws into exploits. Calif says it used AI-assisted audits, and it is blunt that knowing the target mattered more than the model. That is the most useful sentence in the disclosure, because it means the scarce skill is still context, not the bug.

Read the vendor warnings with their interests in mind. Sansec sells a Magento shield and says patching can cause downtime. That doesn’t make its warnings wrong. It means its 22 October revision, which walked back the mass-exploitation alarm, deserves the same scrutiny as its first report.

What changes next? Embargoes shorten but they don’t disappear. PHP’s release was pulled forward once details leaked. The window between a patch and a working exploit is now measured in hours. The teams that keep up are the ones with a current inventory, a fast deploy path and a habit of checking what is actually running, not what they believe is running.

Sources

• PHP news archive, advisories from 20 to 23 October 2026: https://www.php.net/archive/2026.php
• PHP security advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618): https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• PHP security advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619): https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• Calif, PHP2Shell technical write-up: https://calif.io/php2shell/
• watchTowr, PHP2Shell rapid response: https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/
• Amazon Threat Intelligence, MadPot findings: https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
• BleepingComputer, on Amazon’s finding, the PHP embargo, and the Dataminr and VirusTotal quotes: https://www.bleepingcomputer.com/news/security/amazon-says-php2shell-exploitation-began-4-days-before-patches/
• Krebs on Security, outages, exposure figures, Cloudflare timing and Wiz commentary: https://krebsonsecurity.com/2026/10/widespread-php-flaw-may-cause-many-site-outages-today/
• Sansec, PHP2Shell research and 22 October update: https://sansec.io/research/php2shell
• Rackspace, limit file upload size in nginx (third-party, used for the 1 MB default): https://docs.rackspace.com/docs/limit-file-upload-size-in-nginx
• O’Reilly, nginx HTTP Server (third-party, used for the 1 MB default): https://www.oreilly.com/library/view/nginx-http-server/9781788623551/c78b840f-e73f-4a7a-8645-8916a82491eb.xhtml
• Internal: Edge Appliance Zero-Days: An Emergency Response Runbook