PHP2Shell: close two critical PHP flaws and check for abuse

On 21 October 2026 the PHP project fixed two flaws that let attackers run their own code on web servers without logging in. Both sit in PHP itself, not in the WordPress, Nextcloud or shop on top of it, and attacks are already under way. This article explains who is affected, which package versions are safe, what helps until you can patch and how to look for traces of a break-in with our free check script.

What happened?

The flaw has a long back story and a very short endgame. An audit organised by OSTIF found the first hints of the memory problem back in 2024, but no attack path was visible. In August 2026 the security firm Calif and shortly afterwards Wiz independently reported a way to execute code; in September OpenAI reported further attack paths. The release was planned for 22 October.

• 17 October: Amazon sees a first attack attempt in its honeypots, four days before disclosure.
• 20 October: the two CVE numbers circulate with a wrong CVSS score of 10.0. The PHP project brings the release forward to 21 October; that evening a video of the attack is published by mistake.
• 21 October: at around 13:30 UTC PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released with their advisories. Ubuntu, Debian and the official Docker images follow the same day. Germany's BSI issues a level 3 (orange) cyber security warning; CISA, the UK's NCSC and CERT-EU warn as well. Cloudflare, watchTowr and others see attack attempts at mass scale.
• 22 October: in version 1.2 of its warning the BSI states that reports of bypassable patches have been refuted; it knows of no confirmed compromises in the federal administration or regulated sectors yet. Sophos reports a first successful exploitation that probably dropped a Mirai variant.

The two flaws in plain words

A PHP worker handles requests in a fixed order: it accepts the request, reads the input (form fields, cookies, the progress of running uploads), runs the script, frees the request's memory and takes the next one. Both flaws live in this framework, not in the application code above it.

CVE-2026-109618: memory runs out while reading input

PHP caps the memory per request with memory_limit. When the cap is hit, PHP jumps abruptly out of the running code. If that happens while the request data is only half built, the later clean-up treats the half-built state as valid, and that can be turned into code execution. An attacker drives memory up deliberately without breaking the usual limits: multipart requests without a length slip past the post_max_size check, a multipart part may carry any number of headers, and nested field names multiply the work.

The PHP project has demonstrated full code execution with mod_php and default limits. In Datadog's lab a single field name of about 3.5 MB was enough, but with memory_limit deliberately lowered to 16 MB. The fix replaces the abrupt jump with an orderly abort at a safe point.

CVE-2026-109619: state outlives its memory

A PHP worker serves many requests in turn and keeps global state for that. If a fatal error, a timeout or a memory error interrupts the clean-up, part of that state keeps pointing at the old request's memory even though it has already been freed (use-after-free). The next request on the same worker can then use it. Three paths are confirmed:

• Upload progress: session.upload_progress.enabled is on by default and reachable even when the application never calls session_start().
• Per-request settings: INI values, for example from .htaccess or php_value, that raise warnings early. Hiding errors does not help.
• Fatal error backtraces: PHP 8.5 only, with fatal_error_backtraces.

Who is affected?

Every PHP runtime that serves HTTP requests is affected, according to the BSI and CERT-EU across all versions since PHP 5. The risk depends on how PHP runs:

Safe versions

The key fixed versions as of 22 October 2026. Compare them with the package version from your source:

1.Patch and restart

On Ubuntu and Debian the regular package sources are all you need. The second step matters: a running PHP-FPM or Apache process keeps the old code in memory until it restarts.

# install the fixed packages
sudo apt update
sudo apt install --only-upgrade 'php8.1*' libapache2-mod-php8.1

# restart whatever runs PHP for the web (only the services you have)
sudo systemctl restart php8.1-fpm
sudo systemctl restart apache2

# Debian 12 (php8.2) or Debian 13 (php8.4)
sudo apt update && sudo apt install --only-upgrade 'php8.2*'

