CVE-2026-109618: RCE dėl atminties pritrūkimo būsenos

Trumpai: CVE-2026-109618 yra viena iš dviejų spragų už PHP2Shell. Atminties pritrūkimo (Out-of-Memory) būsena gali nutraukti PHP, kai užklausos duomenys inicializuoti tik iš dalies; valant atmintį neteisingi duomenys gali būti laikomi galiojančiais. Tai leidžia vykdyti kodą be prisijungimo. Klaida ištaisyta PHP 8.5.12, 8.4.27, 8.3.36 ir 8.2.35 versijose.

Kas yra CVE-2026-109618?

CVE-2026-109618 (GitHub identifikatorius GHSA-w8hw-w9fx-j79w) yra atminties klaidos spraga PHP branduolyje. Pagal CVSS v4.0 ji įvertinta 9,2 balo. Kartu su CVE-2026-109619 ji sudaro tai, ką žiniasklaida vadina PHP2Shell.

Poveikis yra vadinamasis „unauthenticated Remote Code Execution“: užpuolikas gali nuotoliniu būdu ir be naudotojo paskyros vykdyti kodą žiniatinklio serveryje. Todėl spraga priklauso pavojingiausiai pažeidžiamumų klasei, kokią gali turėti žiniatinklio serveris.

Kaip spraga iš esmės atsiranda

Kai PHP apdoroja žiniatinklio užklausą, vidujai sukuria tai užklausai skirtas duomenų struktūras, pavyzdžiui, pateiktiems formos duomenims. Jei PHP čia pasiekia atminties ribą, jis nutrūksta su atminties pritrūkimo (Out-of-Memory) būsena. Pasak php.net, tai gali nutikti, kai užklausos duomenys inicializuoti tik iš dalies.

Kiekvienos užklausos pabaigoje PHP sutvarko ir atlaisvina atmintį. Būtent čia glūdi klaida: valymas gali neteisingus, tik iš dalies sukurtus duomenis traktuoti kaip galiojančius. Iš tokio netinkamo elgesio tam tikromis sąlygomis galima išvesti kodo vykdymą.

Kodėl tokia klaida rimta? Atminties klaida programavimo kalboje paveikia visas ja veikiančias programas, nepriklausomai nuo to, kaip kruopščiai jos programuotos. Prižiūrėtas WordPress diegimas su naujausiais įskiepiais paveiktas lygiai taip pat kaip sena nuosavo kūrimo programa. Todėl čia nepadeda programos atnaujinimas, o tik PHP atnaujinimas.

Tolesnių techninių išnaudojimo detalių sąmoningai neskelbiame. Gynybai jų nereikia: lemia tai, ar jūsų serveris naudoja ištaisytą versiją ir ar nauji procesai tikrai veikia.

Paveiktos versijos ir veikimo režimai

Paveikti veikimo režimai PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. PHP komanda riziką vertina didžiausią esant mod_php. Distribucijos ir talpintojai kartais įdiegia atgalinius perkėlimus (backports), todėl rodoma senesnė versija, nors klaida ištaisyta. Lemia paketų būsena ir teikėjo patvirtinimas.

Dėl mastelio: Palo Alto Networks (Unit 42) suskaičiavo daugiau nei 22,6 milijono viešai pasiekiamų, potencialiai pažeidžiamų egzempliorių. BSI paskelbė 3 įspėjimo lygį (oranžinis) ir laukė greito plataus išnaudojimo.

CVE-2026-109618 šalinimas: atnaujinimas ir paleidimas iš naujo

Vienintelė visiška priemonė yra atnaujinimas. Pirmiausia patikrinkite versiją ir paketų būseną. Paketų pavadinimai priklauso nuo distribucijos; pavyzdžiai remiasi PHP 8.3:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Jei paketo pakeitimų žurnale (changelog) nurodytas CVE numeris, atgalinis perkėlimas įdiegtas. Jei jo nėra, tai automatiškai nereiškia, kad paketas pažeidžiamas; tuomet padeda palyginimas su versijų lentele arba užklausa teikėjui.

Po atnaujinimo reikia paleisti iš naujo visus PHP procesus, pavyzdžiui, su systemctl restart php8.3-fpm arba esant mod_php iš naujo paleidus Apache. Kaip užtikrinti, kad nebeveiktų senas darbinis procesas (worker), aprašyta puslapyje PHP-FPM ir visų darbinių procesų paleidimas iš naujo.

Pereinamosios priemonės, kai atnaujinti dar negalima

php.net dėl PHP2Shell paskelbė pereinamąsias priemones. Jos galioja abiem spragoms kartu ir aiškiai nėra visiška apsauga. Tai, kad kelios jų susijusios su atminties ribomis, dera su CVE-2026-109618 atminties pritrūkimo sukėlėju; tačiau oficialaus atskirų priemonių priskyrimo atskiriems CVE nėra.

; FPM baseino pavyzdys, pvz. /etc/php/8.3/fpm/pool.d/www.conf (kelias priklauso nuo distribucijos)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, jei reikia įkėlimų
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Reikšmės turi būti nustatytos taip, kad programos jų negalėtų perrašyti, todėl php_admin_value. Su memory_limit=-1 tarnybai reikia atminties ribos iš išorės, per konteinerį ar cgroup, o ne per RLIMIT_AS ar RLIMIT_DATA. PHP 8.5 papildomai taikoma fatal_error_backtraces=0. Visos detalės pateiktos puslapyje Skubios priemonės, kai dar negalite pataisyti.

Kaip PHP SOS padeda konkrečiai?

Per savo PHP pataisų paslaugą CVE-2026-109618 uždarome struktūruotai:

• Užfiksuoti esamą būklę: PHP šaka, veikimo režimas, paketų šaltinis ir atgalinio perkėlimo būklė kiekviename serveryje.
• Įdiegti atnaujinimą iš tinkamo paketų šaltinio arba, kur to nepavyksta, tvarkingai nustatyti pereinamąsias priemones baseino ar serverio konfigūracijoje.
• Patikrinti paleidimą iš naujo: Kontroliuojame, kad nebeveikia seni PHP procesai.
• Įrodymas: Gaunate dokumentaciją su versijomis ir paketų būsenomis prieš įsikišimą ir po jo, pavyzdžiui, vadovybei, draudikui ar duomenų apsaugai.

Dažni klausimai

Šaltiniai

• php.net: saugumo pranešimai
• PHP 8 ChangeLog
• BSI (Vokietijos federalinė informacijos saugumo tarnyba)