Varför mod_php bär den högsta risken

Kort sagt: Av PHP2Shell berörs alla gängse driftlägen, men vid Apache med mod_php bedömer PHP-teamet risken som högst. Där visades en exploit innan någon applikationskod ens körs. Den som driver mod_php bör först uppdatera PHP och starta om Apache fullständigt.

Vad är mod_php?

Vid mod_php är PHP en modul inne i webbservern Apache. Varje Apache-process innehåller en fullständig PHP-tolk och kör PHP-kod direkt. Det här driftläget var länge standard och är fortfarande utbrett på äldre servrar, i många distributionspaket och i vissa Docker-images.

Alternativet är PHP-FPM: Där körs PHP som en egen tjänst med egna processer, och Apache eller Nginx lämnar bara förfrågningar vidare. Båda varianterna berörs av PHP2Shell, liksom php-cgi, FrankenPHP och LiteSpeed.

Typiska miljöer med mod_php är äldre root-servrar som har körts oförändrade i flera år, standardinstallationer av Apache från distributionspaket och Docker-images med Apache och PHP i en container. Den som inte säkert vet vilket driftläge servern använder bör kontrollera det i stället för att anta.

Varför räknas mod_php-sårbarheten som särskilt riskfylld?

PHP-teamet har gjort en tydlig bedömning av PHP2Shell: Vid mod_php är risken högst. Motivering: Där visades en exploit som verkar innan någon applikationskod ens körs.

För driftansvariga får det en obekväm konsekvens. Många skyddsåtgärder finns i applikationen: säkerhetsplugins i WordPress, brandväggsmoduler i butiker, kontroller i den egna koden. Alla är de applikationskod. Om utnyttjandet sker före dem kommer de för sent.

Dessutom kommer den täta sammankopplingen: Vid mod_php delar PHP process med Apache. Det som komprometterar PHP körs med webbserverns rättigheter och i dess minne. Vid PHP-FPM kan pooler däremot skiljas åt med egna användare per webbplats, vilket kan begränsa följderna av ett intrång.

För prioriteringen betyder det: Driver ni flera servrar kommer de med mod_php först i tur, och för dem är en efterföljande kontroll av spår särskilt viktig.

Vad vi inte vet: hur många av de världen över räknade 22,6 miljoner exponerade, potentiellt sårbara instanserna som använder mod_php. Tillförlitliga siffror om det har inte publicerats.

Använder min server mod_php?

Följande kommandon är rent läsande. Tjänst- och kommandonamn skiljer sig mellan distributioner: Debian och Ubuntu använder apache2, RHEL-familjen httpd.

apachectl -M 2>/dev/null | grep -i php     # t.ex. php_module eller php8_module
httpd -M 2>/dev/null | grep -i php         # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php                   # Debian/Ubuntu
apt policy libapache2-mod-php8.3           # Debian/Ubuntu, modulens paketstatus
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # RHEL-familjen

Dyker ingen PHP-modul upp använder Apache sannolikt PHP-FPM via proxy_fcgi. Då gäller anvisningarna under Säkra Nginx med PHP-FPM i tillämpliga delar.

Vad driftansvariga av mod_php bör göra nu

1. Uppdatera PHP-modulen till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en bekräftad backport från er distribution.
2. Starta om Apache fullständigt, inte bara ladda om. Vid mod_php sitter den gamla PHP-koden i varje Apache-process.

sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # RHEL-familjen
ps -o pid,lstart,cmd -C apache2    # kontrollera starttiden, under RHEL: -C httpd

3. Sätt övergångsåtgärder om uppdateringen ännu inte går. php.net anger bland annat fasta gränser som applikationer inte kan skriva över:

# serverkonfiguration eller VirtualHost, inte .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off

Med memory_limit=-1 hör en minnesgräns via cgroup till, inte via RLIMIT_AS eller RLIMIT_DATA. Dessa åtgärder är inget fullständigt skydd; detaljerna står under Akutåtgärder om ni ännu inte kan patcha. Går inget av det genast rekommenderar BSI att tillfälligt ta webbservern från nätet.

På medellång sikt: bort från mod_php

Efter patchen lönar det sig att titta på arkitekturen. Övergången till PHP-FPM med Apache mpm_event och proxy_fcgi eller med Nginx skiljer PHP från webbservern, möjliggör egna pooler och användare per webbplats och gör omstarter och versionsbyten enklare. Den stänger inte PHP2Shell, men minskar angreppsytan för framtida sårbarheter.

Omställningen kräver planering. Inställningar som hittills sattes med php_value i .htaccess verkar inte längre under PHP-FPM och måste flyttas till poolen. Användare och rättigheter ändras, uppladdnings- och cachekataloger behöver eventuellt nya behörigheter. I en testmiljö är det väl hanterbart, i skarp drift under tidspress inte. Anvisningar om omställningen finns under Säkra Apache med mod_php.

Hur hjälper PHP SOS konkret?

• Upptäcka: Vi kontrollerar vilka servrar som använder mod_php och från vilken paketkälla modulen kommer.
• Patcha och starta om: Via PHP-patchtjänsten installerar vi uppdateringen och kontrollerar att ingen gammal Apache-process längre körs.
• Skydda övergången: Där uppdateringen är blockerad sätter vi åtgärderna från php.net i serverkonfigurationen.
• Ställa om: Inom ramen för serverhärdningen planerar och testar vi bytet till PHP-FPM med skilda pooler.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• BSI: Tysklands federala myndighet för informationssäkerhet