# RHEL, AlmaLinux, Rocky: compare with the erratum, not with php -v
sudo dnf upgrade 'php*'
rpm -q php-common php-fpm

On Ubuntu 22.04 this one-liner shows whether the patch is in; it prints OK or VULNERABLE per package:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php8.1*' libapache2-mod-php8.1 2>/dev/null \
  | awk '$1=="ii"{r=system("dpkg --compare-versions "$3" ge 8.1.2-1ubuntu2.28"); print $2, $3, (r==0?"OK":"VULNERABLE")}'

And this one counts the processes still holding old PHP code in memory. 0 means everything has been reloaded:

sudo grep -ls 'php.*(deleted)' /proc/[0-9]*/maps 2>/dev/null | wc -l

2.Stopgap until you can patch

If you cannot patch right away, take the system off the internet; the BSI, CISA and CERT-EU all recommend this. Where that is impossible, the PHP project's official stopgaps reduce the risk but do not close the flaws. The PHP project is unambiguous: only the update gives complete protection.

; CVE-2026-109618: no memory limit inside PHP, use a cgroup/container limit instead
memory_limit = -1
post_max_size = 8M          ; 32M if uploads are needed
upload_max_filesize = 8M    ; always below post_max_size

; CVE-2026-109619: no upload progress tracking
session.upload_progress.enabled = 0

; PHP 8.5 only
fatal_error_backtraces = 0

• Set them so they cannot be overridden: in php.ini, in the FPM pool as php_admin_value[…] or in Apache with php_admin_value, not via ini_set() or .user.ini. Check that no pool, directory or application sets a limit again.
• Limit memory another way: without memory_limit the server needs a cap through cgroups or the container. Never use RLIMIT_AS or RLIMIT_DATA: they trigger exactly the vulnerable path.
• Limit at the web server or proxy: request size, field count, number of multipart parts, headers per part and nesting depth, including requests without a Content-Length. If you do not need multipart, block it altogether.
• Keep workers short-lived: pm.max_requests = 1 in the FPM pool if performance allows.
• Clean up: remove invalid or deprecated per-request INI settings that raise early warnings, and fix fatal errors and timeouts that can be reached from outside.
• WAF as an extra layer: Cloudflare has protected sites with managed rules since 21 October, on the free plan too; on paid zones check that they are set to "Block". The AWS rule covers CVE-2026-109619 only. Both vendors explicitly present their rules as a complement to the update.

3.How to spot attacks

An attack leaves different traces depending on how it ends. Failed attempts often show up in the error log; a successful attack usually does not. In Datadog's lab the exploit returned a normal HTTP 200 after 3.1 seconds and the worker kept running. That is why processes and files matter more than logs.

4.The check script php2shell-check.sh

We have turned the checks in this article into a script that we use on our own and managed servers. It runs as root, changes nothing on the system and writes nothing but a report. The terminal shows only fixed texts, counts and line numbers; paths, addresses and log lines go into the report, which only root can read. That way the output can be shared safely.

curl -fsSLO https://nokkela.blog/downloads/php2shell-check.sh
curl -fsSLO https://nokkela.blog/downloads/php2shell-check.sh.sha256
sha256sum -c php2shell-check.sh.sha256      # must print: php2shell-check.sh: OK

sudo bash php2shell-check.sh                   # lookback from 2026-10-17
sudo SINCE=2026-08-01 bash php2shell-check.sh  # longer lookback

Read the script before its first run: it is just over 500 lines of Bash with no dependencies beyond what Debian and Ubuntu ship. On a test system with deliberately planted traces the output looks like this:

### php2shell-check 1.0.0 (CVE-2026-109618, CVE-2026-109619), since 2026-10-17
[ INFO ] Platform Ubuntu 22.04.5 LTS
[ INFO ] Web users: 1, web roots: 2, error logs: 2, access logs: 1

### PHP packages
[  OK  ] 'All 5 PHP packages at a fixed version'
[  OK  ] 'Running processes use the current PHP code'

