Plesk: Understanding PHP Handlers (FPM, FastCGI, Apache Module)

In short: The Plesk PHP handler determines how PHP runs for a website: as an FPM application with a shared pool, as Dedicated FPM with its own pool per website, as a FastCGI application or as an Apache module (mod_php). From a security standpoint, Dedicated FPM is usually the best choice on Linux and the Apache module the worst. Plesk itself describes it as outdated or insecure, and with PHP2Shell the PHP team sees the highest risk precisely with mod_php.

Why the handler is more than a performance question

In Plesk, you choose a PHP version and a handler for each website. Many treat the handler as a detail of performance and memory. But it also decides how strongly websites are separated from one another, where security settings take effect and which processes must be restarted after an update.

After PHP2Shell, this choice becomes concrete. The vulnerabilities CVE-2026-109618 and CVE-2026-109619 affect all common operating modes, but the PHP team rates the risk highest for mod_php. Anyone still running domains with the Apache module on their Plesk server should change that now. How to check and patch versions is described on the page Plesk servers: checking and patching PHP versions; this article is about choosing the operating mode.

The Plesk PHP handlers at a glance

The overview below is based on the Plesk documentation for Plesk Obsidian, supplemented with the security view. On Linux, according to Plesk, FPM handlers can be served via either Apache or nginx, FastCGI always via Apache.

Background on the operating modes themselves is explained on the pages PHP-FPM explained and Why mod_php carries the highest risk.

Shared or own pool?

The difference between FPM and Dedicated FPM is often underestimated. With the normal FPM handler, according to Plesk, all websites with the same PHP version share one process pool. That saves memory, but it also means: a website that causes problems can drag along all others with the same version, and the shared cache is shared.

Dedicated FPM gives each website its own pool. According to Plesk, this improves isolation and performance but costs more memory. From a security standpoint, the own pool is the basis for setting values such as open_basedir, memory limits or upload limits separately per website. How to separate pools consistently is described in the article Isolating PHP-FPM pools per website.

nginx or Apache: the .htaccess trap

If you choose a handler that is served via nginx, something fundamental changes: according to Plesk, these handlers ignore the .htaccess file. What is written there no longer has any effect.

This is a security issue. Many applications and admins put protective rules in .htaccess, such as a ban on executing PHP files in upload folders, or blocks for configuration files. After a switch to nginx, these rules are silently out of force. Before switching, therefore, check which protective rules are in .htaccess and carry them over into the domain's nginx configuration.

Checking and switching the handler

First, get an overview of which domains use which handler. The commands are read-only.

# All registered handlers with ID, version and type
plesk bin php_handler --list

# Domains that use a particular handler (ID from the list)
plesk bin php_handler --get-usage -id <handler-id>

# Is PHP running inside the Apache process? (Debian/Ubuntu: apache2ctl, RHEL family: httpd)
apache2ctl -M 2>/dev/null | grep -i php

For the switch, proceed domain by domain:

1. Record the protective rules from .htaccess if the new handler is served via nginx.
2. Set interim values against PHP2Shell, such as session.upload_progress.enabled=0, for the new handler. With FPM, they belong as php_admin_value in the pool's additional directives; with FastCGI, other routes apply.
3. Change the handler in the domain's PHP settings, preferably on a copy first.
4. Test functions and check whether the domain is served by processes with current code.
5. If no domain uses the Apache module any longer, deactivate the handler.

In which order to switch?

On a grown Plesk server, everything can rarely be switched in one day. An order by risk helps to use the scarce time sensibly:

• First, domains with the Apache module, because there the PHP2Shell risk is highest according to the PHP team, and Plesk advises against it anyway.
• Then, domains with sensitive data, such as shops, customer portals or forms with health or contract data. The own pool is especially worthwhile here.
• After that, domains on old PHP versions that must be switched anyway. Handler and version can be changed together in one maintenance window.
• Last, the change from the shared to the own pool for the remaining domains, provided the server's memory allows it.

Check memory utilization before the last stage. Plesk points out that Dedicated FPM needs more memory and advises monitoring when there are many websites. A server that swaps memory out after the change becomes slow, and tight memory is not a good state, especially with PHP2Shell.

How does PHP SOS help?

• We record which domains on your Plesk server use which handler, and flag domains with the Apache module.
• We switch to Dedicated FPM and carry protective rules from .htaccess over into the nginx configuration where needed.
• We set interim values and limits per pool and check that they take effect in the web context.
• Within server hardening, we deactivate outdated handlers and document the configuration.

Frequently asked questions

Sources

• Plesk documentation: Choosing the PHP Handler
• Plesk documentation: php_handler
• php.net: Security announcements