Kort gezegd: Bij Apache met mod_php draait PHP rechtstreeks in de webserver. Het PHP-team schat het risico van PHP2Shell juist in deze uitvoeringsmodus het hoogst in, omdat er een exploit is getoond voordat er überhaupt toepassingscode draait. Patch onmiddellijk, herstart Apache volledig en plan daarna de overstap naar PHP-FPM.
Wat mod_php is en waarom het nu telt
Bij mod_php laadt Apache PHP als module in elk eigen werkproces. Elk verzoek aan een PHP-bestand wordt rechtstreeks in dat proces uitgevoerd. Lange tijd was dat de standaard en het is eenvoudig in te richten. Het betekent echter ook: alle websites op de server draaien met dezelfde gebruiker, en PHP deelt het proces met de webserver.
PHP2Shell omvat de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619, beide met CVSS v4.0 9.2. Bij de tweede kan de interne toestand van een verzoek na het vrijgeven van het geheugen blijven bestaan en door een later verzoek in hetzelfde proces worden gebruikt. Voor mod_php heeft het PHP-team het hoogste risico vastgesteld. Achtergrond en duiding vindt u onder Waarom mod_php het hoogste risico draagt.
Apache mod_php herkennen en versie controleren
Controleer eerst of uw Apache überhaupt mod_php gebruikt. De volgende opdrachten lezen alleen. Opdracht- en pakketnamen verschillen per distributie en zijn voorbeelden.
# Debian/Ubuntu: geladen modules
apache2ctl -M 2>/dev/null | grep -i php
# RHEL-familie
httpd -M 2>/dev/null | grep -i php
# Welke MPM is actief? mod_php vereist prefork
apache2ctl -V 2>/dev/null | grep -i mpm
# Pakketstatus van de module (voorbeelden)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'
Verschijnt er een module zoals php_module, dan draait mod_php. De getoonde PHP-versie alleen is geen bewijs van de patch, omdat distributies correcties vaak als backport doorvoeren. Gecorrigeerde versies van het PHP-project zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Bij distributiepakketten telt het wijzigingslogboek met de CVE-nummers.
Patchen en Apache volledig herstarten
Voer de update door via de pakketbeheerder. Omdat PHP in het Apache-proces zit, moet daarna de hele dienst herstarten. Het herladen van de configuratie is hier niet de veilige weg.
# Debian/Ubuntu
systemctl restart apache2
# RHEL-familie
systemctl restart httpd
# Controle: starttijd van alle Apache-processen
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep
Alle Apache-processen moeten een starttijd na de update tonen. Draait op dezelfde server bovendien PHP-FPM of php-cgi, herstart dan ook die diensten.
Is er voor uw PHP-versie nog geen patch beschikbaar, dan adviseert het BSI (de Duitse federale dienst voor informatiebeveiliging) de webserver tijdelijk van het net te halen. Bij mod_php weegt dat extra zwaar, omdat de aanval kan toeslaan vóór de toepassingscode.
Overbruggingsmaatregelen in de Apache-configuratie
php.net noemt overbruggingsmaatregelen die het risico verlagen, maar geen volledige bescherming bieden. Bij mod_php stelt u de waarden in met php_admin_value respectievelijk php_admin_flag in de Apache-configuratie, zodat .htaccess en toepassingen ze niet kunnen overschrijven.
# Voorbeeld: in de VirtualHost- of serverbrede configuratie
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
php_admin_value post_max_size 8M
php_admin_value upload_max_filesize 6M
</IfModule>
Met uploadfunctie noemt php.net post_max_size = 32M, met upload_max_filesize daaronder. Op PHP 8.5 komt fatal_error_backtraces=0 erbij. De aanwijzing over memory_limit=-1 past u alleen toe samen met een geheugengrens voor de dienst via cgroups, bijvoorbeeld via MemoryMax in een systemd-aanvulling, niet via RLIMIT_AS of RLIMIT_DATA. Daarna Apache volledig herstarten. Alle maatregelen in overzicht: Directe maatregelen zonder patch.
De weg weg van mod_php
Na de acute patch loont de overstap naar PHP-FPM. Daarbij draait PHP in eigen processen, gescheiden van de webserver. Elke website kan een eigen pool met een eigen gebruiker krijgen, grenzen zijn per pool in te stellen en herstarts raken alleen PHP. Apache koppelt PHP-FPM via mod_proxy_fcgi en kan dan in plaats van prefork een modernere MPM zoals event gebruiken.
Plan de overstap in een testomgeving: pools per website aanmaken, bestandsrechten aanpassen aan de nieuwe gebruikers, .htaccess-vermeldingen met php_value overbrengen naar pool-instellingen, belastingstests uitvoeren. Hoe een nette opzet eruitziet, toont Nginx met PHP-FPM beveiligen; de uitgangspunten gelden evengoed voor Apache met PHP-FPM.
Los van de uitvoeringsmodus geldt: een patch verwijdert geen reeds ingebrachte schadelijke software. Bewaar de logs vanaf 20-10-2026 en controleer de server op sporen.
Bij het speuren naar sporen op mod_php-servers loont een blik op de gedeelde gebruiker. Omdat alle websites onder de Apache-gebruiker draaien, bijvoorbeeld www-data of apache, kan een aanvaller die één website heeft overgenomen in de regel ook de bestanden van de andere lezen en wijzigen. Controleer daarom niet alleen de website die u opvalt, maar alle document roots op de server. Let vooral op PHP-bestanden met een recente wijzigingsdatum in upload- en cachemappen, op programmacode die eigendom is van de Apache-gebruiker en op onbekende vermeldingen in de crontab van die gebruiker. Vindt u iets, leg dan eerst de toestand vast en verwijder niet overhaast, zodat de oorzaak later te achterhalen blijft.
Hoe helpt PHP SOS concreet?
- Wij controleren uitvoeringsmodus, MPM en pakketstatus en beoordelen of uw server daadwerkelijk is gepatcht.
- Via de PHP-patchservice voeren we de update door, herstarten we Apache volledig en documenteren we het bewijs.
- Tot de patch stellen we de overbruggingsmaatregelen niet-overschrijfbaar in en beperken we het geheugen op dienstniveau.
- 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 server mod_php gebruikt?
Als Apache een PHP-module heeft geladen, verschijnt dat in de modulelijst als php_module of met een versienummer in de naam. Bovendien toont een phpinfo-uitvoer onder Server API de vermelding Apache 2.0 Handler. Verwijder zo'n testbestand direct weer.
Waarom is mod_php bij PHP2Shell bijzonder kritiek?
Volgens het PHP-team is het risico daar het hoogst; er is een exploit getoond voordat er überhaupt toepassingscode draait. Daardoor beschermt ook een goed onderhouden toepassing niet. Een snelle update heeft daarom de hoogste prioriteit.
Volstaat een reload van Apache na de update?
Veilig is een volledige herstart van de dienst, omdat PHP als module in de Apache-processen zit. Controleer daarna de starttijd van alle Apache-processen. Er mogen geen processen overblijven die ouder zijn dan de update.
Is de overstap naar PHP-FPM arbeidsintensief?
Meestal is hij goed te plannen: PHP-FPM installeren, pools aanmaken, Apache omzetten naar proxy_fcgi en van prefork naar een andere MPM overgaan. Test dat vooraf in een kopie van de omgeving.