### Attack attempts in the logs
[FAILED] 'Errors while setting up requests (Unknown on line 0): 2 (report lines 17-18)'
[FAILED] 'Crashed Apache or PHP workers, core dumps: 3 (report lines 21-23)'
[FAILED] 'Session errors and upload-progress sessions: 2 (report lines 26-27)'
[FAILED] 'Published PHP2Shell indicators (scanners, source IPs, payload): 3 (report lines 30-32)'

### Traces of a compromise
[FAILED] 'Foreign processes under the web user: 2 (report lines 35-36)'
[FAILED] 'Programs running from /tmp, /dev/shm, memory or a web root: 1 (report line 39)'
[FAILED] 'Script files written by the web user: 1 (report line 42)'
[ INFO ] Other changed script files (deployment?): 1 (report line 45)
[FAILED] 'Files of the web user in /tmp, /var/tmp, /dev/shm: 1 (report line 48)'
[FAILED] 'Signs of persistence (cron, SSH, systemd, accounts): 2 (report lines 51-52)'
[FAILED] 'Package files differing from their package: 1 (report line 55)'
[ INFO ] No SSH logins in the journal

### Result
[FAILED] 'Yellow: 10, review and assess'
[ INFO ] Report: /opt/php2shell-check/reports/report-20261022-212135.txt
[ INFO ] View all findings: tail -n +16 /opt/php2shell-check/reports/report-20261022-212135.txt

Red lines mean a patch is missing or old code is still running. Yellow lines are findings to review and assess. The exit code is 2 for red, 1 for yellow and 0 when nothing was found, so the script also fits into Ansible or a monitoring system.

5.What to do if you find something

The order matters more than any single step: close first, then check, then clean up.

• Isolate: take the server off the network or restrict it to your management access with a firewall. Do not switch it off while you still want evidence: processes and memory would be lost.
• Preserve evidence: the check script's report, the error and access logs from 17 October, the list of running processes and, if possible, a disk image.
• Rotate secrets: treat everything PHP could read as known: database passwords, API keys in .env or configuration files, cloud credentials, SMTP credentials, the application's session keys. Do this as a precaution even without signs of code execution if the server sat unpatched on the internet: Wiz has shown that the flaw can leak memory contents.
• Rebuild rather than clean up: cleaning a compromised server reliably rarely works. Reinstall, deploy patched PHP, check a backup from before 17 October and restore it.
• Report: where personal data is involved, the GDPR's 72-hour deadline applies (Art. 33); organisations under NIS2 have their own reporting duties.

Frequently asked questions

Sources

External sources, as of 22 October 2026 (open in a new tab):

• PHP project, security release of 21 October 2026
• PHP project, GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP project, GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation, background to the security release
• BSI (Germany), cyber security warning on PHP (level 3)
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC (UK), Critical security issue affecting PHP
• CERT-EU, Security Advisory 2026-018
• NVD, CVE-2026-109618
• Ubuntu, USN-8948-1
• Ubuntu, USN-8948-2 (ESM)
• Debian, DSA-6574-1 (trixie)
• Debian LTS, DLA-4848-1 (bookworm)
• Red Hat, RHSB-2026-013
• AlmaLinux, PHP2Shell updates
• Ondřej Surý, PPA ondrej/php
• Amazon Threat Intelligence, exploitation before disclosure
• Cloudflare, WAF protection against PHP2Shell
• Calif, PHP2Shell
• Wiz, PHP2Shell
• Datadog Security Labs, detection and analysis
• Sophos, proof of concept and first exploitation
• ELLIO, observations from the sensor network
• Eye Security, risk assessment
• Bitdefender, technical advisory
• Elastic Security Labs, detection rules

This article is for general information and does not replace a case-by-case assessment. Versions and commands reflect the stated date and must be adapted to your environment. The check script is provided under the BSD-2-Clause licence without warranty. As of October 2026.