Apache is a common front for PHP and is not itself the CVE. The risk depends on which Apache module reaches PHP.
Run apachectl -M, or httpd -M on RHEL-family systems. You are looking for php_module or php7_module together with mpm_prefork_module, or for proxy_fcgi_module without an embedded PHP module.
mod_php is the combination PHP calls the highest risk, because request shutdown runs even when startup fails and the demonstrated exploit does not need application code. proxy_fcgi plus PHP-FPM is a different process. Restarting Apache recycles mod_php. It does not, by itself, recycle a separate FPM pool unless the pool is socket-activated in a way that dies with Apache, which you should not assume.
Also look for php_value and php_flag in the virtual host or in .htaccess. For CVE-2026-109619 those per-directory settings are applied before request startup on mod_php and can be the early consumer. On FPM, the analogous risk is PHP_VALUE passed by the proxy, not .user.ini.
Pick the guide that matches the module list: mod_php, PHP-FPM behind Apache, or CGI. Patch the PHP build that module actually loads, then restart that service and confirm the module or pool came back.