Contact us

PHP2Shell: two critical PHP flaws, how to check and respond

PHP2Shell: confirm your PHP build is fixed

What happened

On 2026-10-21 the PHP project released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical memory-safety flaws, nicknamed PHP2Shell: CVE-2026-109618 and CVE-2026-109619. The project’s own advisories rate both 9.2 on the CVSS v4.0 scale (critical).

What happened

CVE-2026-109618 is memory corruption when PHP hits an out-of-memory condition mid-request. CVE-2026-109619 is a use-after-free caused by request state that survives into a later request on the same worker. The PHP advisory describes a demonstrated unauthenticated remote code execution, running as the web worker account, against Apache mod_php with default limits. For PHP-FPM the two advisories differ. One says the session upload-progress path was confirmed on FPM. The other says FPM is susceptible by source analysis only, and no complete FPM exploit has been demonstrated.

The exposed population is any server running an unpatched PHP that handles web requests: FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. That includes common CMS platforms and frameworks, plus appliances and containers that bundle PHP. PHP 8.1 and older receive no routine fixes, although source-only backports were published for 7.4, 8.0 and 8.1. Reported attack requests are multipart POSTs that can target an endpoint with no upload function, so “we have no upload form” is not a defense.

Exploitation status: exploitation attempts are widely reported; confirmed successful compromise is not publicly documented. A security vendor report, relayed by other vendors, described a honeypot attempt on 2026-10-17 and more on 2026-10-21. That original report was not reviewed for this brief. Other sources conflict. One vendor says it has not observed exploitation in the wild while noting multiple reports of attempts. A national cyber centre alert identified no active exploitation. A US government agency was reported to have seen none, and neither CVE was listed in its known-exploited catalog as of 2026-10-23 (relayed, so recheck). The PHP Foundation reportedly found no functional exploits in the public proof-of-concept code circulating at disclosure, and public proofs of concept reportedly crash workers rather than reliably give code execution. One vendor’s claim of multiple confirmed incidents has no published technical detail and is unconfirmed. Treat this as active scanning, not as a false alarm.

A third issue, CVE-2026-115560, concerns an unusual configuration where an application switches session.serialize_handler to php at runtime. It was not fixed by the 2026-10-21 releases as of 2026-10-23.

Are you exposed?

A version string alone is not enough, because distributions often backport fixes without changing it. Check the package changelog for the CVE ids:

apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

For upstream builds, php -v and php-fpm -v should show 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later. Then inventory the PHP you are actually running, including bundled copies:

ps -eo pid,user,lstart,cmd | grep -E 'php-fpm|php-cgi|lsphp|frankenphp|apache2|httpd'
find / -xdev -type f -name 'php-fpm*' -o -name 'php-cgi' -o -name 'libphp*.so' 2>/dev/null

Confirm the workers were restarted after patching: the process start time must be later than the package install time. For containers, pulling a patched tag is not enough until the containers are recreated.

Signs someone already used it

These are public indicators. Absence of a hit is not proof of safety, and the memory-disclosure path may leave no file, process or log entry. Start the hunt from before the 2026-10-21 disclosure. The commands use 2026-10-17, the first attempt date reported by that relayed vendor account, as a conservative start.

  • Request pattern: a multipart/form-data POST containing a PHP_SESSION_UPLOAD_PROGRESS field sent to a URL with no upload function, or a multipart POST with a missing or mismatched Content-Length.
  • Log signatures: clusters of “Allowed memory size of N bytes exhausted”, worker segfaults or restarts, bursts of HTTP 500 from one source followed by normal requests, and a long or malformed PHPSESSID in Set-Cookie.
  • Source addresses reported from a honeypot: 103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 and 95.217.98.37. Some sit on shared anonymization infrastructure, so investigate rather than block blindly.
awk '$9==500 {print $1}' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null | sort | uniq -c | sort -rn | head
grep -hE 'Allowed memory size of [0-9]+ bytes exhausted|SIGSEGV|exited on signal 11' /var/log/php*-fpm.log /var/log/syslog /var/log/messages 2>/dev/null
find /var/www -type f -name '*.php' -newermt '2026-10-17' -ls
find / -xdev -user www-data -newermt '2026-10-17' -type f 2>/dev/null | head -100

Also look for a PHP worker spawning sh, bash, python, perl, curl, wget or nc, which process-execution auditing can show. Check for new cron entries or accounts under the web worker account, and for unexpected outbound connections from the web server. To hunt for reverse-shell strings, limit the search to recently changed files, because legitimate plugins and libraries commonly contain fsockopen and every hit needs manual review:

find /var/www /tmp /dev/shm -type f -newermt '2026-10-17' -exec grep -lE '/dev/tcp/|mkfifo|nc -e' {} + 2>/dev/null

Contain it now

1. Patch or isolate internet-facing PHP hosts first. If you cannot patch immediately, take the host off public exposure. Use WAF or CDN rules as a stopgap only.

Contain it now

2. For a host with indicators, capture evidence in parallel with containment: snapshot the disk, copy web, PHP, auth and system logs, and save ps auxf and ss -tanp output.

3. Isolate the host at the network layer instead of powering it off, so memory and connections stay available to responders.

4. Rotate secrets the PHP process could read: database passwords, API keys, SMTP credentials, CMS salts, .env contents and cloud tokens.

5. Rebuild from a known-good image or backup taken before the exposure window, then redeploy with patched PHP, rather than cleaning in place.

6. Review systems the host could reach, such as databases, file shares and cloud roles, and its outbound connections.

Fix and harden

  • Primary fix: upgrade to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package that explicitly lists both CVE ids, then restart the PHP workers and the web server.
  • PHP 8.1 and older: migrate to a supported branch, or confirm a vendor backport exists.
  • Interim only: set session.upload_progress.enabled=0 in php.ini or the pool configuration, not through ini_set. Keep it until the next bugfix release because of CVE-2026-115560.
  • Interim only: enforce a non-overridable memory_limit of -1 in the FPM pool and use a container memory limit that kills only the affected worker. The advisories state these steps do not make an installation safe.
  • Tighten request limits (post size, input nesting, multipart parts) and block multipart requests to routes that never accept uploads.
  • Keep egress filtering on web servers and a current PHP inventory so the next advisory takes hours, not days.

Core-Infosec treats PHP-FPM exposure as a patch-and-hunt item: confirm the PHP version on each host, upgrade to a fixed release, then review web server and PHP logs for the published indicators.

When to call incident response

Call in responders if a PHP worker spawned a shell, interpreter or network tool; unexpected .php files appeared in a web root; memory-exhaustion errors, segfaults or 500 bursts from one source coincide with later normal-looking requests; the web server made unexplained outbound connections; new cron entries or accounts exist under the worker account; or an unpatched internet-facing host, especially mod_php, was exposed and logs alone cannot rule out exploitation.

Message us to talk through your PHP patching plan.

Sources

Discover more from Core-Infosec

Subscribe to get the latest posts sent to your email.

Picture of Core Watch

Core Watch

Practical security guidance from Core-Infosec.

Read More