Na kratko: CVE-2026-109619 je druga ranljivost za PHP2Shell. Notranje stanje, ki sodi k zahtevi, lahko po sprostitvi pomnilnika ostane; poznejša zahteva v istem workerju ga lahko uporabi, preden je ponastavljeno. Posledica je izvajanje kode brez prijave. Rešitev: posodobitev na PHP 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 in ponovni zagon vseh workerjev.
Kaj je CVE-2026-109619?
CVE-2026-109619 (oznaka GitHub GHSA-6wmf-4rv5-p3rp) ima po CVSS v4.0 oceno 9,2. Skupaj s CVE-2026-109618 tvori PHP2Shell. Obe ranljivosti sta v samem PHP in ne v aplikaciji.
Učinek je enak kot pri sestrski ranljivosti: napadalec lahko na daljavo, brez gesla in brez uporabniškega računa, na strežniku izvede kodo. Vzrok pa je drugačen.
Zakaj je zastarelo stanje v workerju nevarno
Spletni strežnik PHP za vsako zahtevo ne zažene novega procesa. Pri PHP-FPM, Apacheu z mod_php, LiteSpeed ali FrankenPHP en worker zaporedoma obdela veliko zahtev. Med dvema zahtevama PHP ponastavi svoje notranje stanje, da nič iz zahteve A ne pride v zahtevo B.
Pri CVE-2026-109619 to ponastavljanje ne uspe v celoti. Po navedbah php.net lahko notranje stanje, ki sodi k zahtevi, po sprostitvi pomnilnika ostane. Poznejša zahteva v istem workerju lahko to zastarelo stanje uporabi, preden je ponastavljeno. Poenostavljeno: nekaj se uporablja naprej, kar pravzaprav ni več veljavno.
Z vidika obratovanja je to pomenljivo. Ponovna uporaba workerjev je zaželena, ker spletne strežnike dela hitre: worker se ne mora znova zagnati za vsako zahtevo, nalagati razširitev in ustvarjati pomnilnika. Ranljivost torej zadene lastnost, ki jo ima praktično vsaka produkcijska namestitev PHP. php.net ne navaja konfiguracije, ki bi težavo povsem preprečila; zato pot vodi prek posodobitve.
Podrobnosti o izkoriščanju ne objavljamo. Za upravljavce velja: vsak način delovanja, pri katerem workerji obdelajo več zahtev, je treba imeti v očeh, in prav ti načini so običajni.
Primerjava obeh ranljivosti PHP2Shell
| Značilnost | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Oznaka GitHub | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Ocena | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Sprožilec | Out of Memory med inicializacijo podatkov zahteve | notranje stanje ostane po sprostitvi |
| Učinek | izvajanje kode brez prijave | izvajanje kode brez prijave |
| Odpravljeno v | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Prizadeti so PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP in LiteSpeed. Najvišje tveganje vidi ekipa PHP pri mod_php; zakaj, razlagamo na strani Zakaj ima mod_php najvišje tveganje.
Zapiranje CVE-2026-109619: posodobitev, nato ponovni zagon vseh workerjev
Prav pri tej ranljivosti je ponovni zagon odločilen. Dokler stari workerji tečejo v pomnilniku, strežnik dela z napačno kodo naprej, čeprav nove datoteke že zdavnaj ležijo na disku.
Preverite različico in stanje paketa. Imena paketov se po distribuciji in vmesniku ponudnika gostovanja razlikujejo:
php -v
php-fpm8.3 -v # binarna datoteka FPM ima lahko drugo različico kot CLI
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # družina RHEL
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Nato znova zaženite vse zadevne storitve:
sudo systemctl restart php8.3-fpm # za vsako nameščeno različico PHP
sudo systemctl restart apache2 # pri mod_php; v RHEL se storitev imenuje httpd
Če vaša distribucija ali ponudnik gostovanja namesti backport, lahko prikazana številka različice ostane enaka. Takrat štejeta dnevnik sprememb paketa in pisna potrditev ponudnika. Preverjanje korak za korakom najdete na strani Ponovni zagon PHP-FPM in vseh workerjev.
Zapišite datum in uro ponovnega zagona. Za poznejšo oceno, ali je napad potekal pred popravkom ali po njem, je ta čas najpomembnejša referenčna točka.
Kaj ostane po popravku
Popravek ne dokazuje, da prej ni bilo nič narobe. Po poročilih medijev je bil prvi poskus napada opažen 17. oktobra, štiri dni pred popravki. Hranite dnevnike strežnika od 20. oktobra, kot svetuje strokovni tisk, in strežnik preverite glede nepravilnosti. Napotke ponuja stran Ali sem že ogrožen?.
Pri tem pomislite na doseg: pri uspešnem izvajanju kode ima napadalec pravice procesa PHP. Bere lahko, kar sme brati aplikacija, na primer konfiguracijske datoteke z dostopi do podatkovne zbirke ali ključi API. Če se incident potrdi, je treba te dostopne podatke po čiščenju obnoviti.
Kako konkretno pomaga PHP SOS?
S storitvijo popravljanja PHP popravek izvedemo sledljivo:
- Zabeležiti: katere različice PHP in načini delovanja tečejo na katerem strežniku in kateri paketni vir jih dobavlja?
- Popraviti: posodobitev iz pravega vira ali vmesni ukrepi po php.net, kjer je posodobitev še blokirana.
- Preveriti ponovni zagon: proces za procesom preverimo, da teče samo še popravljena različica.
- Dokumentirati: različice, stanja paketov in čase ponovnih zagonov, da lahko stanje dokažete.
Pogosta vprašanja
Po čem se CVE-2026-109619 razlikuje od CVE-2026-109618?
CVE-2026-109618 nastane, ko stanje Out of Memory prekine zahtevo sredi inicializacije. CVE-2026-109619 zadeva stanje, ki po koncu zahteve ostane v workerju. Obe vodita v izvajanje kode brez prijave in sta odpravljeni v istih različicah PHP.
Ali pomaga pogostejši ponovni zagon workerjev PHP-FPM?
Kot nadomestilo za posodobitev ni primeren. php.net pogostejših ponovnih zagonov workerjev ne navaja kot vmesni ukrep. Workerje pa morate po posodobitvi znova zagnati, da popravljena različica sploh teče.
Ali me posodobitev CMS-ja ščiti pred CVE-2026-109619?
Ne. Ranljivost je v PHP in ne v WordPressu, Shopwaru, TYPO3 ali drugem sistemu. Zapre jo samo posodobitev PHP ali potrjen backport ponudnika.
Ali so znane sledi napada prek CVE-2026-109619?
Potrjeni indikatorji ogroženosti (Indicators of Compromise) doslej niso bili objavljeni. Odkrivanje temelji na analizi vedenja, na primer novih datotek PHP, nenavadnih odhodnih povezav ali neznanih cron opravil.