php-cgi: ett arv med risk

Kort sagt: php-cgi är det äldsta sättet att driva PHP bakom en webbserver och körs fortfarande på många servrar, ofta obemärkt. php-cgi-sårbarheten i PHP2Shell berör uttryckligen det här driftläget. Patcha, avsluta alla körande php-cgi-processer och planera bytet till PHP-FPM.

Vad php-cgi är och var det fortfarande körs

PHP finns i flera varianter: som kommandoradsprogram, som Apache-modul, som PHP-FPM och som php-cgi. php-cgi är ett program som webbservern startar och som den lämnar förfrågningar till via CGI eller FastCGI. Utan egen processhantering är det enklare än PHP-FPM men också mindre kontrollerbart.

Typiska fyndplatser är äldre hostingpaneler, Apache med mod_fcgid, egna wrapper-skript för flera PHP-versioner och PHP under Windows med IIS via FastCGI. På byråer och myndigheter finns dessutom servrar som sattes upp för flera år sedan och sedan dess bara har drivits vidare.

php-cgi-sårbarheten i PHP2Shell

PHP2Shell omfattar sårbarheterna CVE-2026-109618 och CVE-2026-109619 i PHP självt, vardera med CVSS v4.0 9,2. Båda gör det möjligt att köra skadlig kod utan inloggning. PHP-projektet nämner uttryckligen php-cgi bland de berörda driftlägena, vid sidan av PHP-FPM, mod_php, FrankenPHP och LiteSpeed.

Åtgärdade är PHP 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För PHP 8.1 och äldre finns inga officiella uppdateringar längre, bara minimala backports i källkoden för 7.4, 8.0 och 8.1. Just php-cgi-uppsättningar körs över genomsnittet ofta på gamla versioner. php-cgi berörs dessutom inte för första gången: redan 2024 väckte en sårbarhet i php-cgi under Windows (CVE-2024-4577) uppmärksamhet. Den här typen av arv förtjänar därför särskild uppmärksamhet.

Hitta php-cgi på servern

Följande kommandon läser bara och hjälper till att spåra upp php-cgi. Sökvägar och modulnamn är exempel.

# Körande php-cgi-processer med starttid och användare
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Installerade php-cgi-program
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

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

Hittar ni FcgidWrapper-poster eller hanterare som pekar på ett php-cgi-program körs det här driftläget. Kontrollera versionen för varje hittat program med -v. För distributionspaket styrker ändringsloggen med CVE-numren patchen, eftersom backports ofta inte ändrar versionsnumret.

Patcha och avsluta alla processer

Installera uppdateringen via pakethanteringen eller den källa som php-cgi kommer från. Därefter måste alla körande php-cgi-processer försvinna. Med mod_fcgid håller Apache processer i beredskap en stund; en fullständig omstart av Apache avslutar dem.

# Starta om Apache helt (Debian/Ubuntu respektive RHEL-familjen)
systemctl restart apache2   # eller: systemctl restart httpd

# Kontroll: finns det fortfarande php-cgi-processer äldre än uppdateringen?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Körs php-cgi via en egen processhanterare eller en paneltjänst startar ni om den. Under Windows med IIS återvinner ni applikationspoolerna, se PHP under Windows och IIS.

Tillfälliga åtgärder för php-cgi

php.net rekommenderar tillfälliga åtgärder som inte ger något fullständigt skydd. Med php-cgi hör värdena hemma i den php.ini som respektive program laddar eller i serverkonfigurationen. .user.ini-filer och ini_set() räcker enligt php.net inte för session.upload_progress.enabled.

; php.ini för php-cgi-installationen
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M

Med uppladdningsfunktion anger php.net post_max_size = 32M. På PHP 8.5 tillkommer fatal_error_backtraces=0. Minnesgränser sätter ni via cgroups för webbservertjänsten, inte via RLIMIT_AS eller RLIMIT_DATA. Starta därefter om alla processer.

Vägen till PHP-FPM

Långsiktigt är php-cgi inget bra val. PHP-FPM erbjuder pooler per webbplats, egna användare, gränser per pool, statussidor och kontrollerade omstarter. Bytet är oftast väl planerbart: installera PHP-FPM, skapa pooler, ställ om webbservern till FastCGI mot PHP-FPM och ta bort wrapper-skript. Hur en ordentlig uppsättning ser ut visar Säkra Nginx med PHP-FPM. Körs dessutom en gammal PHP-version bör ni förena bytet med uppgraderingen.

Tills bytet är genomfört bör ni granska den befintliga konfigurationen kritiskt. Webbservern bör bara lämna filer med ändelsen .php vidare till php-cgi och inga sökvägar som pekar på filer som inte finns. I uppladdningskataloger får ingen PHP-körning vara möjlig. Wrapper-skript som laddar en egen php.ini per webbplats kontrollerar ni med avseende på om de filerna upphäver de tillfälliga värdena igen. Ligger ett php-cgi-program direkt i en katalog som är nåbar från internet, som cgi-bin, ska det bort därifrån. Sådana arv härrör ofta från installationsanvisningar från svunna år och glöms helt enkelt bort vid senare ombyggnader. Dokumentera varje fynd med sökväg och syfte så att den senare ombyggnaden inte missar något.

Det är fortsatt viktigt: en patch tar inte bort skadlig programvara som fördes in tidigare. Spara loggarna från och med den 20 oktober 2026.

Hur hjälper PHP SOS konkret?

• Vi spårar upp php-cgi-installationer, wrappers och hanterare och kopplar dem till webbplatserna.
• Vi patchar, avslutar alla gamla processer och dokumenterar läget.
• För PHP 8.1 och äldre planerar vi tillsammans med er migreringen till en PHP-version som stöds.
• Inom ramen för serverhärdningen ersätter vi php-cgi med PHP-FPM med separata pooler.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• php.net: versioner som stöds
• BSI