PHP2Shell (CVE-2026-109618, CVE-2026-109619): what to patch, what to check and how a WAF helps

What PHP2Shell is

PHP2Shell is a family of memory-safety bugs in how PHP sets up and tears down each web request. It was found by researchers from Wiz, Calif and OpenAI’s Codex Security, who report that affected code goes back to PHP 5.4. The PHP project published two advisories on 21 October 2026 and new releases for every supported branch at the same time.

Both advisories carry the same CVSS 4.0 vector, AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H: network reachable, no login, no user interaction, full impact on the server. The attack complexity is rated high, but the researchers demonstrated working exploits, so treat that rating with caution.

How an attacker reaches the bugs

For CVE-2026-109618, the attacker pushes PHP into an out-of-memory error at the wrong moment. The advisory describes several ways to do it through the multipart parser:

• a body without a usable Content-Length skips the post_max_size check;
• each multipart part can carry any number of headers;
• empty file fields do not count towards max_file_uploads, but they still create metadata, and nested field names multiply the work.

For CVE-2026-109619, one request leaves stale state behind and a later request on the same worker consumes it. The confirmed paths are:

• session upload progress, which is enabled by default and works without the application ever calling session_start();
• diagnostics raised by per-request INI settings (php_value in .htaccess, or PHP_VALUE in FPM);
• the PHP 8.5 fatal_error_backtraces setting.

Who is affected

According to the PHP project, every PHP installation that serves web requests is at risk. The server API (SAPI) that runs PHP changes how easy the attack is:

WordPress, Drupal and Joomla sites run on these same SAPIs. The researchers report pre-authentication RCE against all three, and the memory disclosure of CVE-2026-109619 works whatever the application.

Fixed versions

The PHP 8.6.0 release candidate published the same day (RC4) also contains the fixes.

Distribution packages. Linux distributions and LTS vendors received the patches in advance. A distribution package can carry the fix under an old-looking version number, so check the package changelog for the CVE IDs instead of comparing versions. For example:

apt changelog php8.2-fpm | grep -E 'CVE-2026-10961[89]'   # Debian, Ubuntu
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'  # RHEL, Alma, Rocky
php -v                                                     # upstream builds only

After updating, restart every PHP process: Apache for mod_php, each FPM pool, FrankenPHP and LiteSpeed workers. A worker that is still running keeps the vulnerable code in memory.

Exploitation status

The disclosure was rushed. A proof-of-concept video was posted by mistake the evening before the planned release, and The Hacker News reported early attacks and “active exploitation attempts” on 21 October, the day of the patches. Later reporting mentions honeypot hits as early as 17 October and Mirai-variant botnets trying the flaws. No source has publicly confirmed a successful compromise so far. With this much scanning, assume every unpatched PHP server will be probed.

Partial mitigations and their limits

The PHP project is explicit: only updating is a complete solution. The measures below reduce exposure to specific attack paths while you schedule the update. They do not make an installation safe.

For CVE-2026-109618 (out-of-memory corruption)

• memory_limit=-1, set where applications cannot override it (php_admin_value in the FPM pool or Apache configuration). This removes the PHP memory limit failure an attacker can control. An allocation failure in the operating system can still reach the vulnerable code.
• A low post_max_size: 8M for sites without uploads, 32M if you need them, with upload_max_filesize below it.
• Request limits at the web server or proxy for decoded body size, number of fields, multipart parts, headers and nesting depth. They must also cover requests without a usable Content-Length.
• A container or cgroup memory limit as an availability boundary, ideally one that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA: they can cause the very allocation failure the attack needs.

For CVE-2026-109619 (stale global state)

• session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, then restart every worker. ini_set() and FPM’s .user.ini apply too late and do not help. This closes the confirmed session paths, not every variant.
• On PHP 8.5, fatal_error_backtraces=0, which closes the confirmed backtrace path only.
• Remove invalid or deprecated per-request settings that emit diagnostics before the request starts. Hiding them with error_reporting, display_errors or @ does not help.
• Fix fatal errors and execution timeouts that an attacker can trigger, including in callbacks, uploads, imports and cleanup code.

; php.ini or FPM pool (php_admin_value[...] = ...), then restart every worker
session.upload_progress.enabled = 0
post_max_size = 8M          ; 32M if the site accepts uploads
upload_max_filesize = 4M    ; always below post_max_size
fatal_error_backtraces = 0  ; PHP 8.5 only

Note a behaviour change after the update. Running out of memory no longer stops PHP on the spot: the error is raised at the next safe point, and a second, hard limit above memory_limit ends the process outright. Shutdown functions do not run in that case, so review code that relies on register_shutdown_function() to log or clean up after a memory error.

Signs of an attack

