Röviden: A PHP2Shell az összes szokásos üzemmódot érinti, de az Apache mod_php-nál a PHP-csapat a legmagasabbra értékeli a kockázatot. Ott exploitot mutattak be, még mielőtt az alkalmazáskód egyáltalán futna. Aki mod_php-t üzemeltet, először frissítse a PHP-t, és teljesen indítsa újra az Apache-ot.
Mi a mod_php?
A mod_php esetében a PHP egy modul az Apache webszerveren belül. Minden Apache-folyamat tartalmaz egy teljes PHP-értelmezőt, és közvetlenül futtatja a PHP-kódot. Ez az üzemmód sokáig az alapértelmezett volt, és régebbi szervereken, sok disztribúciós csomagban és egyes Docker-image-ekben a mai napig elterjedt.
Az alternatíva a PHP-FPM: ott a PHP önálló szolgáltatásként, saját folyamatokkal fut, az Apache vagy az Nginx pedig csak továbbítja a kéréseket. Mindkét változatot érinti a PHP2Shell, ahogy a php-cgi-t, a FrankenPHP-t és a LiteSpeedet is.
A mod_php tipikus környezetei az évek óta változatlanul futó régebbi root szerverek, az Apache szabványos telepítései disztribúciós csomagokból, és az Apache-ot és PHP-t egy konténerben egyesítő Docker-image-ek. Aki nem tudja biztosan, hogy a szervere melyik üzemmódot használja, ellenőrizze, ne feltételezze.
Miért számít különösen kockázatosnak a mod_php biztonsági rése?
A PHP-csapat a PHP2Shell kapcsán világos értékelést adott: a mod_php esetében a kockázat a legmagasabb. Indoklás: ott olyan exploitot mutattak be, amely azelőtt hat, hogy az alkalmazáskód egyáltalán futna.
Az üzemeltetők számára ennek kellemetlen következménye van. Sok védelmi intézkedés az alkalmazásban ül: biztonsági bővítmények a WordPressben, tűzfalmodulok a webshopokban, ellenőrzések a saját kódban. Ezek mind alkalmazáskód. Ha a kihasználás ezek előtt történik, elkésnek.
Ehhez jön a szoros összefonódás: a mod_php esetében a PHP osztozik a folyamaton az Apache-csal. Amit a PHP kompromittál, az a webszerver jogaival és annak memóriájában fut. A PHP-FPM-nél ezzel szemben a poolok weboldalankénti saját felhasználókkal elválaszthatók, ami korlátozhatja egy behatolás következményeit.
A priorizáláshoz ez azt jelenti: ha több szervert üzemeltet, a mod_php-sok kerülnek előre, és náluk különösen fontos a nyomok utólagos ellenőrzése.
Amit nem tudunk: a világszerte megszámolt 22,6 millió kitett, potenciálisan sebezhető példány közül hány használ mod_php-t. Erről megbízható számokat nem tettek közzé.
Mod_php-t használ a szerverem?
A következő parancsok kizárólag olvasók. A szolgáltatás- és parancsnevek disztribúciónként eltérnek: a Debian és az Ubuntu apache2-t, az RHEL-család httpd-t használ.
apachectl -M 2>/dev/null | grep -i php # pl. php_module vagy 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, a modulcsomag állapota
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-család
Ha nem jelenik meg PHP-modul, az Apache valószínűleg a PHP-FPM-et használja a proxy_fcgi-n keresztül. Ilyenkor az Nginx és PHP-FPM biztosítása oldal tudnivalói értelemszerűen érvényesek.
Mit tegyenek most a mod_php-üzemeltetők
- A PHP-modul frissítése a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, vagy a disztribúciója megerősített backportjára.
- Az Apache teljes újraindítása, nem csak újratöltése. A mod_php esetében a régi PHP-kód minden Apache-folyamatban benne van.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL-család
ps -o pid,lstart,cmd -C apache2 # indítási idő ellenőrzése, RHEL-en: -C httpd
- Átmeneti intézkedések beállítása, ha a frissítés még nem megy. A php.net egyebek mellett olyan rögzített korlátokat nevez meg, amelyeket az alkalmazások nem írhatnak felül:
# Szerverkonfiguráció vagy VirtualHost, nem .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
A memory_limit=-1 mellé cgroupon keresztüli memóriahatár tartozik, nem az RLIMIT_AS vagy az RLIMIT_DATA révén. Ezek az intézkedések nem nyújtanak teljes védelmet; a részletek az Azonnali intézkedések, ha még nem tud javítani oldalon vannak. Ha egyik sem megy azonnal, a BSI azt ajánlja, hogy a webszervert átmenetileg vegyék le a hálózatról.
Ha az Apache-a mod_php-val október 17. és a javítás között védtelenül volt az interneten, mentse a naplókat október 20-tól, és vizsgáltassa át a szervert nyomok szempontjából. A javítás önmagában nem bizonyítja, hogy nem történt semmi.
Középtávon: el a mod_php-tól
A javítás után érdemes az architektúrára nézni. Az átállás a PHP-FPM-re az Apache mpm_event és proxy_fcgi modulokkal vagy az Nginxszel elválasztja a PHP-t a webszervertől, weboldalankénti saját poolokat és felhasználókat tesz lehetővé, és megkönnyíti az újraindításokat és a verzióváltásokat. A PHP2Shell-t nem zárja le, de csökkenti a jövőbeli rések támadási felületét.
Az átállás tervezést igényel. A korábban a .htaccess-ben php_value-val beállított értékek a PHP-FPM alatt már nem hatnak, és át kell őket vinni a poolba. A felhasználók és a jogok változnak, a feltöltési és gyorsítótár-könyvtáraknak esetleg új jogosultság kell. Egy tesztkörnyezetben ez jól kezelhető, éles üzemben időnyomás alatt nem. Tudnivalók az átállásról az Apache biztosítása mod_php-val oldalon vannak.
Hogyan segít konkrétan a PHP SOS?
- Felismerés: Ellenőrizzük, mely szerverek használnak mod_php-t, és melyik csomagforrásból származik a modul.
- Javítás és újraindítás: A PHP-javítási szolgáltatáson keresztül telepítjük a frissítést, és ellenőrizzük, hogy már nem fut régi Apache-folyamat.
- Az átmenet biztosítása: Ahol a frissítés akadályba ütközik, a php.net intézkedéseit állítjuk be a szerverkonfigurációban.
- Átállítás: A szerverkeményítés keretében megtervezzük és teszteljük az átállást a PHP-FPM-re, elkülönített poolokkal.
Gyakori kérdések
Miből látom, hogy az Apache-om mod_php-t használ?
Az apachectl -M vagy httpd -M paranccsal látja a betöltött modulokat. Ha ott egy php_module vagy php8_module jellegű modul áll, a PHP közvetlenül az Apache-ban fut. Debianon és Ubuntun az a2query -m is megmutatja, hogy aktív-e php-modul.
Véd a WordPress biztonsági bővítménye mod_php esetén?
Ennél a résnél nem. A PHP-csapat szerint a mod_php esetében exploitot mutattak be, még mielőtt az alkalmazáskód egyáltalán futna. Egy bővítmény alkalmazáskód, így elkésik. Védelmet csak a PHP-frissítés nyújt az Apache újraindításával.
Át kell-e most váltanom a mod_php-ról PHP-FPM-re?
Először javítson, aztán állítson át. A PHP-FPM-re való váltás a legtöbb felállásnál középtávon értelmes, mert a PHP ilyenkor a webszervertől elkülönítve fut. A PHP2Shell-t viszont nem zárja le, mert a PHP-FPM is érintett.