Actuele situatie: PHP2Shell. Twee kritieke PHP-kwetsbaarheden (CVSS 9.2) maken schadelijke code zonder inloggen mogelijk. Patches sinds 21-10-2026.Wat u nu moet doen →

mod_php uitgelegd: PHP in het Apache-proces

Bij mod_php zit PHP in elk Apache-proces. Dat is eenvoudig, maar weinig flexibel en na PHP2Shell de riskantste uitvoeringsmodus. Zo werkt ze en zo herkent u haar.

Stand 5 min. leestijdPHP-kennis

Kort gezegd: mod_php is PHP als module in de Apache-webserver. Elk Apache-proces bevat dan een volledige PHP-interpreter en voert PHP-code zelf uit; de SAPI heet apache2handler. Dat is eenvoudig in te richten, maar bindt PHP aan Apache, vraagt meestal de prefork-MPM en staat nauwelijks scheiding tussen websites toe. De PHP-handleiding raadt het voor nieuwe installaties af, en bij PHP2Shell schat het PHP-team het risico bij mod_php het hoogst in.

Wat is mod_php?

Bij mod_php laadt Apache PHP als eigen module in zijn processen. Er is geen afzonderlijke PHP-dienst: moet Apache een .php-bestand uitleveren, dan voert hetzelfde proces dat het verzoek heeft aangenomen ook de PHP-code uit. Jarenlang was dit de standaardmanier om PHP te draaien, en op oudere servers en in sommige Docker-images is het tot op vandaag wijdverbreid.

Volgens de PHP-handleiding leest PHP als servermodule zijn configuratie maar één keer, bij het starten van de webserver. Wijzigingen in de php.ini en updates van de module werken daarom pas na een herstart van Apache.

Belangrijk voor het begrip: Apache-processen leven lang. Een proces neemt na elkaar veel verbindingen aan voordat het wordt vervangen; hoeveel, regelt de Apache-directive MaxConnectionsPerChild. De ingebedde PHP-interpreter blijft in die tijd dezelfde. Wie de bibliotheek libphp op de schijf vervangt, verandert niets aan de lopende processen.

Voor directie en projectverantwoordelijken is dit zo samen te vatten: bij mod_php zijn webserver en PHP één geheel. Wie het ene aanraakt, raakt het andere. Een PHP-update betekent een herstart van de webserver, een fout in PHP draait met de rechten van de webserver, en een scheiding tussen meerdere websites op dezelfde server is nauwelijks mogelijk.

Hoe wordt mod_php ingebonden?

De PHP-handleiding toont de inbinding in twee stappen: de module laden en vastleggen welke bestanden PHP moet verwerken.

LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

De handleiding adviseert FilesMatch met SetHandler in plaats van alleen AddType, zodat geüploade bestanden als bild.php.jpg niet als PHP worden uitgevoerd. Onder Debian en Ubuntu nemen pakketten als libapache2-mod-php8.3 en de opdrachten a2enmod en a2dismod dit werk over.

Of mod_php actief is, kan lezend worden gecontroleerd:

apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL-familie
apachectl -V | grep -i mpm               # actieve MPM (prefork, worker, event)

Prefork, Thread Safety en resources

Apache verdeelt verzoeken via een Multi-Processing-Module (MPM). Volgens de PHP-handleiding vereist mod_php de prefork-MPM, tenzij PHP met Zend Thread Safety (--enable-zts) is gebouwd. De meeste distributiepakketten zijn zonder Thread Safety gebouwd.

Prefork betekent: één proces per gelijktijdige verbinding, en elk proces draagt een complete PHP-interpreter. Ook verzoeken om afbeeldingen of CSS-bestanden bezetten dus een proces met PHP in de bagage. Dat kost geheugen en beperkt de belasting die een server kan dragen.

Kenmerk mod_php PHP-FPM
Waar draait PHP? in elk Apache-proces in een eigen dienst
Apache-MPM meestal prefork event mogelijk
Gebruiker per website nee, alles als Apache-gebruiker ja, per pool
PHP herstarten alleen met Apache onafhankelijk van Apache
Instellingen per map php_value in .htaccess pool of .user.ini