The researchers quoted by The Hacker News point to these signs. Look for them in web server, PHP and FPM logs from 17 October onwards:

• unusual multipart/form-data requests, often to URLs that never accept uploads, followed by “Allowed memory size exhausted” errors or repeated HTTP 500 responses;
• oddly large PHPSESSID cookies in responses;
• PHP workers restarting or crashing for no clear reason (child exited on signal in FPM, segmentation faults in the Apache error log);
• bursts of warnings before any script runs, cleanup diagnostics, or “Maximum execution time exceeded” on odd URLs, which the GHSA advisories list as signs worth reviewing.

Turn on log_errors with error_reporting=E_ALL while you investigate. Clean logs are not proof of safety: a successful exploit can leave no PHP error at all. If you find these signs on an unpatched server, treat it as possibly compromised. Look for new files in writable directories, new cron jobs and unexpected outbound connections from the PHP user, and rotate the secrets the application can read.

The follow-up: CVE-2026-115560

On 23 October 2026, two days after the patches, the PHP project published an informational advisory about a separate, “unlikely” RCE vector in session upload progress, CVE-2026-115560. The 21 October releases do not fix it.

It needs an unusual combination of configuration and code:

• the configuration sets session.serialize_handler to php_binary or php_serialize;
• the application switches it to php at runtime with ini_set() before calling session_start();
• session upload progress is still enabled.

Applications that never change the serialize handler at runtime are not exposed. The PHP project will ship the fix and a full advisory with the next regular bugfix release; no date or version has been announced. Its advice is to set session.upload_progress.enabled=0 until then. If you already did that for CVE-2026-109619, keep it.

To check whether your code switches the handler:

grep -rnE "ini_set\(\s*['\"]session\.serialize_handler" --include='*.php' .

How OpenWAF protects your sites

Rule 10075 is enabled on the OpenWAF edge. It blocks every request in which a request argument is named PHP_SESSION_UPLOAD_PROGRESS (case-insensitive), whether it sits in a multipart body, a URL-encoded body or the query string. This is the field PHP reads to start session upload progress. Dropping it at the edge keeps those requests away from the PHP worker, which covers the confirmed session paths of CVE-2026-109619 and the CVE-2026-115560 vector.

A WAF rule is a stopgap, and this one has clear limits:

• It does not cover CVE-2026-109618 in general. The out-of-memory paths go through the multipart parser itself, and a request built for them does not need that field. Per-site request size and time-out limits make memory exhaustion harder, but they are not a fix.
• It does not cover the paths of CVE-2026-109619 that depend on server configuration, such as per-request INI diagnostics or fatal_error_backtraces.
• It only matches the default field name. If an application changed session.upload_progress.name, requests with the new name are not blocked by this rule.
• It only protects hostnames proxied through OpenWAF. Traffic that reaches your origin directly bypasses it, so restrict the origin to OpenWAF where you can.

Legitimate upload progress bars use the same field, so they stop working behind the rule. If you need one, add a per-site exception for rule 10075 on that path, and only after the server runs a fixed PHP release. Sites that run the WAF in log-only mode record matching requests instead of blocking them.

The fix is still to update PHP. The rule buys time while you do.

Checklist

1. List every server, container image and hosting account that runs PHP, and note the SAPI (mod_php, FPM, CGI, FrankenPHP, LiteSpeed).
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install your distribution’s package whose changelog lists CVE-2026-109618 and CVE-2026-109619.
3. On 7.4, 8.0 or 8.1, apply the source backport or your LTS vendor’s package, and plan the move to a supported branch.
4. Restart Apache, every FPM pool and every long-running PHP worker. Rebuild and redeploy container images.
5. Set session.upload_progress.enabled=0 in php.ini or the pool configuration until the CVE-2026-115560 fix ships, or permanently if you do not use upload progress.
6. Until every host is patched, lower post_max_size, enforce request limits at the proxy and set fatal_error_backtraces=0 on PHP 8.5.
7. Search logs from 17 October for the signs above, and treat unpatched servers that show them as possibly compromised.
8. Put public PHP sites behind a WAF that blocks PHP_SESSION_UPLOAD_PROGRESS while you patch, and restrict origins to the WAF.

Frequently asked questions

Sources

• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618) PHP, Oct 21, 2026
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619) PHP, Oct 21, 2026
• Security advisory: Critical remote code execution vulnerabilities, update now php.net, Oct 21, 2026
• Informational advisory: Session upload progress (CVE-2026-115560) php.net, Oct 23, 2026
• PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws as Exploit Attempts Emerge The Hacker News, Oct 21, 2026
• PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches The Hacker News
• CVE-2026-109618 record CVE Program, Oct 21, 2026
• PHP2Shell (researchers’ site: Wiz, Calif, OpenAI Codex Security) PHP2Shell researchers