php-cgi: oude erfenis met risico

Kort gezegd: php-cgi is de oudste manier om PHP achter een webserver te draaien en loopt nog op veel servers, vaak ongemerkt. De php-cgi kwetsbaarheid uit PHP2Shell treft deze uitvoeringsmodus uitdrukkelijk. Patch, beëindig alle lopende php-cgi-processen en plan de overstap naar PHP-FPM.

Wat php-cgi is en waar het nog draait

PHP bestaat in meerdere varianten: als opdrachtregelprogramma, als Apache-module, als PHP-FPM en als php-cgi. php-cgi is een programma dat de webserver start en waaraan hij verzoeken doorgeeft via CGI of FastCGI. Zonder eigen procesbeheer is het eenvoudiger dan PHP-FPM, maar ook minder beheersbaar.

Typische vindplaatsen zijn oudere hostingpanelen, Apache met mod_fcgid, eigen wrapperscripts voor meerdere PHP-versies en PHP onder Windows met IIS via FastCGI. Bij bureaus en overheden vindt men bovendien servers die jaren geleden zijn ingericht en sindsdien alleen nog draaiende zijn gehouden.

De php-cgi kwetsbaarheid bij PHP2Shell

PHP2Shell omvat de kwetsbaarheden CVE-2026-109618 en CVE-2026-109619 in PHP zelf, elk met CVSS v4.0 9.2. Beide maken het uitvoeren van schadelijke code zonder inloggen mogelijk. Het PHP-project noemt php-cgi uitdrukkelijk onder de getroffen uitvoeringsmodi, naast PHP-FPM, mod_php, FrankenPHP en LiteSpeed.

Verholpen zijn PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Voor PHP 8.1 en ouder zijn er geen officiële updates meer, alleen minimale backports van de broncode voor 7.4, 8.0 en 8.1. Juist php-cgi-opstellingen draaien bovengemiddeld vaak op oude versies. php-cgi is bovendien niet voor het eerst getroffen: al in 2024 zorgde een kwetsbaarheid in php-cgi onder Windows (CVE-2024-4577) voor opschudding. Erfenissen van dit soort verdienen daarom bijzondere aandacht.

php-cgi op de server vinden

De volgende opdrachten lezen alleen en helpen php-cgi op te sporen. Paden en modulenamen zijn voorbeelden.

# Lopende php-cgi-processen met starttijd en gebruiker
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Geïnstalleerde php-cgi-programma's
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

# Apache: zijn mod_fcgid of mod_cgi geladen?
apache2ctl -M 2>/dev/null | grep -Ei 'fcgid|cgi'
grep -RniE 'FcgidWrapper|AddHandler.*php|Action.*php' /etc/apache2 /etc/httpd 2>/dev/null

Vindt u FcgidWrapper-vermeldingen of handlers die naar een php-cgi-programma wijzen, dan draait deze uitvoeringsmodus. Controleer voor elk gevonden programma de versie met -v. Bij distributiepakketten onderbouwt het wijzigingslogboek met de CVE-nummers de patch, omdat backports het versienummer vaak niet wijzigen.

Patchen en alle processen beëindigen

Voer de update door via de pakketbeheerder of de bron waaruit php-cgi komt. Daarna moeten alle lopende php-cgi-processen verdwijnen. Bij mod_fcgid houdt Apache processen een tijd vast; een volledige herstart van Apache beëindigt ze.

# Apache volledig herstarten (Debian/Ubuntu respectievelijk RHEL-familie)
systemctl restart apache2   # of: systemctl restart httpd

# Controle: zijn er nog php-cgi-processen ouder dan de update?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Draait php-cgi via een eigen procesmanager of een paneldienst, herstart die dan. Onder Windows met IIS recyclet u de toepassingspools, zie PHP onder Windows en IIS.

Overbruggingsmaatregelen bij php-cgi

php.net adviseert overbruggingsmaatregelen die geen volledige bescherming bieden. Bij php-cgi horen de waarden in de php.ini die het betreffende programma laadt, of in de serverconfiguratie. .user.ini-bestanden en ini_set() volstaan voor session.upload_progress.enabled volgens php.net niet.

; php.ini van de php-cgi-installatie
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Met uploadfunctie noemt php.net post_max_size = 32M. Op PHP 8.5 komt fatal_error_backtraces=0 erbij. Geheugengrenzen stelt u in via cgroups voor de webserverdienst, niet via RLIMIT_AS of RLIMIT_DATA. Herstart daarna alle processen.

De weg naar PHP-FPM

Op den duur is php-cgi geen goede keuze. PHP-FPM biedt pools per website, eigen gebruikers, grenzen per pool, statuspagina's en gecontroleerde herstarts. De overstap is meestal goed te plannen: PHP-FPM installeren, pools aanmaken, de webserver omzetten naar FastCGI richting PHP-FPM, wrapperscripts verwijderen. Hoe een nette opzet eruitziet, toont Nginx met PHP-FPM beveiligen. Draait er bovendien een oude PHP-versie, combineer de overstap dan met de upgrade.

Tot de overstap is gedaan, moet u de bestaande configuratie kritisch bekijken. De webserver mag alleen bestanden met de extensie .php aan php-cgi doorgeven en geen paden die naar niet-bestaande bestanden wijzen. In uploadmappen mag geen PHP-uitvoering mogelijk zijn. Wrapperscripts die per website een eigen php.ini laden, controleert u erop of die bestanden de overbruggingswaarden weer opheffen. Staat een php-cgi-programma direct in een openbaar bereikbare map zoals cgi-bin, dan hoort het daar verwijderd te worden. Dergelijke erfenissen stammen vaak uit installatiehandleidingen van voorbije jaren en worden bij latere verbouwingen simpelweg vergeten. Documenteer elke vondst met pad en doel, zodat de latere ombouw niets over het hoofd ziet.

Belangrijk blijft: een patch verwijdert geen schadelijke software die eerder is ingebracht. Bewaar de logs vanaf 20-10-2026.

Hoe helpt PHP SOS concreet?

• Wij sporen php-cgi-installaties, wrappers en handlers op en koppelen ze aan de websites.
• Wij patchen, beëindigen alle oude processen en documenteren de status.
• Voor PHP 8.1 en ouder plannen we met u de migratie naar een ondersteunde PHP-versie.
• In het kader van de serverhardening vervangen we php-cgi door PHP-FPM met gescheiden pools.

Veelgestelde vragen

Bronnen

• php.net: beveiligingsmeldingen
• PHP 8 ChangeLog
• php.net: ondersteunde versies
• BSI