AI aitas leida PHP vead: vanad versioonid jäävad paikadeta

PHP projekti 21. oktoobri 2026 turvateate ja 23. oktoobri täpsustuse järgi parandavad väljalasked 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 kaks kriitilist haavatavust, CVE-2026-109618 ja CVE-2026-109619. Vead võivad võimaldada ründajal veebipäringu kaudu serveris koodi käivitada ilma sisse logimata. Veebihalduril tuleb tuvastada veebipäringuid teenindav PHP paigaldus ja paigaldada sellele sobiv turvaväljalase või tarnija kinnitatud paigatud pakett.

Avastamisel ja parandamisel olid eri osalised. OpenAI 21. oktoobri selgituse järgi leidis Calif ühe vea GPT-5.6 Soli abil, Wiz avastas ja teatas mõlemast veast sõltumatult ning PHP hooldajad juhtisid paranduste tegemist ja avaldamist. AI roll oli vea leidmisel abiks; serveritesse jõudev parandus pärineb PHP hooldajate väljalasetest.

Millised PHP versioonid on parandatud?

Uuenduse siht sõltub serveris kasutatavast PHP harust. PHP projekti avaldatud parandatud väljalasked on:

PHP 8.5 puhul vähemalt 8.5.12;
PHP 8.4 puhul vähemalt 8.4.27;
PHP 8.3 puhul vähemalt 8.3.36;
PHP 8.2 puhul vähemalt 8.2.35.

PHP 8.1 ja vanemad harud ei saa projektilt enam tavapäraseid turvaväljalaskeid. Selle juhtumi jaoks tehti siiski minimaalsed lähtekoodiparandused ka harudele 7.4, 8.0 ja 8.1. Need aitavad eeskätt administraatoreid, kes ehitavad PHP ise lähtekoodist või kellel puudub pikaajalise toega tarnija; vanadele harudele ei ilmunud uusi ametlikke hooldusväljalaskeid.

Linuxi distributsioon või majutusteenuse pakkuja võib paranduse oma vanemasse paketti tagasi portida. Siis võib PHP kuvatav põhiversioon pärast paikamist samaks jääda ning ainult versiooninumbri põhjal ei saa kaitstust otsustada. Võrdle paketi täpset väljalaset tarnija turvateatega ja veendu, et selles on parandatud mõlemad haavatavused. Kui tarnija parandust ei paku, tuleb rakendus viia toetatud PHP harule. Ka parandatud 8.2 haru tugi lõpeb aasta lõpus, mistõttu vajab see eraldi uuendusplaani.

Miks puudutab viga ka uuendatud veebirakendust?

Haavatavused asuvad PHP käituskeskkonnas, mitte mõne üksiku sisuhaldussüsteemi lisamoodulis. Wizi tehniline käsitlus kirjeldab autentimiseta koodi käivitamise demonstratsioone WordPressi, Drupali ja Joomla toonastes testpaigaldustes. Need on näited PHP vea võimalikust mõjust; konkreetse veebisaidi olukord sõltub kasutatavast PHP versioonist, käitusviisist ja seadistusest. Sisuhaldussüsteemi uuendamine üksi PHP viga ei paranda.

Esimene haavatavus on seotud mälupuuduse käsitlemisega. Päringu töötlemine võib katkeda siis, kui PHP sisemised andmed on alles osaliselt algväärtustatud, kuid hilisem korrastamine käsitleb neid kehtivana. Teise vea puhul võib päringuga seotud olek jääda töötajaprotsessi pärast selle alusmälu vabastamist. Kui sama protsess võtab vastu järgmise päringu, võidakse aegunud olekut uuesti kasutada.

Risk puudutab veebipäringuid teenindavaid PHP-FPM-i, Apache mod_php mooduli, php-cgi, FrankenPHP ja LiteSpeedi paigaldusi. Kõrgeimaks on hinnatud mod_php risk, sest selle käitusviisi puhul on näidatud rünnet, mille võib käivitada autentimata päring enne rakenduse koodi töölehakkamist. Teiste käitusviiside puhul sõltuvad ründeteed seadistusest, kuid ka need paigaldused vajavad turvaparandust.

Kuidas veebiserveri tegelik PHP versioon kontrollida ja uuendada?

Alusta sellest, milline PHP paigaldus teenindab avalikke veebipäringuid. Käsk php -v näitab käsurea PHP versiooni, ent veebiserver võib kasutada teist binaarfaili, eraldi PHP-FPM-i kogumit või majutusteenuse hallatavat paketti. Samas serveris võivad eri veebisaidid töötada eri PHP harudel. Seetõttu võrdle käsurea tulemust veebiserveri ja FPM-i seadistuse või majutuspaneelis näidatud versiooniga; kontrolli ka paketi väljalaset, mille tarnija on tegelikult paigaldanud.

Pane kirja iga avalikke veebipäringuid teenindava PHP paigalduse haru, täpne paketiversioon ja tarnija. Ametlikku PHP väljalaset võrdle parandatud versioonide loendiga, tarnija paketi puhul kontrolli selle turvateadet.
Varunda enne muudatust veebisaidi failid, andmebaas ning PHP ja veebiserveri seadistused. Veendu, et varukoopia on taastatav, sest haru vahetamine võib tuua esile rakenduse ühilduvusprobleeme.
Paigalda sobiv parandatud PHP väljalase või tarnija kinnitatud pakett. Toetuseta haru puhul kasuta kontrollitud tagasiporditud parandust või vii rakendus toetatud harule.
Taaskäivita uuendatud PHP töötajaprotsessid ja vajaduse korral veebiserver. Seejärel kontrolli veebipäringuid teenindava paigalduse versiooni, veebisaidi toimimist ja vealoge. Paketifailide vahetamisest üksi ei nähtu, kas juba töötavad protsessid kasutavad uut koodi.

Kui uuendamine viibib, võivad ajutised seadistusmuudatused vähendada mõne teadaoleva ründetee mõju. Näiteks seansi üleslaadimise edenemise funktsiooni väljalülitamine peab jõustuma enne päringu töötlemist ning selle järel tuleb töötajaprotsessid taaskäivitada. Ajutine muudatus ei asenda kummagi kriitilise vea parandamist.

Ka pärast turvaväljalaske paigaldamist vajab tähelepanu erandlik seansiseadistus: kui rakendus vahetab seansi serialiseerimisviisi töö ajal ja üleslaadimise edenemise funktsioon on sisse lülitatud, soovitab PHP projekt selle funktsiooni järgmise tavapärase veaparandusväljalaskeni välja lülitada. Veebihalduri järelkontroll peab seega hõlmama nii tegelikult töötavat PHP paketti kui ka selle seansiseadistust.

Loe ka: