PHP-i kriitiliste haavatavuste üksikasjad on avalikustatud ja on ilmunud parandavad uuendused

On avaldatud PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 paranduste väljalasked ning plaastrid juba toetust mitte saavatele versioonidele PHP 7.4, PHP 8.0 ja PHP 8.1 (haavatavad versioonid alates 5.4 kuni 7.3 jäävad plaastritest ilma), milles on parandatud kaks kriitilist haavatavust:

• CVE-2026-109618 — kaugkoodi tõukamine, mis on põhjustatud sellest, et kui protsessi jaoks vaba mälu on otsa saanud, võib mälu puuduse käitleja, kasutades funktsiooni longjmp(), katkestada PHP tõlgendi sellises olekus, kus on initsialiseeritud vaid osa sisemistest struktuuridest, mis on seotud päringu töötlemisega. Järgmisel korral pöördub päringu töötlemise lõpetamise funktsioon nende struktuuride poole, nagu oleks need juba initsialiseeritud, kuigi nende jaoks ei ole mälu eraldatud.

  Rünnaku peamine vektor on multipart-päringute manipuleerimine, et luua tingimusi protsessi jaoks vaba mälu otsa saamiseks. post_max_size limiidi ümbersõiduks ei pruugi olla määratud Content-Length pealkirja ja selle asemel edastatakse suur hulk HTTP pealkirju. Samuti on võimalik spetsiifilisi rünnakuid php-rakendustes, mis kasutavad ülemäära palju mälu. Ekspluudi olemasolu on kinnitatud mod_php puhul, kuna see kutsub funktsiooni shutdown() isegi tõrke korral. PHP-FPM lõpetab tõrke korral alamprotsessi, mis raskendab rünnaku teostamist, kuid teoreetiliselt ei välista seda.

• CVE-2026-109619 — kaugkoodi täitmine, mis on põhjustatud mälu juurde pääsemisest pärast selle vabastamist valede globaalsete seisundite puhastamise tõttu, mis on seotud konkreetse päringuga. Kui päring katkestatakse fataalse vea, ajaülevaate või mälu puuduse tõttu, võib globaalne seisund jääda lähtestamata ja viidatud näidikud võivad jääda aktiivseks, hoolimata sellest, et mälu, millele nad viitavad, on vabastatud. Järgmise päringu töötlemisel samas protsessis võib vägivaldne näidik viia vana globaalsete seisunditeni.

  Ressurside kasutamine võib hõlmata tingimuste loomist, mis põhjustavad mäluhõive ammendumise multipart-päringute töötlemisel laadimise edenemise näitamiseks (session.upload_progress). Peamiste ja kinnitatud rünnakuvektoritena mainitakse PHP 8.5 'fatal_error_backtraces' töötlejat, mis ei nulli jälgimisolekut lõpetamisel. Esimesel juhul on rünnak võimalik mod_php ja PHP-FPM gegen, teisel juhul ainult mod_php. Samuti mainitakse kinnitamata võimalust rünnaku läbiviimiseks seadistustes, mille konfiguratsioonis on direktiivid, mis põhjustavad hoiatuseteateid päringute varases töötlemises (näiteks hoiatused aegunud parameetrite kasutamise kohta).

Kinnitust on leidnud, et haavatavuste täielik blokeerimine on võimalik ainult värskenduse installimise teel. Järgmised meetmed võivad vähendada rünnaku õnnestumise tõenäosust, kuid ei tee süsteemi täielikult turvaliseks:

• php.ini parameetri „memory_limit=-1” seadistamine, mis raskendab ründaja võimalust jälgida mälu piiride ammendumist.
• Parameetri „post_max_size = 8M” seadmine, kui suuremate failide üleslaadimine pole vajalik. Parameetri „upload_max_filesize” väärtus peab olema väiksem parameetri „post_max_size” väärtusest.
• Mälu tarbimise limiidi seadmine süsteemitase, läbi cgroup memory.max või konteineri mälutarbimise parameetrid, kuid mitte süsteemsete limiitide RLIMIT_AS ja RLIMIT_DATA kaudu, mis lihtsalt provotseerivad probleemi 'longjmp()'.
• Kui jõudlus pole oluline, võib piirata ühe tööprotsessi poolt töödeldavate päringute arvu PHP-FPM-is pm.max_requests=1 ja Apache httpd-s MaxRequestsPerChild abil.
• Seadistamine php.ini tasemel või konfiguratsioonis serverid (mitte läbi ini_set() või FPM .user.ini, kuna parameeter peab kehtima enne päringu töötlemise algust), parameeter „session.upload_progress.enabled=0”.
• PHP 8.5 väljalaske kasutamisel tuleks seadistada parameeter „fatal_error_backtraces=0”.
• Ühistele päringutele seotud vananenud või valede seade eemaldamine (nt assert.* ja vale teed open_basedir'is), mis põhjustavad diagnostiliste teadete kuvamist enne initsialiseerimist.
• PHP-koodis olukordade kõrvaldamine, mis viivad tähtaegadeni ja fataalsete vigadeni, näiteks, mis on seotud callback-käitlejate ja üleslaadimise töötlemise tõrgetega.
• Vanade PHP versioonide koodis esimese haavatavuse blokeerimiseks võib longjmp()-kõne asendada _exit()iga.
• Lisaks saab php.ini-s max_input_nesting_level parameetri väärtust vähendada ja blokeerida multipart-päringud, nagu eelnevalt teatatud.

Haavatavuste parandamise staatust jaotustes saab hinnata järgmiste lehekülgede andmete põhjal: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

Lisa 1: Haavatavused tuvastati AI mudelite GPT‑5.6 ja Gemini 4 Argon abil. Ettevõte OpenAI avaldas php2shell-checker tööriista, et kontrollida saitide ja kohalike käivitatavate failide haavatavust, kuid see tööriist kontrollib ainult HTTP-serveri või käsu «php -v» tagastatud PHP versiooninumbrit, ilma üksikasjalikku analüüsi tegemata.

Lisa 2: Ekspluati prototüübi autor, mis kasutab mälu kahekordse vabastamise (double-free) haavatavust, teatas, et probleem jääb parandamata PHP 8.5.12 väljaandes ja eksploit jätkab tööd. Varem on PHP esindajad väitnud, et see haavatavus ei ole seotud tulevaste parandustega ja ei ole tegelik probleem. Kuid ekspluati autor väitis, et see on hoopis teine haavatavus.

Allikas: opennet.ru