Exploited CVEs, and how to close them.

Indicators of attack (IOAs).

• Request shape: large multipart/form-data POSTs with an unusually high number of parts. In the observed attacks, bodies ranged from about 280 KB to 33 MB, with roughly 900 to 1,000 parts per request. Attackers can vary these numbers, so alert against your own upload baseline.
• Mixed framing: the same client sends both Transfer-Encoding: chunked and Content-Length multipart requests to the same endpoint.
• Memory exhaustion fatals: PHP Allowed memory size … exhausted errors on these requests, logged during request startup (Unknown on line 0), with no matching application log entry. The failure happens before your code runs.
• Memory disclosure: a response with an abnormally large PHPSESSID Set-Cookie, around 800 KB decoded. Normal session cookies are small.
• The observed sequence: four requests against one Apache worker, retried until it succeeds.
  1. A chunked request, followed by memory exhaustion.
  2. A chunked request whose response carries the oversized session cookie.
  3. A Content-Length request, followed by memory exhaustion.
  4. A Content-Length request, followed by a shell and a worker crash.
• Correlate by worker. Tie requests to the same worker process using PID plus process start time, since PIDs are reused. Timestamps alone aren’t reliable when requests overlap.

None of these alone proves an attack. That includes a 500, a timeout, a worker crash, a missing access log line, or a single large upload; each can be benign.

Indicators of compromise (IOCs).

The confirmed IOC is a web server worker starting a shell.

• Process lineage from httpd/apache2 (and, by extension, php-fpm) to sh/bash/dash.
• Unexpected file writes by the web user.
• Outbound connections from PHP workers.
• An Apache error log line like child pid … exit signal Segmentation fault (11) right after one of the requests above.

1. Isolate the host.
2. Preserve logs and process evidence.
3. Rotate any credentials the application could read.
4. Redeploy from a patched image rather than cleaning in place.

• PHPSet memory_limit=-1 in a way applications can’t override (for example php_admin_value in the FPM pool or Apache config), and check nothing puts a finite limit back.
• PHPSet a low post_max_size: 8M if you don’t need file uploads, 32M if you do. Keep upload_max_filesize below post_max_size.
• PHPEnforce limits at the web server or proxy for decoded request size, input field count, multipart part count, header count and nesting depth. These must also cover requests without a usable Content-Length (chunked). Run them in log only mode first so legitimate uploads don’t break.
• PHPUse a container or cgroup memory limit as an availability boundary. Don’t use RLIMIT_AS or RLIMIT_DATA instead; they can trigger the vulnerable path.
• If your applications don’t use multipart/form-data, block it at the frontend (from the CVE-2026-109618 advisory).

• PHPSet session.upload_progress.enabled=0 and restart every worker. Set it in php.ini, an FPM pool or server config that applies before request parsing; ini_set() and FPM .user.ini don’t work. This blocks the confirmed session paths, not every variant.
• PHPOn PHP 8.5, set fatal_error_backtraces=0 and restart every worker.
• PHPRemove invalid or deprecated per request settings that emit diagnostics before initialization. Hiding diagnostics doesn’t help.
• PHPFix attacker reachable fatal errors and execution timeouts, including in callbacks, upload or import processing, and cleanup.