Trumpai: CVE-2026-109619 yra antroji spraga už PHP2Shell. Vidinė būsena, priklausanti užklausai, gali išlikti atlaisvinus atmintį; vėlesnė užklausa tame pačiame darbiniame procese (worker) gali ją panaudoti, kol ji dar nenustatyta iš naujo. Pasekmė yra kodo vykdymas be prisijungimo. Priemonė: atnaujinti iki PHP 8.5.12, 8.4.27, 8.3.36 ar 8.2.35 ir paleisti iš naujo visus darbinius procesus.
Kas yra CVE-2026-109619?
CVE-2026-109619 (GitHub identifikatorius GHSA-6wmf-4rv5-p3rp) pagal CVSS v4.0 įvertinta 9,2 balo. Kartu su CVE-2026-109618 ji sudaro PHP2Shell. Abi spragos glūdi pačiame PHP, o ne programoje.
Poveikis toks pat kaip ir sesutės spragos: užpuolikas gali nuotoliniu būdu, be slaptažodžio ir be naudotojo paskyros, vykdyti kodą serveryje. Tačiau priežastis kita.
Kodėl pasenusi būsena darbiniame procese pavojinga
PHP žiniatinklio serveris kiekvienai užklausai nepaleidžia naujo proceso. Su PHP-FPM, Apache su mod_php, LiteSpeed ar FrankenPHP vienas darbinis procesas (worker) paeiliui apdoroja daug užklausų. Tarp dviejų užklausų PHP vidinę būseną nustato iš naujo, kad nieko iš užklausos A nepatektų į užklausą B.
Esant CVE-2026-109619, šis nustatymas iš naujo nepavyksta visiškai. Pasak php.net, užklausai priklausanti vidinė būsena gali išlikti atlaisvinus atmintį. Vėlesnė užklausa tame pačiame darbiniame procese gali panaudoti šią pasenusią būseną, kol ji dar nenustatyta iš naujo. Paprasčiau tariant: kažkas toliau naudojama, kas iš tikrųjų jau nebegalioja.
Eksploatacijos požiūriu tai pastebėtina. Darbinių procesų pakartotinis naudojimas yra sąmoningas, nes padaro žiniatinklio serverį greitą: darbinio proceso nereikia kiekvienai užklausai paleisti iš naujo, kraustyti plėtinių ir skirti atminties. Taigi spraga paliečia savybę, kurią turi praktiškai kiekvienas gamybinis PHP diegimas. php.net nenurodo konfigūracijos, kuri problemą visiškai išvengtų; todėl kelias eina per atnaujinimą.
Išnaudojimo detalių neskelbiame. Operatoriams svarbu: reikia stebėti kiekvieną veikimo režimą, kuriame darbiniai procesai aptarnauja kelias užklausas, o būtent šie režimai ir yra įprasti.
Dviejų PHP2Shell spragų palyginimas
| Požymis | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub identifikatorius | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Įvertinimas | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Sukėlėjas | Atminties pritrūkimas (Out-of-Memory) užklausos duomenų inicializavimo metu | Vidinė būsena išlieka po atlaisvinimo |
| Poveikis | Kodo vykdymas be prisijungimo | Kodo vykdymas be prisijungimo |
| Ištaisyta | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Paveikti PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. Didžiausią riziką PHP komanda mato esant mod_php; kodėl, paaiškiname puslapyje Kodėl mod_php kelia didžiausią riziką.
CVE-2026-109619 uždarymas: atnaujinimas, tada visų darbinių procesų paleidimas iš naujo
Būtent šios spragos atveju paleidimas iš naujo yra lemiamas. Kol seni darbiniai procesai veikia atmintyje, serveris toliau dirba su klaidingu kodu, nors nauji failai seniai guli diske.
Patikrinkite versiją ir paketų būseną. Paketų pavadinimai skiriasi pagal distribuciją ir talpintojo sąsają:
php -v
php-fpm8.3 -v # FPM vykdomasis failas gali turėti kitą versiją nei CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL šeima
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Po to paleiskite iš naujo visas paveiktas tarnybas:
sudo systemctl restart php8.3-fpm # kiekvienai įdiegtai PHP versijai
sudo systemctl restart apache2 # esant mod_php; RHEL sistemose tarnyba vadinasi httpd
Jei jūsų distribucija ar talpintojas įdiegia atgalinį perkėlimą (backport), rodomas versijos numeris gali likti tas pats. Tada svarbūs paketo pakeitimų žurnalas (changelog) ir raštiškas teikėjo patvirtinimas. Žingsnis po žingsnio patikrą rasite puslapyje PHP-FPM ir visų darbinių procesų paleidimas iš naujo.
Užsirašykite paleidimo iš naujo datą ir valandą. Vėlesniam vertinimui, ar ataka įvyko prieš pataisą ar po jos, šis laikas yra svarbiausias atskaitos taškas.
Ką dar reikia padaryti po pataisos
Pataisa neįrodo, kad anksčiau nieko neįvyko. Pagal žiniasklaidos pranešimus pirmas atakos bandymas pastebėtas spalio 17 d., keturiomis dienomis anksčiau už pataisas. Saugokite serverio žurnalus nuo spalio 20 d., kaip rekomenduoja specializuota spauda, ir tikrinkite serverį dėl neįprastumų. Užuominų pateikia puslapis Ar jau esu kompromituotas?.
Atsižvelkite į aprėptį: sėkmingai vykdant kodą užpuolikas turi PHP proceso teises. Jis gali skaityti tai, ką programa gali skaityti, pavyzdžiui, konfigūracijos failus su duomenų bazių prieigomis ar API raktais. Jei incidentas patvirtinamas, šias prieigas po išvalymo reikia atnaujinti.
Kaip PHP SOS padeda konkrečiai?
Per PHP pataisų paslaugą taisymą įgyvendiname atsekamai:
- Užfiksuoti: kokios PHP versijos ir veikimo režimai veikia kuriame serveryje ir kuris paketų šaltinis jas teikia?
- Pataisyti: atnaujinimas iš tinkamo šaltinio arba pereinamosios priemonės pagal php.net, kur atnaujinimas dar užblokuotas.
- Kontroliuoti paleidimą iš naujo: procesas po proceso tikriname, kad veikia tik pataisyta versija.
- Dokumentuoti: versijos, paketų būsenos ir paleidimo iš naujo laikai, kad galėtumėte būklę įrodyti.
Dažni klausimai
Kuo CVE-2026-109619 skiriasi nuo CVE-2026-109618?
CVE-2026-109618 atsiranda, kai atminties pritrūkimo (Out-of-Memory) būsena nutraukia užklausą inicializavimo viduryje. CVE-2026-109619 susijusi su būsena, likusia darbiniame procese po užklausos pabaigos. Abi lemia kodo vykdymą be prisijungimo ir ištaisytos tose pačiose PHP versijose.
Ar padeda dažniau paleisti PHP-FPM darbinius procesus iš naujo?
Kaip atnaujinimo pakaitalas tai netinka. php.net dažnesnio darbinių procesų paleidimo iš naujo kaip pereinamosios priemonės nenurodo. Tačiau po atnaujinimo darbinius procesus paleisti iš naujo privalote, kad iš viso veiktų pataisyta versija.
Ar CMS atnaujinimas mane saugo nuo CVE-2026-109619?
Ne. Spraga yra PHP, o ne WordPress, Shopware, TYPO3 ar kitoje sistemoje. Ją uždaro tik PHP atnaujinimas arba teikėjo patvirtintas atgalinis perkėlimas (backport).
Ar žinomi atakos per CVE-2026-109619 pėdsakai?
Patvirtintų kompromitavimo rodiklių (Indicators of Compromise) kol kas neskelbta. Aptikimas grindžiamas elgsenos analize, pavyzdžiui, naujais PHP failais, neįprastais išeinančiais ryšiais ar nežinomomis cron užduotimis.