Kort gezegd: Door PHP2Shell zijn alle gangbare werkwijzen getroffen, maar bij Apache met mod_php schat het PHP-team het risico het hoogst in. Daar is een exploit getoond voordat er zelfs maar toepassingscode draait. Wie mod_php draait, moet PHP eerst bijwerken en Apache volledig herstarten.
Wat is mod_php?
Bij mod_php is PHP een module binnen de Apache-webserver. Elk Apache-proces bevat een volledige PHP-interpreter en voert PHP-code direct uit. Deze werkwijze was lang de standaard en is op oudere servers, in veel distributiepakketten en in sommige Docker-images tot vandaag verbreid.
Het alternatief is PHP-FPM: daar draait PHP als eigen dienst met eigen processen, en Apache of Nginx geeft verzoeken alleen door. Beide varianten zijn door PHP2Shell getroffen, evenals php-cgi, FrankenPHP en LiteSpeed.
Typische omgevingen met mod_php zijn oudere rootservers die al jaren ongewijzigd draaien, standaardinstallaties van Apache uit distributiepakketten en Docker-images met Apache en PHP in één container. Wie niet zeker weet welke werkwijze zijn server gebruikt, moet het controleren in plaats van aannemen.
Waarom geldt de mod_php-kwetsbaarheid als bijzonder riskant?
Het PHP-team heeft over PHP2Shell een duidelijke inschatting gegeven: bij mod_php is het risico het hoogst. Motivering: daar is een exploit getoond die werkt voordat er zelfs maar toepassingscode draait.
Voor beheerders heeft dat een onaangenaam gevolg. Veel beschermingsmaatregelen zitten in de toepassing: beveiligingsplugins in WordPress, firewallmodules in shops, controles in de eigen code. Het is allemaal toepassingscode. Als het misbruik daarvóór plaatsvindt, komen ze te laat.
Daarbij komt de nauwe verwevenheid: bij mod_php deelt PHP het proces met Apache. Wat PHP compromitteert, draait met de rechten van de webserver en in diens geheugen. Bij PHP-FPM kunnen pools daarentegen met eigen gebruikers per website worden gescheiden, wat de gevolgen van een inbraak kan beperken.
Voor de prioritering betekent dat: draait u meerdere servers, dan komen die met mod_php het eerst aan de beurt, en bij hen is een aansluitende controle op sporen bijzonder belangrijk.
Wat we niet weten: hoeveel van de wereldwijd getelde 22,6 miljoen blootgestelde, mogelijk kwetsbare instanties mod_php gebruiken. Betrouwbare cijfers daarover zijn niet gepubliceerd.
Gebruikt mijn server mod_php?
De volgende opdrachten zijn puur lezend. Dienst- en opdrachtnamen verschillen per distributie: Debian en Ubuntu gebruiken apache2, de RHEL-familie httpd.
apachectl -M 2>/dev/null | grep -i php # bijv. php_module of php8_module
httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php # Debian/Ubuntu
apt policy libapache2-mod-php8.3 # Debian/Ubuntu, pakketstand van de module
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-familie
Verschijnt er geen PHP-module, dan gebruikt Apache waarschijnlijk PHP-FPM via proxy_fcgi. Dan gelden de aanwijzingen onder Nginx met PHP-FPM beveiligen naar analogie.
Wat mod_php-beheerders nu moeten doen
- PHP-module bijwerken naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of een bevestigde backport van uw distributie.
- Apache volledig herstarten, niet alleen herladen. Bij mod_php zit de oude PHP-code in elk Apache-proces.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL-familie
ps -o pid,lstart,cmd -C apache2 # starttijd controleren, onder RHEL: -C httpd
- Overbruggingsmaatregelen instellen als de update nog niet kan. php.net noemt onder meer vaste grenzen die toepassingen niet kunnen overschrijven:
# Serverconfiguratie of VirtualHost, niet .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Bij memory_limit=-1 hoort een geheugengrens via cgroup, niet via RLIMIT_AS of RLIMIT_DATA. Deze maatregelen zijn geen volledige bescherming; de details staan onder Spoedmaatregelen als u nog niet kunt patchen. Kan geen van beide direct, dan adviseert het BSI de webserver tijdelijk van het netwerk te halen.
Stond uw Apache met mod_php tussen 17 oktober en de patch onbeschermd op het internet, veiligstel dan de logs vanaf 20 oktober en laat de server op sporen controleren. De patch alleen bewijst niet dat er niets is gebeurd.
Op middellange termijn: weg van mod_php
Na de patch loont een blik op de architectuur. De overstap naar PHP-FPM met Apache mpm_event en proxy_fcgi of met Nginx scheidt PHP van de webserver, maakt eigen pools en gebruikers per website mogelijk en maakt herstarts en versiewissels eenvoudiger. Hij dicht PHP2Shell niet, maar verkleint het aanvalsoppervlak van toekomstige kwetsbaarheden.
De omschakeling vraagt om planning. Instellingen die tot nu toe via php_value in .htaccess werden gezet, werken onder PHP-FPM niet meer en moeten naar de pool verhuizen. Gebruikers en rechten veranderen, upload- en cachemappen hebben mogelijk nieuwe machtigingen nodig. In een testomgeving is dat goed beheersbaar, in de lopende bedrijfsvoering onder tijdsdruk niet. Aanwijzingen voor de omschakeling vindt u onder Apache met mod_php beveiligen.
Hoe helpt PHP SOS concreet?
- Herkennen: wij controleren welke servers mod_php gebruiken en uit welke pakketbron de module komt.
- Patchen en herstarten: via de PHP-patchservice installeren we de update en controleren we dat er geen oud Apache-proces meer draait.
- Overgang beveiligen: waar de update geblokkeerd is, stellen we de maatregelen van php.net in de serverconfiguratie in.
- Omzetten: in het kader van de serverhardening plannen en testen we de overstap naar PHP-FPM met gescheiden pools.
Veelgestelde vragen
Hoe herken ik of mijn Apache mod_php gebruikt?
Met apachectl -M of httpd -M ziet u de geladen modules. Staat daar een module als php_module of php8_module, dan draait PHP direct in Apache. Onder Debian en Ubuntu toont ook a2query -m of een php-module actief is.
Beschermt een beveiligingsplugin in WordPress mij bij mod_php?
Bij deze kwetsbaarheid niet. Volgens het PHP-team is bij mod_php een exploit getoond voordat er zelfs maar toepassingscode draait. Een plugin is toepassingscode en komt dus te laat. Bescherming biedt alleen de PHP-update met herstart van Apache.
Moet ik nu van mod_php overstappen op PHP-FPM?
Eerst patchen, dan omzetten. De overstap naar PHP-FPM is voor de meeste opstellingen op middellange termijn zinvol, omdat PHP dan gescheiden van de webserver draait. Hij dicht PHP2Shell echter niet, want PHP-FPM is eveneens getroffen.