PHP2Shell: iga PHP-serveri leidmine, paikamine ja kontroll

PHP2Shell on kaks kriitilist haavatavust PHP mootoris endas, CVE-2026-109618 ja CVE-2026-109619, mis avaldati 21. oktoobril 2026 CVSS-raskusastmega 9.2. Paikamata käituskeskkonnas saab ründaja ilma kontota käivitada koodi PHP worker-protsessina või lugeda protsessi mälu, kus hoitakse paroole, seansitõendeid, API-võtmeid ja sertifikaate. Teie rakenduse koodis ei pea selleks viga olema: uurijate sõnul võib ohus olla isegi „Hello World“ leht mõjutatud PHP versioonil. Ainus tegelik lahendus on parandatud PHP väljalase ja seejärel iga PHP-d käitava protsessi taaskäivitamine. See juhend annab teile vajalikud käsud.

Millised versioonid on parandatud

PHP 8.1, 8.0 ja 7.x on jõudnud elutsükli lõppu ega saa parandust. Kui kasutate neid endiselt, tähendab paikamine üleminekut toetatud harule.

Linuxi distributsioonid toovad turvaparandusi sageli oma pakettidesse üle (backport), ilma et versiooninumber muutuks upstream’i omaks. Sellistes süsteemides ei ütle versioon üksi piisavalt: otsige paketi muudatuste logist mõlemat CVE numbrit (samm 2).

Samm 1: leidke iga PHP käituskeskkond

Alustage inventuurist, sest rünnaku alla satub just see käituskeskkond, mida keegi ei mäletanud. Igas serveris:

php -v
systemctl list-units --type=service --all 'php*' 'apache2*' 'httpd*'
ls /usr/sbin/php-fpm* /usr/bin/php[0-9]* 2>/dev/null

Esimene rida näitab CLI versiooni, teine töötavaid PHP-FPM-i kogumeid ja veebiservereid ning kolmas kõiki kõrvuti paigaldatud PHP versioone (sage unustatud käituskeskkondade allikas). Loetlege ka paigaldatud paketid:

dpkg -l 'php*' | grep '^ii'      # Debian, Ubuntu
rpm -qa 'php*' 'ea-php*'         # RHEL, AlmaLinux, Rocky, cPanel

Konteinerite puhul kontrollige PHP versiooni igas töötavas tõmmises:

docker ps --format '{{.Names}}' | while read c; do printf '%s: ' "$c"; docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'; done

Ärge unustage testkeskkondi (staging), cron- ja järjekorraservereid, ehitusagente ega hallatud majutuspakette. Majutuspaketi puhul küsige teenusepakkujalt kirjalikult, millist PHP järku te kasutate ja millal see paigati.

Samm 2: paigaldage parandatud väljalase

Debian ja Ubuntu (asendage 8.3 oma haruga):

sudo apt update
sudo apt install --only-upgrade 'php8.3*'
apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'

RHEL, AlmaLinux, Rocky Linux:

sudo dnf upgrade 'php*'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

cPaneli serverid EasyApache 4 pakettidega:

sudo dnf upgrade 'ea-php*'      # older systems: sudo yum update 'ea-php*'

Alpine Linux (paketinimed sisaldavad haru, nt php83):

apk update && apk upgrade 'php83*'

Docker-tõmmised: fikseerige Dockerfile’is parandatud silt, näiteks FROM php:8.3.36-fpm, seejärel ehitage tõmmis ilma vahemäluta uuesti ja asendage töötavad konteinerid:

docker build --pull --no-cache -t myapp:php2shell .
docker compose up -d --build --force-recreate

Kui grep muudatuste logist midagi ei leia, ei ole teie distributsioon parandust veel avaldanud. Kontrollige edasi, kasutage seal, kus ehitate PHP ise, ametlikku väljalaset saidilt php.net, ja rakendage seni allpool kirjeldatud ajutisi meetmeid.

Samm 3: taaskäivitage kõik, mis laadis vana PHP