De handleiding adviseert daarom voor alle moderne installaties PHP-FPM met mod_proxy_fcgi: beter resourcebeheer, processcheiding, herstart van PHP zonder herstart van Apache en compatibiliteit met de event-MPM, die sinds Apache 2.4 standaard is. De basis staat onder PHP-FPM uitgelegd.

Instellingen met .htaccess, php_value en php_admin_value

Met mod_php kunnen PHP-instellingen direct in de Apache-configuratie worden gezet. De handleiding onderscheidt daarbij wijzigingsmodi: vermeldingen met INI_PERDIR mogen in php.ini, .htaccess of httpd.conf staan, vermeldingen met INI_SYSTEM alleen in php.ini of httpd.conf.

# In de VirtualHost-configuratie: voor de toepassing vergrendeld
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# In .htaccess mogelijk, maar door de toepassing te overschrijven
php_value max_execution_time 60

php_admin_value en php_admin_flag zijn alleen in de serverconfiguratie toegestaan, niet in .htaccess. Precies dit onderscheid is bij de tussenmaatregelen voor PHP2Shell belangrijk, omdat waarden als session.upload_progress.enabled niet door de toepassing teruggezet mogen worden.

mod_php en PHP2Shell: waarom het risico het hoogst is

Het PHP-team schat het risico door PHP2Shell bij mod_php het hoogst in: daar is een exploit gedemonstreerd voordat er ook maar toepassingscode draait. Beveiligingsplug-ins of controles in het CMS komen daarmee te laat. Daar komt bij dat PHP bij mod_php met de rechten en in het geheugen van de webserver draait. De uitgebreide duiding staat onder Waarom mod_php het hoogste risico draagt.

Voor beheerders geldt daarom:

  1. De PHP-module bijwerken naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35, dan wel een bevestigde backport.
  2. Apache volledig opnieuw starten, niet alleen herladen, en de starttijd van de processen controleren.
  3. Tussenwaarden via php_admin_value in de serverconfiguratie instellen als de update nog niet mogelijk is.
  4. Daarna de overstap naar PHP-FPM plannen, zoals beschreven onder Apache met mod_php beveiligen.

Hoe helpt PHP SOS concreet?

  • Herkennen: Wij controleren op welke servers mod_php draait, met welke MPM en uit welke pakketbron.
  • Patchen: Wij werken de PHP-module bij, starten Apache volledig opnieuw en leggen de stand vast.
  • Overgang beveiligen: Waar de update geblokkeerd is, zetten wij de maatregelen van php.net vergrendeld in de serverconfiguratie.
  • Omschakelen: In het kader van de serverhardening migreren wij getest naar PHP-FPM met eigen pools.

Veelgestelde vragen

Waarom heet het mod_php als de module php_module heet?

mod_php is de omgangsnaam voor PHP als Apache-module. In de configuratie wordt ze met LoadModule geladen; de PHP-handleiding noemt als voorbeeld LoadModule php_module modules/libphp.so. Oudere versies gebruikten namen als php7_module of php5_module.

Waarom heeft mod_php de prefork-MPM nodig?

Volgens de PHP-handleiding vereist mod_php de prefork-MPM, tenzij PHP met Zend Thread Safety is gebouwd. De meeste distributiepakketten zijn zonder Thread Safety gebouwd. Prefork start voor elke gelijktijdige verbinding een eigen proces, wat meer geheugen kost.

Werken php_value-regels in .htaccess ook met PHP-FPM?

Nee. php_value en php_flag in .htaccess zijn Apache-directives van de PHP-module en werken alleen met mod_php. Onder PHP-FPM horen zulke instellingen in de pool of, voor toegestane waarden, in een .user.ini.

Moet ik mod_php meteen afschaffen?

Eerst komt de update van PHP met volledige herstart van Apache. De overstap naar PHP-FPM is daarna zinvol, maar moet worden gepland en getest. Ze sluit PHP2Shell niet, omdat PHP-FPM eveneens is getroffen.

Bronnen

Direct contact

Elk uur telt. Schrijf ons nu.

Beschrijf kort het systeem, de PHP-versie en wat u opmerkt. Wij nemen contact op, brengen de situatie in kaart en werken op afstand tot het incident is afgerond en gedocumenteerd.

Directe hulp