Exposure assessment ≠ compromise detection. This guide cannot determine whether a particular system was compromised. Verify the current advisory and your exact runtime.

Determine how PHP is loaded

Some distributions use apache2ctl or httpd instead of apachectl. Run the command appropriate to the installation. Module inventory is a starting point: inspect the virtual-host handler and proxy mapping to determine which integration actually serves the domain.

A php module indicates mod_php may be in use; proxy_fcgi can forward to a separate FPM service. Inventory both if they coexist. Do not assume every virtual host uses the same runtime.

Apache module inventory and configuration test; binary names vary
apachectl -M
apachectl -t

Before you change the runtime

Record the current package revision, runtime handler, configuration and deployment topology. Confirm a current fix for both CVEs from the responsible vendor. Back up application data and configuration using a tested restore process. If an incident is suspected, preserve evidence before changing processes or files.

Test the intended PHP build with the application, extensions, scheduled jobs and database in staging. Plan a maintenance window or a rolling change with health checks. Keep a configuration and application rollback plan; do not restore a vulnerable runtime to public traffic without restricting exposure.

For mod_php deployments

Update the distribution’s PHP Apache module package and related PHP packages from the verified fixed source. Test the Apache configuration and application before restarting Apache in a controlled window or rolling replacement.

The PHP advisories describe pre-application mod_php exploitation paths. Do not rely on a CMS patch, authentication page or hidden PHP errors to protect the embedded runtime.

For Apache with PHP-FPM

Update the PHP-FPM backend, then restart or replace those workers. An Apache restart alone leaves a separate FPM service running the old code. Review all sockets or upstream mappings and confirm the serving build on each node.

Changes to .htaccess or per-directory PHP overrides should be reviewed for compatibility and early initialization behavior, but configuration cleanup does not replace the complete engine fixes.

Verify the result and handle a delayed patch

Check the actual web-serving binary, package revision or image on every instance. Replace old workers and verify their startup times. Validate application health, uploads, sessions, queue workers and scheduled jobs. CLI output alone does not prove what serves HTTP requests.

If a fixed deployment fails compatibility checks, restrict access and escalate to your vendor or administrator. Temporary WAF or configuration changes may reduce specific attack paths but are not a complete substitute for patching. Investigate suspicious activity separately: a successful update cannot establish that the system was never compromised.

CHECK THE ORIGINAL GUIDANCE

Sources & further reading

PHP project · October 2026 security releases↗PHP advisory · Out-of-memory corruption↗PHP advisory · Stale global state↗Apache · apachectl↗

Advisory snapshot: 2026-10-22. Next review due: 2026-10-29. Recheck sources before acting; this site does not update advisories automatically.