Uus pakett ei muuda juba töötavates protsessides midagi. Taaskäivitage need:

sudo systemctl restart php8.3-fpm     # Debian, Ubuntu (one per installed version)
sudo systemctl restart php-fpm        # RHEL family
sudo systemctl restart apache2        # Apache with mod_php (httpd on RHEL)
sudo supervisorctl restart all        # long-running workers under Supervisor
php artisan queue:restart             # Laravel queue workers

Debianis ja Ubuntus loetleb sudo needrestart -r l teenused, mis kasutavad endiselt vanu teeke.

Samm 4: kontrollige

Kontrollige iga käituskeskkonda uuesti, seekord seda, mida kasutab veebiserver, mitte ainult CLI-d:

php-fpm8.3 -v                         # or: php-fpm -v
systemctl status php8.3-fpm | grep Active

Versioon peab olema parandatud väljalaskega võrdne või sellest uuem (või peab paketi muudatuste logi nimetama mõlemat CVE-d) ja „Active: since“ aeg peab olema hilisem kui uuendus. WordPressis näete versiooni ka jaotises Tööriistad, Saidi tervis, Info, Server. Ärge pange kontrollimiseks võrku phpinfo() lehte: see avaldab täpselt selle, mida ründajad otsivad.

Kui uuendus peab ootama

Need uurijate soovitatud seaded vähendavad ohtu ajal, mil uuendust ette valmistate. Need ei ole parandus:

; php.ini
post_max_size = 8M                  ; as low as your uploads allow
max_input_nesting_level = 32        ; as low as your forms allow
session.upload_progress.enabled = 0
fatal_error_backtraces = 0          ; where your PHP version supports it

; PHP-FPM pool: recycle workers more often (costs performance)
pm.max_requests = 100

Väärtused on näited; testige neid oma rakendusega. Seade memory_limit = -1 blokeerib mõned ründeteed, kuid kasutage seda ainult koos operatsioonisüsteemi taseme piiranguga, nagu cgroup v2 memory.max, ja ärge kunagi asendage seda piirangut RLIMIT_AS ega RLIMIT_DATA abil. Teenusepakkuja WAF- ja CDN-reeglid aitavad üleminekulahendusena, kuid ei asenda uuendust.

Otsige ründe märke

Ühte tuvastusreeglit ei ole. Need käsud toovad esile uurijate kirjeldatud signaalid:

grep -E 'Allowed memory size of [0-9]+ bytes exhausted' /var/log/php*-fpm.log /var/log/apache2/error.log
grep -E 'exited on signal (6|11)' /var/log/php*-fpm.log
awk '$9 == 500' /var/log/nginx/access.log | wc -l

Mälupiirangu vead pärast ebatavalisi multipart-päringuid, HTTP 500 vastuste puhangud, signaali peale kokku jooksvad PHP worker’id ja ebatavaliselt suured PHPSESSID küpsised vastustes väärivad lähemat uurimist. Ükski neist ei tõesta rünnakut ja nende puudumine ei tõesta, et teid ei mõjutatud. Kui need leiate, säilitage logid, paigaldage parandus ja vahetage välja saladused, mis olid PHP mälus: andmebaasi paroolid, rakenduse võtmed ja API-tõendid. Meie intsidentidele reageerimise meeskond saab uurimise üle võtta ja meie hallatud turbe teenus saab teie servereid pärast paikamist jälgida.

Kust alustada

1. Käivitage inventuurikäsud igas serveris ja konteineris ning pange kirja iga PHP versioon.
2. Uuendage paketihalduriga või ehitage tõmmised parandatud sildiga uuesti.
3. Taaskäivitage PHP-FPM, Apache ja iga PHP worker.
4. Kontrollige versiooni ja taaskäivitamise aega ning säilitage väljund tõendina.
5. Otsige grepiga logidest ülalkirjeldatud märke ja vahetage saladused igas süsteemis, kus need ilmnevad.

Üksikasjad: PHP2Shelli teabesait, PHP Foundationi teadaanne, Wiz Research.