[GrahamCampbell]

When PHP-FPM fails to start a request, for example because PHP runs out of memory while parsing the request body, the worker ends the FastCGI request without writing any output and exits with code 70 (see php_request_startup() in sapi/fpm/fpm/fpm_main.c). Bref turns that empty output into a 200 with an empty body, so the failure is invisible to clients and to the Lambda error metrics. PHP-FPM writes at least the blank line that ends the headers for any request it actually runs, so empty output can only mean the request never started, and this now throws FastCgiCommunicationFailed like the other PHP-FPM failures. The advisory for CVE-2026-109618 describes request bodies crafted to run PHP out of memory during request startup, which on PHP-FPM end up on exactly this path. The test runs PHP-FPM with a low memory limit and posts enough small form variables to exceed it while the body is parsed.