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.
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 ohjeet pätevät soveltuvin osin.
Mitä mod_php:n käyttäjien tulee nyt tehdä
- Päivittäkää PHP-moduuli versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai jakelunne vahvistamaan backportiin.
- Käynnistäkää Apache kokonaan uudelleen, älkää vain lataako asetuksia uudelleen. mod_php:ssä vanha PHP-koodi on jokaisessa Apache-prosessissa.
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
- Asettakaa väliaikaiset toimenpiteet, jos päivitys ei vielä onnistu. php.net mainitsee muun muassa kiinteät rajat, joita sovellukset eivät voi ylikirjoittaa:
# 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. Jos kumpikaan ei onnistu heti, BSI suosittelee ottamaan verkkopalvelimen tilapäisesti pois verkosta.
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.
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 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 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.