{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"PHP-i kriitiliste haavatavuste \u00fcksikasjad on avalikustatud ja on ilmunud parandavad uuendused","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
On avaldatud PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 paranduste v\u00e4ljalasked 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\u00e4\u00e4vad plaastritest ilma), milles on parandatud kaks kriitilist haavatavust:<\/p>\n
\n
CVE-2026-109618 \u2014 kaugjuhtimine koodi t\u00f5ttu, et kui protsessis on vaba m\u00e4lu l\u00f5ppenud, v\u00f5ib m\u00e4lu puudumise k\u00e4itleja, kasutades longjmp() funktsiooni, katkestada PHP t\u00f5lgendi oleku, kus on initsialiseeritud vaid osa sisemistest struktuuridest, mis on seotud p\u00e4ringu t\u00f6\u00f6tlemisega. Edasi liikudes p\u00f6\u00f6rdub p\u00e4ringu t\u00f6\u00f6tlemise l\u00f5petamise funktsioon nende struktuuride poole kui juba initsialiseeritud, kuigi neile ei ole m\u00e4lu eraldatud.\n
R\u00fcnnaku peamine vektor on multipart-p\u00e4ringute manipuleerimine, et luua tingimusi protsessi jaoks vaba m\u00e4lu otsa saamiseks. post_max_size limiidi \u00fcmbers\u00f5iduks ei pruugi olla m\u00e4\u00e4ratud Content-Length pealkirja ja selle asemel edastatakse suur hulk HTTP pealkirju. Samuti on v\u00f5imalik spetsiifilisi r\u00fcnnakuid php-rakendustes, mis kasutavad \u00fclem\u00e4\u00e4ra palju m\u00e4lu. Ekspluudi olemasolu on kinnitatud mod_php puhul, kuna see kutsub funktsiooni shutdown() isegi t\u00f5rke korral. PHP-FPM l\u00f5petab t\u00f5rke korral alamprotsessi, mis raskendab r\u00fcnnaku teostamist, kuid teoreetiliselt ei v\u00e4lista seda. <\/p>\n
CVE-2026-109619 \u2014 kaugjuhtimine koodi t\u00f5ttu, et m\u00e4lu kasutamine p\u00e4rast selle vabastamist tuleneb vale globaalsete olekute puhastamisest, mis on seotud konkreetse p\u00e4ringuga. Kui p\u00e4ring katkeb fatal t\u00f5rke, aja\u00fclesande v\u00f5i m\u00e4lupuuduse t\u00f5ttu, v\u00f5ivad globaalne olek j\u00e4\u00e4da l\u00e4htestamata ja viidatud n\u00e4itajad j\u00e4\u00e4vad aktiivseks, vaatamata m\u00e4lule, millele nad viitavad, vabastamisele. J\u00e4rgmisel p\u00e4ringu t\u00f6\u00f6tlemisel samas protsessis v\u00f5ib juhtuda, et j\u00e4\u00e4kn\u00e4idiku kaudu p\u00f6\u00f6rdutakse vana globaalse oleku poole.\n
Ressurside kasutamine v\u00f5ib h\u00f5lmata tingimuste loomist, mis p\u00f5hjustavad m\u00e4luh\u00f5ive ammendumise multipart-p\u00e4ringute t\u00f6\u00f6tlemisel laadimise edenemise n\u00e4itamiseks (session.upload_progress). Peamiste ja kinnitatud r\u00fcnnakuvektoritena mainitakse PHP 8.5 'fatal_error_backtraces' t\u00f6\u00f6tlejat, mis ei nulli j\u00e4lgimisolekut l\u00f5petamisel. Esimesel juhul on r\u00fcnnak v\u00f5imalik mod_php ja PHP-FPM gegen, teisel juhul ainult mod_php. Samuti mainitakse kinnitamata v\u00f5imalust r\u00fcnnaku l\u00e4biviimiseks seadistustes, mille konfiguratsioonis on direktiivid, mis p\u00f5hjustavad hoiatuseteateid p\u00e4ringute varases t\u00f6\u00f6tlemises (n\u00e4iteks hoiatused aegunud parameetrite kasutamise kohta).<\/p>\n<\/ul>\n
Kinnitust on leidnud, et haavatavuste t\u00e4ielik blokeerimine on v\u00f5imalik ainult v\u00e4rskenduse installimise teel. J\u00e4rgmised meetmed v\u00f5ivad v\u00e4hendada r\u00fcnnaku \u00f5nnestumise t\u00f5en\u00e4osust, kuid ei tee s\u00fcsteemi t\u00e4ielikult turvaliseks:<\/p>\n
\n
php.ini parameetri seadmine \u00abmemory_limit=-1\u00bb, mis raskendab r\u00fcndaja v\u00f5imalust kontrollida m\u00e4lulimiitide l\u00f5ppemist.\n
Parameetri \u00abpost_max_size = 8M\u00bb seadmine, kui ei ole vaja suurt failide \u00fcleslaadimist. Parameetri \u00abupload_max_filesize\u00bb v\u00e4\u00e4rtus peaks olema v\u00e4iksem kui parameetri \u00abpost_max_size\u00bb v\u00e4\u00e4rtus.\n
M\u00e4lu tarbimise limiidi seadmine s\u00fcsteemitase, l\u00e4bi cgroup memory.max v\u00f5i konteineri m\u00e4lutarbimise parameetrid, kuid mitte s\u00fcsteemsete limiitide RLIMIT_AS ja RLIMIT_DATA kaudu, mis lihtsalt provotseerivad probleemi 'longjmp()'.\n
Kui j\u00f5udlus pole oluline, v\u00f5ib piirata \u00fche t\u00f6\u00f6protsessi poolt t\u00f6\u00f6deldavate p\u00e4ringute arvu PHP-FPM-is pm.max_requests=1 ja Apache httpd-s MaxRequestsPerChild abil.\n