php-cgi: gammel arv med risiko

Kort sagt: php-cgi er den ældste måde at drive PHP bag en webserver på og kører stadig på mange servere, ofte upåagtet. php-cgi-sårbarheden fra PHP2Shell berører udtrykkeligt denne driftsform. Patch, afslut alle kørende php-cgi-processer, og planlæg skiftet til PHP-FPM.

Hvad php-cgi er, og hvor det stadig kører

PHP findes i flere varianter: som kommandolinjeprogram, som Apache-modul, som PHP-FPM og som php-cgi. php-cgi er et program, som webserveren starter, og som den overdrager forespørgsler til via CGI eller FastCGI. Uden egen procesadministration er det enklere end PHP-FPM, men også sværere at styre.

Typiske fundsteder er ældre hostingpaneler, Apache med mod_fcgid, egne wrapper-scripts til flere PHP-versioner og PHP under Windows med IIS via FastCGI. I bureauer og myndigheder findes desuden servere, som blev sat op for år siden og siden da blot er blevet drevet videre.

php-cgi-sårbarheden ved PHP2Shell

PHP2Shell omfatter sårbarhederne CVE-2026-109618 og CVE-2026-109619 i PHP selv, hver med CVSS v4.0 9,2. Begge tillader udførelse af skadelig kode uden login. PHP-projektet nævner udtrykkeligt php-cgi blandt de berørte driftsformer, ved siden af PHP-FPM, mod_php, FrankenPHP og LiteSpeed.

Rettet er PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. For PHP 8.1 og ældre findes der ikke længere officielle opdateringer, kun minimale kilde-backports til 7.4, 8.0 og 8.1. Netop php-cgi-opsætninger kører over gennemsnittet ofte på gamle versioner. php-cgi er desuden ikke berørt for første gang: Allerede i 2024 vakte en sårbarhed i php-cgi under Windows (CVE-2024-4577) opsigt. Gammel arv af denne slags fortjener derfor særlig opmærksomhed.

Find php-cgi på serveren

Følgende kommandoer læser kun og hjælper med at opspore php-cgi. Stier og modulnavne er eksempler.

# Kørende php-cgi-processer med starttidspunkt og bruger
ps -eo pid,lstart,user,cmd | grep -E 'php-cgi|php[0-9.]*-cgi' | grep -v grep

# Installerede php-cgi-programmer
ls /usr/bin/php*-cgi /usr/lib/cgi-bin/php* 2>/dev/null

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

Finder I FcgidWrapper-poster eller handlere, der peger på et php-cgi-program, kører denne driftsform. Kontrollér for hvert fundet program versionen med -v. Ved distributionspakker dokumenterer ændringsloggen med CVE-numrene patchen, fordi backports ofte ikke ændrer versionsnummeret.

Patch og afslut alle processer

Indspil opdateringen via pakkehåndteringen eller den kilde, php-cgi stammer fra. Bagefter skal alle kørende php-cgi-processer forsvinde. Ved mod_fcgid holder Apache processer i beredskab et stykke tid; en fuldstændig genstart af Apache afslutter dem.

# Genstart Apache fuldstændigt (Debian/Ubuntu henholdsvis RHEL-familien)
systemctl restart apache2   # eller: systemctl restart httpd

# Kontrol: Findes der stadig php-cgi-processer ældre end opdateringen?
ps -eo pid,lstart,cmd | grep -E 'php-cgi' | grep -v grep

Kører php-cgi via en egen procesadministrator eller en panel-tjeneste, genstarter I denne. Under Windows med IIS genbruger I applikationspoolene, se PHP under Windows og IIS.

Midlertidige foranstaltninger ved php-cgi

php.net anbefaler midlertidige foranstaltninger, som ikke giver fuldstændig beskyttelse. Ved php-cgi hører værdierne hjemme i den php.ini, som det pågældende program indlæser, eller i serverkonfigurationen. .user.ini-filer og ini_set() er ifølge php.net ikke nok for session.upload_progress.enabled.

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

Med upload-funktion angiver php.net post_max_size = 32M. På PHP 8.5 kommer fatal_error_backtraces=0 til. Hukommelsesgrænser sætter I via cgroups for webserver-tjenesten, ikke via RLIMIT_AS eller RLIMIT_DATA. Genstart derefter alle processer.

Vejen til PHP-FPM

På længere sigt er php-cgi intet godt valg. PHP-FPM tilbyder pools pr. website, egne brugere, grænser pr. pool, statussider og kontrollerede genstarter. Skiftet kan som regel planlægges godt: installér PHP-FPM, opret pools, omstil webserveren til FastCGI mod PHP-FPM, fjern wrapper-scripts. Hvordan en ren opbygning ser ud, viser Sådan sikrer I Nginx med PHP-FPM. Kører der desuden en gammel PHP-version, så forbind skiftet med opgraderingen.

Indtil skiftet er sket, bør I gennemgå den bestående konfiguration kritisk. Webserveren bør kun overdrage filer med endelsen .php til php-cgi og ingen stier, der peger på ikke-eksisterende filer. I upload-mapper må der ikke være mulighed for PHP-udførelse. Wrapper-scripts, der indlæser en egen php.ini pr. website, bør I kontrollere for, om disse filer ophæver de midlertidige værdier igen. Ligger et php-cgi-program direkte i en offentligt tilgængelig mappe som cgi-bin, skal det fjernes dér. Sådan gammel arv stammer ofte fra installationsvejledninger fra svundne år og bliver ved senere ombygninger simpelthen glemt. Dokumenter hvert fund med sti og formål, så den senere ombygning intet overser.

Fortsat vigtigt: En patch fjerner ikke skadelig software, som blev smuglet ind tidligere. Gem logs fra og med 20.10.2026.

Hvordan hjælper PHP SOS konkret?

• Vi opsporer php-cgi-installationer, wrappere og handlere og tildeler dem til websites.
• Vi patcher, afslutter alle gamle processer og dokumenterer statussen.
• For PHP 8.1 og ældre planlægger vi sammen med jer migreringen til en understøttet PHP-version.
• Som led i serverhærdningen erstatter vi php-cgi med PHP-FPM med adskilte pools.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• php.net: Understøttede versioner
• BSI