# Miksi mod_php kantaa suurimman riskin

> Miksi PHP-tiimi arvioi PHP2Shellin riskin suurimmaksi Apachella ja mod_php:llä, miten tunnistatte mod_php:n ja mitä korjaatte ja vaihdatte nyt.

Lähde: https://phpsos.de/fi/php2shell/mod-php-risiko/  
Tilanne: 25.10.2026  
Palveluntarjoaja: PHP SOS, PHP-hätäapu ja palvelimen tietoturva. Pikaapu WhatsAppilla: https://wa.me/491736494914?text=Hei%20PHP%20SOS%2C%20tarvitsemme%20apua%20PHP-palvelimemme%20kanssa.%20Yritys%3A%20%E2%80%A6%20Verkkosivusto%3A%20%E2%80%A6

**Lyhyesti:** PHP2Shell koskee kaikkia yleisiä ajotapoja, mutta Apachella ja mod_php:llä PHP-tiimi arvioi riskin suurimmaksi. Siinä on esitetty hyökkäys ennen kuin sovelluskoodia ajetaan lainkaan. Joka käyttää mod_php:tä, kannattaa päivittää PHP ensin ja käynnistää Apache kokonaan uudelleen.

## Mikä on mod_php?

mod_php:ssä PHP on moduuli Apache-verkkopalvelimen sisällä. Jokainen Apache-prosessi sisältää täydellisen PHP-tulkin ja suorittaa PHP-koodin suoraan. Tämä ajotapa oli pitkään oletus, ja se on yhä yleinen vanhemmilla palvelimilla, monissa jakelupaketeissa ja joissakin Docker-imageissa.

Vaihtoehto on PHP-FPM: siinä PHP toimii omana palvelunaan omine prosesseineen, ja Apache tai Nginx vain välittää pyynnöt. Molemmat vaihtoehdot ovat PHP2Shellin kohteena, samoin php-cgi, FrankenPHP ja LiteSpeed.

Tyypillisiä mod_php-ympäristöjä ovat vanhemmat root-palvelimet, jotka ovat toimineet vuosia muuttumattomina, Apachen vakioasennukset jakelupaketeista ja Docker-imaget, joissa Apache ja PHP ovat samassa kontissa. Joka ei tiedä varmasti, mitä ajotapaa palvelin käyttää, kannattaa tarkistaa se oletuksen sijaan.

## Miksi mod_php-haavoittuvuus katsotaan erityisen riskialttiiksi?

PHP-tiimi on antanut PHP2Shellistä selkeän arvion: mod_php:ssä riski on suurin. Perustelu: siinä on esitetty hyökkäys, joka tehoaa ennen kuin sovelluskoodia ajetaan lainkaan.

Ylläpitäjille tästä seuraa epämukava johtopäätös. Moni suojatoimi on sovelluksessa: tietoturvalisäosat WordPressissä, palomuurimoduulit verkkokaupoissa, tarkistukset omassa koodissa. Ne kaikki ovat sovelluskoodia. Jos hyödyntäminen tapahtuu ennen niitä, ne tulevat liian myöhään.

Lisäksi on tiivis kytkentä: mod_php:ssä PHP jakaa prosessin Apachen kanssa. Mikä PHP:n vaarantaa, toimii verkkopalvelimen oikeuksilla ja sen muistissa. PHP-FPM:ssä poolit voi sen sijaan erottaa omilla käyttäjillä verkkosivustoittain, mikä voi rajoittaa murron seurauksia.

Priorisoinnin kannalta tämä tarkoittaa: jos ylläpidätte useita palvelimia, mod_php:tä käyttävät tulevat ensin, ja niillä jälkien tarkistus jälkikäteen on erityisen tärkeää.

Mitä emme tiedä: kuinka moni maailmanlaajuisesti lasketuista 22,6 miljoonasta julkisesti tavoitettavissa olevasta, mahdollisesti haavoittuvasta instanssista käyttää mod_php:tä. Luotettavia lukuja siitä ei ole julkaistu.

## Käyttääkö palvelimeni mod_php:tä?

Seuraavat komennot ovat pelkästään lukevia. Palvelu- ja komentonimet vaihtelevat jakelun mukaan: Debian ja Ubuntu käyttävät nimeä `apache2`, RHEL-perhe nimeä `httpd`.

```bash
apachectl -M 2>/dev/null | grep -i php     # esim. php_module tai 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, moduulin paketin tila
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619"   # RHEL-perhe
```

