# Hvorfor mod_php bærer den højeste risiko

> Hvorfor PHP-teamet vurderer risikoen ved PHP2Shell som højest for Apache med mod_php, hvordan I genkender mod_php, og hvad I nu skal rette og omstille.

Kilde: https://phpsos.de/da/php2shell/mod-php-risiko/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Af PHP2Shell er alle gængse driftsformer berørt, men ved Apache med mod_php vurderer PHP-teamet risikoen som højest. Dér er der vist en exploit, før applikationskode overhovedet kører. Den, der driver mod_php, bør først opdatere PHP og genstarte Apache fuldstændigt.

## Hvad er mod_php?

Ved mod_php er PHP et modul inde i Apache-webserveren. Hver Apache-proces indeholder en fuldstændig PHP-fortolker og udfører PHP-kode direkte. Denne driftsform var længe standard og er stadig udbredt på ældre servere, i mange distributionspakker og i nogle Docker-images.

Alternativet er PHP-FPM: Dér kører PHP som en selvstændig tjeneste med egne processer, og Apache eller Nginx sender kun forespørgsler videre. Begge varianter er berørt af PHP2Shell, ligeledes php-cgi, FrankenPHP og LiteSpeed.

Typiske miljøer med mod_php er ældre rootservere, som har kørt uændret i årevis, standardinstallationer af Apache fra distributionspakker og Docker-images med Apache og PHP i én container. Den, der ikke ved sikkert, hvilken driftsform ens server bruger, bør kontrollere det i stedet for at antage det.

## Hvorfor regnes mod_php-sårbarheden som særligt risikabel?

PHP-teamet har afgivet en klar vurdering af PHP2Shell: Ved mod_php er risikoen højest. Begrundelse: Dér er der vist en exploit, som virker, før applikationskode overhovedet kører.

For driftsansvarlige har det en ubehagelig konsekvens. Mange beskyttelsesforanstaltninger sidder i applikationen: sikkerheds-plugins i WordPress, firewallmoduler i webshops, kontroller i egen kode. De er alle applikationskode. Hvis udnyttelsen sker før dem, kommer de for sent.

Hertil kommer den tætte sammenkædning: Ved mod_php deler PHP proces med Apache. Det, der kompromitterer PHP, kører med webserverens rettigheder og i dens hukommelse. Ved PHP-FPM kan pools derimod adskilles med egne brugere pr. website, hvilket kan begrænse følgerne af et indbrud.

For prioriteringen betyder det: Driver I flere servere, kommer dem med mod_php først, og ved dem er en efterfølgende kontrol for spor særligt vigtig.

Hvad vi ikke ved: hvor mange af de på verdensplan talte 22,6 millioner eksponerede, potentielt sårbare instanser der bruger mod_php. Pålidelige tal herom er ikke offentliggjort.

## Bruger min server mod_php?

De følgende kommandoer er rent læsende. Tjeneste- og kommandonavne afviger fra distribution til distribution: Debian og Ubuntu bruger `apache2`, RHEL-familien `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # f.eks. 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, modulets pakkestatus
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # RHEL-familien
```

Dukker der intet PHP-modul op, bruger Apache sandsynligvis PHP-FPM via `proxy_fcgi`. Så gælder henvisningerne under [Sikr Nginx med PHP-FPM](https://phpsos.de/da/server/nginx-php-fpm/) tilsvarende.

## Hvad mod_php-operatører nu bør gøre

1. **Opdatere PHP-modulet** til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 eller en bekræftet backport fra jeres distribution.
2. **Genstarte Apache fuldstændigt,** ikke kun genindlæse. Ved mod_php sidder den gamle PHP-kode i hver Apache-proces.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # RHEL-familien
ps -o pid,lstart,cmd -C apache2    # kontrollér starttidspunktet, under RHEL: -C httpd
```

3. **Sætte midlertidige foranstaltninger, hvis opdateringen endnu ikke er mulig.** php.net nævner bl.a. faste grænser, som applikationer ikke kan overskrive:

```apache
# Serverkonfiguration eller VirtualHost, ikke .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ører en hukommelsesgrænse via cgroup med, ikke via `RLIMIT_AS` eller `RLIMIT_DATA`. Disse foranstaltninger er ingen fuld beskyttelse; detaljerne står under [Akutforanstaltninger, hvis I endnu ikke kan rette](https://phpsos.de/da/php2shell/sofortmassnahmen-ohne-patch/). Hvis ingen af delene er mulige med det samme, anbefaler BSI midlertidigt at tage webserveren af nettet.

> **Handl med det samme:**
> Hvis jeres Apache med mod_php mellem den 17. oktober og rettelsen kørte ubeskyttet på internettet, så sikr logs fra og med 20. oktober og lad serveren kontrollere for spor. Rettelsen alene beviser ikke, at der intet skete.

## På mellemlang sigt: væk fra mod_php

Efter rettelsen er det værd at se på arkitekturen. Skiftet til PHP-FPM med Apache `mpm_event` og `proxy_fcgi` eller med Nginx adskiller PHP fra webserveren, tillader egne pools og brugere pr. website og gør genstarter og versionsskift lettere. Det lukker ikke PHP2Shell, men mindsker angrebsfladen for fremtidige sårbarheder.

Omstillingen kræver planlægning. Indstillinger, der hidtil blev sat med `php_value` i `.htaccess`, virker ikke længere under PHP-FPM og skal flyttes til poolen. Brugere og rettigheder ændrer sig, upload- og cachemapper har måske brug for nye tilladelser. I et testmiljø er det let at håndtere, i den løbende drift under tidspres er det ikke. Henvisninger om omstillingen finder I under [Sikr Apache med mod_php](https://phpsos.de/da/server/apache-mod-php/).

## Hvordan hjælper PHP SOS konkret?

- **Genkende:** Vi kontrollerer, hvilke servere der bruger mod_php, og fra hvilken pakkekilde modulet stammer.
- **Rette og genstarte:** Via [PHP-patch-servicen](https://phpsos.de/da/leistungen/php-patch-service/) indspiller vi opdateringen og kontrollerer, at ingen gammel Apache-proces kører længere.
- **Sikre overgangen:** Hvor opdateringen er blokeret, sætter vi foranstaltningerne fra php.net i serverkonfigurationen.
- **Omstille:** Som led i [serverhærdningen](https://phpsos.de/da/leistungen/server-haertung/) planlægger og tester vi skiftet til PHP-FPM med adskilte pools.


## Ofte stillede spørgsmål

**Hvordan kan jeg se, om min Apache bruger mod_php?**  
Med apachectl -M eller httpd -M ser I de indlæste moduler. Står der et modul som php_module eller php8_module, kører PHP direkte i Apache. Under Debian og Ubuntu viser også a2query -m, om et php-modul er aktivt.

**Beskytter et sikkerheds-plugin i WordPress mig ved mod_php?**  
Ved denne sårbarhed nej. Ifølge PHP-teamet er der ved mod_php vist en exploit, før applikationskode overhovedet kører. Et plugin er applikationskode og kommer dermed for sent. Beskyttelse giver kun PHP-opdateringen med genstart af Apache.

**Bør jeg nu skifte fra mod_php til PHP-FPM?**  
Først rette, så omstille. Skiftet til PHP-FPM er for de fleste opsætninger fornuftigt på mellemlang sigt, fordi PHP så kører adskilt fra webserveren. Det lukker dog ikke PHP2Shell, for PHP-FPM er ligeledes berørt.

## Kilder

- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: det tyske forbundsagentur for informationssikkerhed](https://www.bsi.bund.de/)