A web server such as nginx or Apache sends each PHP request over a socket or a port to PHP-FPM. A worker handles one request at a time and is then reused for the next one, and a master process starts and replaces workers. Its settings live in php-fpm.conf and in pool files, usually in a pool.d directory.
Reuse is why state that survives a request matters, and a patched binary does not help until the old workers are gone. PHP-FPM has one protective habit: it stops the worker when request startup fails, which makes the startup path of CVE-2026-109618 harder, and PHP said that no complete FPM exploit was demonstrated for it. That does not close the path. For CVE-2026-109619 the confirmed FPM path starts with a fatal error in the application.
In October 2026, Abstract Security noted that Apache mod_php had the demonstrated exploit path, while PHP-FPM, php-cgi, FrankenPHP and LiteSpeed were all at risk. Interim measures for FPM were php_admin_flag in the pool and, at a high cost in speed, pm.max_requests = 1. Mattias Geniar's tests covered both.
After you install the fix, restart PHP-FPM and any queue or Octane workers so that every process runs the new code. Check each PHP version that a pool uses, and keep the interim pool settings until you have verified the patched build.