Jos mitään PHP-moduulia ei näy, Apache käyttää todennäköisesti PHP-FPM:ää `proxy_fcgi`:n kautta. Silloin sivun [Nginx PHP-FPM:n kanssa turvalliseksi](https://phpsos.de/fi/server/nginx-php-fpm/) ohjeet pätevät soveltuvin osin.

## Mitä mod_php:n käyttäjien tulee nyt tehdä

1. **Päivittäkää PHP-moduuli** versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai jakelunne vahvistamaan backportiin.
2. **Käynnistäkää Apache kokonaan uudelleen,** älkää vain lataako asetuksia uudelleen. mod_php:ssä vanha PHP-koodi on jokaisessa Apache-prosessissa.

```bash
sudo systemctl restart apache2     # Debian/Ubuntu
sudo systemctl restart httpd       # RHEL-perhe
ps -o pid,lstart,cmd -C apache2    # tarkista käynnistysaika, RHEL:ssä: -C httpd
```

3. **Asettakaa väliaikaiset toimenpiteet, jos päivitys ei vielä onnistu.** php.net mainitsee muun muassa kiinteät rajat, joita sovellukset eivät voi ylikirjoittaa:

```apache
# Palvelimen konfiguraatio tai VirtualHost, ei .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
```

Asetuksen `memory_limit=-1` kanssa mukaan kuuluu muistiraja cgroupin kautta, ei `RLIMIT_AS`- tai `RLIMIT_DATA`-rajoilla. Nämä toimenpiteet eivät ole täysi suoja; yksityiskohdat löytyvät sivulta [Pikatoimet, jos ette voi vielä korjata](https://phpsos.de/fi/php2shell/sofortmassnahmen-ohne-patch/). Jos kumpikaan ei onnistu heti, BSI suosittelee ottamaan verkkopalvelimen tilapäisesti pois verkosta.

> **Toimi heti:**
> Jos Apachenne mod_php:n kanssa oli suojaamattomana verkossa 17. lokakuuta ja korjauksen välisenä aikana, turvatkaa lokit 20. lokakuuta alkaen ja tarkistuttakaa palvelin jälkien varalta. Korjaus yksin ei todista, ettei mitään ole tapahtunut.

## Keskipitkällä aikavälillä: pois mod_php:stä

Korjauksen jälkeen kannattaa katsoa arkkitehtuuria. Siirtyminen PHP-FPM:ään Apachen `mpm_event`:n ja `proxy_fcgi`:n tai Nginxin kanssa erottaa PHP:n verkkopalvelimesta, sallii omat poolit ja käyttäjät verkkosivustoittain ja helpottaa uudelleenkäynnistyksiä ja versionvaihtoja. Se ei sulje PHP2Shelliä, mutta pienentää tulevien haavoittuvuuksien hyökkäyspinta-alaa.

Siirtymä vaatii suunnittelua. Asetukset, jotka on tähän asti asetettu `php_value`:lla tiedostossa `.htaccess`, eivät toimi PHP-FPM:ssä ja ne on siirrettävä pooliin. Käyttäjät ja oikeudet muuttuvat, lataus- ja välimuistihakemistot saattavat tarvita uusia oikeuksia. Testiympäristössä tämä on hyvin hallittavissa, mutta ei käynnissä olevassa toiminnassa kiireessä. Vihjeitä siirtymään löydätte sivulta [Apache mod_php:n kanssa turvalliseksi](https://phpsos.de/fi/server/apache-mod-php/).

## Miten PHP SOS auttaa konkreettisesti?

- **Tunnistaminen:** Tarkistamme, mitkä palvelimet käyttävät mod_php:tä ja mistä pakettilähteestä moduuli tulee.
- **Korjaus ja uudelleenkäynnistys:** [PHP-korjauspalvelun](https://phpsos.de/fi/leistungen/php-patch-service/) kautta asennamme päivityksen ja tarkistamme, ettei vanhoja Apache-prosesseja ole enää käynnissä.
- **Ylimenon turvaaminen:** Kun päivitys on estetty, asetamme php.netin toimenpiteet palvelimen konfiguraatioon.
- **Siirtymä:** [Palvelimen koventamisen](https://phpsos.de/fi/leistungen/server-haertung/) yhteydessä suunnittelemme ja testaamme vaihdon PHP-FPM:ään erillisin poolein.


## Usein kysytyt kysymykset

**Mistä tunnistan, käyttääkö Apacheni mod_php:tä?**  
Komennolla apachectl -M tai httpd -M näette ladatut moduulit. Jos siellä on moduuli kuten php_module tai php8_module, PHP toimii suoraan Apachessa. Debianissa ja Ubuntussa myös a2query -m näyttää, onko php-moduuli aktiivinen.

**Suojaako WordPressin tietoturvalisäosa mod_php:n kanssa?**  
Tämän haavoittuvuuden osalta ei. PHP-tiimin mukaan mod_php:ssä on esitetty hyökkäys ennen kuin sovelluskoodia ajetaan lainkaan. Lisäosa on sovelluskoodia ja tulee siten liian myöhään. Suojan antaa vain PHP-päivitys ja Apachen uudelleenkäynnistys.

**Pitäisikö minun nyt siirtyä mod_php:stä PHP-FPM:ään?**  
Ensin korjaus, sitten siirtymä. Vaihto PHP-FPM:ään on useimmissa ympäristöissä keskipitkällä aikavälillä järkevä, koska PHP toimii silloin erillään verkkopalvelimesta. Se ei kuitenkaan sulje PHP2Shelliä, sillä myös PHP-FPM on haavoittuva.

## Lähteet

- [php.net: tietoturvatiedotteet](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Saksan liittovaltion tietoturvavirasto](https://www.bsi.bund.de/)