mod_php vs PHP-FPM: Which PHP Setup Is Riskier?

The mod_php vs PHP-FPM choice decides how PHP runs inside your web stack, and it changes how exposed you are to runtime bugs. mod_php embeds the PHP interpreter in every Apache process. PHP-FPM runs PHP as a separate pool of worker processes that the web server talks to over FastCGI. The October 2026 PHP2Shell vulnerabilities showed the difference in practice: the PHP project rated mod_php the highest-risk setup.

What is a PHP SAPI?

A SAPI (Server API) is the layer that connects the PHP interpreter to whatever is feeding it requests. mod_php, PHP-FPM, CGI, the command line, LiteSpeed LSAPI and FrankenPHP are all SAPIs, and each one starts, runs and shuts down a request in its own way.

That lifecycle matters for security. A bug that only triggers when a request starts badly, or when state leaks from one request into the next, can be harmless under one SAPI and exploitable under another, even with identical PHP code and identical application code.

What is mod_php?

mod_php is an Apache module that loads the PHP interpreter directly into each Apache worker process. Apache handles the connection and PHP runs inside the same process, under the same account as the web server.

It is the oldest way to run PHP and is still common on shared hosting and older Linux builds because it needs almost no setup. Its main costs are that every Apache process carries the interpreter whether it serves PHP or a static file, all sites on the server share one identity, and per-directory settings from .htaccess (php_value, php_flag) apply very early in the request.

What is PHP-FPM?

PHP-FPM (FastCGI Process Manager) runs PHP as its own service with one or more pools of worker processes. The web server, usually Nginx or Apache with its event worker, forwards PHP requests to a pool over a socket and serves static files itself.

Each pool can run under its own user, with its own settings and limits. That makes it the default on most modern distributions and container images, and it is what managed hosting platforms generally use.

mod_php vs PHP-FPM security differences

The differences that matter to a defender fall into four areas.

• Process isolation. With mod_php, PHP code runs inside the web server process. With PHP-FPM, a compromised worker gets the pool's account, which can be a different, lower-privilege user per site.
• Request lifecycle. The PHP2Shell advisory for CVE-2026-109618 explains that mod_php runs the request shutdown procedure even when request startup has failed. PHP-FPM exits the child process instead. That single difference is why remote code execution was validated on mod_php with default limits, while no complete FPM exploit was demonstrated for that CVE.
• Early configuration. mod_php applies .htaccess and directory-level PHP settings before request startup. The advisory for CVE-2026-109619 names that as part of what makes mod_php the most exposed. FPM pool values and .user.ini files do not provide the same early path, though FPM can still be exposed if the front end passes PHP_VALUE or PHP_ADMIN_VALUE parameters.
• Worker reuse. Both SAPIs reuse long-lived workers, which is what lets stale state from one request reach the next. FPM gives you a direct control over that: pm.max_requests. The PHP advisory lists pm.max_requests=1 (a fresh worker per request) as a mitigation when performance is not a concern.

PHP-FPM is not safe by default. CVE-2026-109619 was still validated for code execution on a normal dynamic FPM pool through session upload progress. The difference is degree, not immunity.

Which PHP setup is riskier?

mod_php is the riskier setup for runtime memory bugs like PHP2Shell, because it processes failed requests in the same long-lived web server process and applies directory settings early. PHP-FPM narrows the attack paths and lets you isolate sites, but it still needs patching on the same schedule.

How do you tell which SAPI a server uses?

Check how the web server hands off PHP requests: an Apache configuration that loads a PHP module means mod_php, while a configuration that proxies requests to a FastCGI socket or port means PHP-FPM or another FastCGI SAPI. A phpinfo page restricted to administrators also reports the Server API line.

Do this per site, not per server. Mixed hosts are common, and older virtual hosts often keep mod_php after newer ones moved to FPM.

When to move off mod_php

If you still run mod_php, plan the migration now rather than during the next emergency.

1. Inventory every host and virtual host that loads the PHP Apache module.
2. Move each site to its own FPM pool with its own user and only the file permissions it needs. Our piece on why your web server account should not read your secrets covers that permission model.
3. Replace .htaccess PHP directives with pool or php.ini settings applied at startup, which the PHP advisory also recommends.
4. Set enforced limits per pool with php_admin_value and php_admin_flag so applications cannot override them.

For the end-of-life branches that still run on many mod_php hosts, see why end-of-life PHP versions need a retirement plan. For the setting the advisories recommend on every SAPI, see how to disable PHP session upload progress.