Säkra Apache med mod_php

Kort sagt: Med Apache och mod_php körs PHP direkt i webbservern. PHP-teamet bedömer risken från PHP2Shell som störst just i det driftläget, eftersom en exploit har visats innan någon applikationskod ens körs. Patcha omedelbart, starta om Apache helt och planera därefter bytet till PHP-FPM.

Vad mod_php är och varför det spelar roll nu

Med mod_php laddar Apache PHP som en modul i varje egen arbetsprocess. Varje förfrågan till en PHP-fil körs direkt i den processen. Det var länge standard och är enkelt att sätta upp. Men det innebär också: alla webbplatser på servern körs med samma användare, och PHP delar process med webbservern.

PHP2Shell omfattar sårbarheterna CVE-2026-109618 och CVE-2026-109619, båda med CVSS v4.0 9,2. Vid den andra kan en förfrågans interna tillstånd finnas kvar efter att minnet frigjorts och användas av en senare förfrågan i samma process. För mod_php har PHP-teamet konstaterat den högsta risken. Bakgrund och bedömning finns under Varför mod_php bär den högsta risken.

Känn igen Apache mod_php och kontrollera versionen

Kontrollera först om er Apache över huvud taget använder mod_php. Följande kommandon läser bara. Kommando- och paketnamn skiljer sig mellan distributioner och är exempel.

# Debian/Ubuntu: laddade moduler
apache2ctl -M 2>/dev/null | grep -i php

# RHEL-familjen
httpd -M 2>/dev/null | grep -i php

# Vilken MPM är aktiv? mod_php förutsätter prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Modulens paketstatus (exempel)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

Visas en modul som php_module körs mod_php. Den visade PHP-versionen är ensam inget belägg för patchen, eftersom distributioner ofta levererar rättningar som backport. Åtgärdade versioner från PHP-projektet är 8.5.12, 8.4.27, 8.3.36 och 8.2.35. För distributionspaket gäller ändringsloggen med CVE-numren.

Patcha och starta om Apache helt

Installera uppdateringen via pakethanteringen. Eftersom PHP sitter i Apache-processen måste hela tjänsten därefter startas om. Att läsa om konfigurationen är här inte det säkra sättet.

# Debian/Ubuntu
systemctl restart apache2

# RHEL-familjen
systemctl restart httpd

# Kontroll: starttid för alla Apache-processer
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Alla Apache-processer måste visa en starttid efter uppdateringen. Körs dessutom PHP-FPM eller php-cgi på samma server startar ni om även de tjänsterna.

Tillfälliga åtgärder i Apache-konfigurationen

php.net nämner tillfälliga åtgärder som sänker risken men inte ger något fullständigt skydd. Med mod_php sätter ni värdena med php_admin_value respektive php_admin_flag i Apache-konfigurationen, så att .htaccess och applikationer inte kan skriva över dem.

# Exempel: i VirtualHost- eller den serveromfattande konfigurationen
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

Med uppladdningsfunktion anger php.net post_max_size = 32M, med upload_max_filesize under det värdet. På PHP 8.5 tillkommer fatal_error_backtraces=0. Anvisningen om memory_limit=-1 genomför ni bara tillsammans med en minnesgräns för tjänsten via cgroups, till exempel med MemoryMax i ett systemd-tillägg, inte via RLIMIT_AS eller RLIMIT_DATA. Starta därefter om Apache helt. Alla åtgärder i överblick: Omedelbara åtgärder utan patch.

Vägen bort från mod_php

Efter den akuta patchen lönar sig bytet till PHP-FPM. Då körs PHP i egna processer, skilda från webbservern. Varje webbplats kan få en egen pool med egen användare, gränser kan sättas per pool och omstarter berör bara PHP. Apache kopplar in PHP-FPM via mod_proxy_fcgi och kan då använda en modernare MPM som event i stället för prefork.

Planera bytet i en testmiljö: skapa pooler per webbplats, anpassa filrättigheterna till de nya användarna, överför .htaccess-poster med php_value till poolinställningar och kör belastningstester. Hur en ordentlig uppsättning ser ut visar Säkra Nginx med PHP-FPM; principerna gäller lika för Apache med PHP-FPM.

Oberoende av driftläge gäller: en patch tar inte bort skadlig programvara som redan har förts in. Spara loggarna från och med den 20 oktober 2026 och kontrollera servern med avseende på spår.

Vid spårsökning på mod_php-servrar lönar det sig att titta på den gemensamma användaren. Eftersom alla webbplatser körs under Apache-användaren, till exempel www-data eller apache, kan en angripare som har tagit över en webbplats i regel också läsa och ändra de andras filer. Kontrollera därför inte bara den webbplats som verkar avvikande utan alla dokumentrötter på servern. Var särskilt uppmärksamma på PHP-filer med ungt ändringsdatum i uppladdnings- och cachekataloger, på programkod som ägs av Apache-användaren och på okända poster i den användarens crontab. Hittar ni något säkrar ni först tillståndet och raderar inte förhastat, så att orsaken går att följa upp senare.

Hur hjälper PHP SOS konkret?

• Vi kontrollerar driftläge, MPM och paketstatus och bedömer om er server verkligen är patchad.
• Via PHP-patchtjänsten installerar vi uppdateringen, startar om Apache helt och dokumenterar beläggen.
• Fram till patchen sätter vi de tillfälliga åtgärderna så att de inte kan skrivas över och begränsar minnet på tjänstenivå.
• Inom ramen för serverhärdningen planerar och testar vi bytet till PHP-FPM med separata pooler.

Vanliga frågor

Källor

• php.net: säkerhetsmeddelanden
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets