Vulnerability
OOM strategies
Several multipart parsing problems can let a request reach OOM while remaining within its apparent PHP limits:
A multipart request without a usable declared content length may pass the initial post_max_size check and continue supplying decoded body data.
A multipart part can contain an unrestricted number of headers. Representing these headers inside PHP can use substantially more memory than their wire representation, allowing a request within post_max_size to exhaust the normal memory_limit.
Empty file controls do not count towards max_file_uploads but still create the normal file metadata arrays. Nested field names multiply the generated array work.
OOM can also be reached in application-specific ways when attacker-controlled input causes a sufficiently large allocation or repeated memory use.
Susceptibility
Apache mod_php unconditionally invokes the request shutdown procedure, even when request startup has failed. During request startup, automatic body parsing can exhaust the configured memory limit and exit the request in a context where state is temporarily invalid. Shutdown then processes this invalid state. This happens entirely before any application-specific code begins execution.
FPM exits the child when request startup fails. This prevents consumption of the invalid state and removes the child from the pool. After normal startup, OOM may still be reached in a context failing to account for an early exit, with the invalid state being processed during request shutdown. Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI.
Source analysis indicates that FrankenPHP, analogous to Apache mod_php, calls the request shutdown procedure unconditionally, making it likely susceptible to application-independent attacks. LSAPI models FPM, with application-specific exploits being likely but unvalidated.