Sådan sikrer I Apache med mod_php

Kort sagt: Ved Apache med mod_php kører PHP direkte i webserveren. PHP-teamet vurderer risikoen ved PHP2Shell netop i denne driftsform som højest, fordi der er vist en exploit, før applikationskode overhovedet kører. Patch med det samme, genstart Apache fuldstændigt, og planlæg derefter skiftet til PHP-FPM.

Hvad mod_php er, og hvorfor det tæller nu

Ved mod_php indlæser Apache PHP som modul i hver sin arbejdsproces. Hver forespørgsel til en PHP-fil udføres direkte i denne proces. Det var længe standarden og er enkelt at sætte op. Men det betyder også: Alle websites på serveren kører under samme bruger, og PHP deler proces med webserveren.

PHP2Shell omfatter sårbarhederne CVE-2026-109618 og CVE-2026-109619, begge med CVSS v4.0 9,2. Ved den anden kan en forespørgsels interne tilstand efter frigivelse af hukommelsen blive stående og udnyttes af en senere forespørgsel i samme proces. For mod_php har PHP-teamet fastslået den højeste risiko. Baggrund og vurdering står under Hvorfor mod_php bærer den højeste risiko.

Genkend Apache mod_php og kontrollér versionen

Kontrollér først, om jeres Apache overhovedet bruger mod_php. Følgende kommandoer læser kun. Kommando- og pakkenavne er forskellige fra distribution til distribution og er eksempler.

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

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

# Hvilket MPM er aktivt? mod_php kræver prefork
apache2ctl -V 2>/dev/null | grep -i mpm

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

Vises et modul som php_module, kører mod_php. Den viste PHP-version alene er intet bevis for patchen, fordi distributioner ofte indspiller rettelser som backport. Rettede versioner fra PHP-projektet er 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Ved distributionspakker tæller ændringsloggen med CVE-numrene.

Patch og genstart Apache fuldstændigt

Indspil opdateringen via pakkehåndteringen. Fordi PHP sidder i Apache-processen, må hele tjenesten genstartes bagefter. En genindlæsning af konfigurationen er her ikke den sikre vej.

# Debian/Ubuntu
systemctl restart apache2

# RHEL-familien
systemctl restart httpd

# Kontrol: starttidspunkt for alle Apache-processer
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

Alle Apache-processer skal vise et starttidspunkt efter opdateringen. Kører der på samme server desuden PHP-FPM eller php-cgi, så genstart også disse tjenester.

Midlertidige foranstaltninger i Apache-konfigurationen

php.net nævner midlertidige foranstaltninger, som sænker risikoen, men ikke giver fuldstændig beskyttelse. Ved mod_php sætter I værdierne med php_admin_value henholdsvis php_admin_flag i Apache-konfigurationen, så .htaccess og applikationer ikke kan overskrive dem.

# Eksempel: i VirtualHost- eller den serverdækkende konfiguration
<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 upload-funktion angiver php.net post_max_size = 32M, og upload_max_filesize skal ligge under. På PHP 8.5 kommer fatal_error_backtraces=0 til. Anvisningen om memory_limit=-1 gennemfører I kun sammen med en hukommelsesgrænse for tjenesten via cgroups, f.eks. med MemoryMax i et systemd-tillæg, ikke via RLIMIT_AS eller RLIMIT_DATA. Derefter genstartes Apache fuldstændigt. Alle foranstaltninger i overblik: Akutforanstaltninger uden patch.

Vejen væk fra mod_php

Efter den akutte patch kan det betale sig at skifte til PHP-FPM. Her kører PHP i egne processer, adskilt fra webserveren. Hvert website kan få en egen pool med egen bruger, grænser kan sættes pr. pool, og genstarter berører kun PHP. Apache tilkobler PHP-FPM via mod_proxy_fcgi og kan så i stedet for prefork bruge et mere moderne MPM som event.

Planlæg skiftet i et testmiljø: opret pools pr. website, tilpas filrettigheder til de nye brugere, overfør .htaccess-poster med php_value til pool-indstillinger, kør belastningstests. Hvordan en ren opbygning ser ud, viser Sådan sikrer I Nginx med PHP-FPM; principperne gælder for Apache med PHP-FPM på samme måde.

Uanset driftsform gælder: En patch fjerner ikke skadelig software, der allerede er smuglet ind. Gem logs fra og med 20.10.2026, og undersøg serveren for spor.

Ved sporsøgningen på mod_php-servere er det værd at se på den fælles bruger. Fordi alle websites kører under Apache-brugeren, f.eks. www-data eller apache, kan en angriber, der har overtaget ét website, som regel også læse og ændre de andres filer. Undersøg derfor ikke kun det website, der forekommer jer påfaldende, men alle document roots på serveren. Vær især opmærksom på PHP-filer med ung ændringsdato i upload- og cache-mapper, på programkode, der ejes af Apache-brugeren, og på ukendte poster i denne brugers crontab. Finder I noget, så sikr først tilstanden, og slet ikke for hurtigt, så årsagen senere kan spores.

Hvordan hjælper PHP SOS konkret?

• Vi kontrollerer driftsform, MPM og pakkestatus og vurderer, om jeres server faktisk er patchet.
• Via PHP-patch-servicen indspiller vi opdateringen, genstarter Apache fuldstændigt og dokumenterer beviset.
• Indtil patchen er på plads, sætter vi de midlertidige foranstaltninger, så de ikke kan overskrives, og begrænser hukommelsen på tjenesteniveau.
• Som led i serverhærdningen planlægger og tester vi skiftet til PHP-FPM med adskilte pools.

Ofte stillede spørgsmål

Kilder

• php.net: Sikkerhedsmeddelelser
• PHP 8 ChangeLog
• BSI
• OWASP Cheat Sheets