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

> Varför PHP-teamet bedömer risken från PHP2Shell som högst vid Apache med mod_php, hur ni känner igen mod_php och vad ni nu bör patcha och ställa om.

Källa: https://phpsos.de/sv/php2shell/mod-php-risiko/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**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`.

```bash
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](https://phpsos.de/sv/server/nginx-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.

```bash
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:

```apache
# 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](https://phpsos.de/sv/php2shell/sofortmassnahmen-ohne-patch/). Går inget av det genast rekommenderar BSI att tillfälligt ta webbservern från nätet.

> **Agera direkt:**
> Om er Apache med mod_php låg oskyddad på internet mellan den 17 oktober och patchen: säkra loggarna från och med den 20 oktober och låt servern kontrolleras efter spår. Patchen ensam bevisar inte att inget har hänt.

## 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](https://phpsos.de/sv/server/apache-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](https://phpsos.de/sv/leistungen/php-patch-service/) 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](https://phpsos.de/sv/leistungen/server-haertung/) planerar och testar vi bytet till PHP-FPM med skilda pooler.


## Vanliga frågor

**Hur ser jag om min Apache använder mod_php?**  
Med apachectl -M eller httpd -M ser ni de inlästa modulerna. Står där en modul som php_module eller php8_module körs PHP direkt i Apache. På Debian och Ubuntu visar också a2query -m om en php-modul är aktiv.

**Skyddar ett säkerhetsplugin i WordPress mig vid mod_php?**  
Vid den här sårbarheten inte. Enligt PHP-teamet visades vid mod_php en exploit innan någon applikationskod ens körs. Ett plugin är applikationskod och kommer därmed för sent. Skydd ger bara PHP-uppdateringen med omstart av Apache.

**Bör jag nu byta från mod_php till PHP-FPM?**  
Patcha först, ställ sedan om. Bytet till PHP-FPM är på medellång sikt meningsfullt för de flesta miljöer, eftersom PHP då körs skilt från webbservern. Det stänger dock inte PHP2Shell, eftersom PHP-FPM också är berört.

## Källor

- [php.net: säkerhetsmeddelanden](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Tysklands federala myndighet för informationssäkerhet](https://www.bsi.bund.de/)