# PHP Composer moves to PHP-FPM

> The PHP Composer Docker image now uses PHP-FPM, following PHP's recommendation and the recent PHP2Shell vulnerabilities.

**Tag:** [Announcements](https://lizzy.nu/blog/tag/announcements)
**Published:** October 23, 2026
**Author:** Lizzy

![Cover Image](https://cdn.lizzy.nu/blog/2026/php-composer-fpm.webp)

I've updated my PHP Composer Docker image to use PHP-FPM. The new version is available at [cuteminded/php-composer](https://hub.docker.com/r/cuteminded/php-composer) and is a drop-in replacement for the previous image.

The old Apache *mod_php* version now lives at [cuteminded/php-composer-legacy](https://hub.docker.com/r/cuteminded/php-composer-legacy), so it remains available if you need it.

## What's changed?

The main change is how PHP runs inside the container. The previous image used Apache's *mod_php* module to execute PHP. The new image uses PHP-FPM to handle PHP execution.

For anyone using the image, the move is intended to be straightforward. You can replace the old image with the new one without reworking your application or deployment setup.

## Why move to PHP-FPM?

The [official PHP manual](https://www.php.net/manual/en/install.unix.apache2.php) explicitly advises against using *mod_php* for new installations. It recommends PHP-FPM with Apache's *mod_proxy_fcgi* module for modern deployments.

With *mod_php*, PHP runs inside Apache's worker processes. PHP-FPM runs PHP in separate processes, giving it independent resource management and allowing PHP to restart without restarting Apache. It also works with Apache's *event* MPM, the component that manages how Apache handles connections. Typical *mod_php* installations require *prefork* instead, which limits how well Apache handles concurrent requests.

The move to PHP-FPM follows that recommendation. The warning doesn't announce the removal of *mod_php*, but it makes PHP's recommended approach for new installations clear.

## PHP2Shell was another reason to make the switch

The recent PHP2Shell vulnerabilities were another reason I moved the image to PHP-FPM. In its [security advisory from 21 October 2026](https://www.php.net/archive/2026.php#2026-10-21-5), the PHP team considered the risk highest for *mod_php*. A demonstrated exploit allowed an unauthenticated request to trigger an attack before any application code ran.

PHP-FPM was affected too, so switching to FPM alone does not fix these vulnerabilities. Running a patched PHP version is still essential. The fixes for [CVE-2026-109618](https://nvd.nist.gov/vuln/detail/cve-2026-109618) and [CVE-2026-109619](https://nvd.nist.gov/vuln/detail/cve-2026-109619) were released in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The higher risk reported for *mod_php* gave me another concrete reason to move away from it.

## Switching to the new image

Use *cuteminded/php-composer* for the PHP-FPM version. If your configuration already points to that repository, the image name stays the same. Pull the updated image and recreate your container to use it.

If you've switched your configuration to *cuteminded/php-composer-legacy*, change the repository back to *cuteminded/php-composer* when you're ready to move to PHP-FPM. Choose the tag that matches the PHP version and image variant you need.

## What happens to the legacy image?

The Apache *mod_php* image isn't disappearing. It won't receive new features, but I'll continue updating it for as long as upstream support makes that possible.

Further development will focus on the PHP-FPM image. The legacy repository remains available for setups that still need the old version.