Shtë publikuar versioni korrektues PHP 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35, si dhe patch-et për degët e PHP 7.4, PHP 8.0 dhe PHP 8.1 që nuk mbahen më (versionet e ndjeshme nga 5.4 deri në 7.3 mbeten pa patch-e), në të cilat janë korrigjuar dy vulnerabilitete kritike:
- CVE-2026-109618 â ekzekutimi i kodit nĂ« distancĂ«, i shkaktuar nga fakti se gjatĂ« shterimit tĂ« memories sĂ« mbĂ«shtetur pĂ«r procesin, menaxheri i memorie pĂ«r mungesĂ« memory, pĂ«rmes ekzekutimit tĂ« funksionit longjmp(), mund ta ndĂ«rpresĂ« interpretuesin PHP nĂ« njĂ« gjendje ku janĂ« inicializuar vetĂ«m disa struktura tĂ« brendshme qĂ« lidhen me pĂ«rpunimin e kĂ«rkesĂ«s. NĂ« vazhdim, funksioni i pĂ«rfundimit tĂ« pĂ«rpunimit tĂ« kĂ«rkesĂ«s referohet kĂ«tyre strukturave si tĂ« inicializuara, megjithĂ«se memoria pĂ«r to nuk Ă«shtĂ« alokuar.
Vektori kryesor i sulmit është manipulimi me kërkesat multipart për të krijuar kushte për shterimin e memories së mbështetur për procesin. Për të anashkaluar limitin post_max_size mund të mos tregohet header-i Content-Length dhe të dërgohet një numër i madh HTTP-heardesh. Mund të zhvillohen edhe sulme të sakta ndaj operacioneve të caktuara në aplikacionet php, të cilat shpenzojnë pa masë memory. Prania e një eksploitimi është konfirmuar për mod_php, pasi ai e thërras funksionin shutdown() edhe në rast dështimi. PHP-FPM në rast dështimi ndalon procesin fëmijë, duke e bërë të vështirë zhvillimin e sulmit, por teorikisht nuk e përjashton atë.
- CVE-2026-109619 â ekzekutimi i kodit nĂ« distancĂ«, i shkaktuar nga qasja nĂ« memory pas lirimit tĂ« saj pĂ«r shkak tĂ« pastrimit tĂ« papĂ«rshtatshĂ«m tĂ« gjendjes globale qĂ« i Ă«shtĂ« lidhur kĂ«rkesĂ«s specifike. NĂ« rastin e ndĂ«rprerjes sĂ« kĂ«rkesĂ«s pĂ«r shkak tĂ« njĂ« gabimi fatal, njĂ« skadence ose mungesĂ« memory, gjendja globale mund tĂ« mbetet e pa riluajtur dhe treguesit mund tĂ« mbeten aktivĂ«, megjithĂ«se memoria pĂ«r tĂ« cilĂ«n ato i referohen Ă«shtĂ« liruar. GjatĂ« pĂ«rpunimit tĂ« kĂ«rkesĂ«s sĂ« ardhshme nĂ« tĂ« njĂ«jtin proces mund tĂ« ndodhĂ« referimi me treguesin e mbetur nĂ« gjendjen globale tĂ« vjetĂ«r.
Për funksionim, mund të përdoret krijimi i kushteve për shterrjen e memories së disponueshme gjatë përpunimit të kërkesave multipart në kod për të treguar progresin e ngarkesës (session.upload_progress). Në këtë rast, si një vektor sulmi kryesor dhe të konfirmuar përmendet menaxhuesi fatal_error_backtraces në PHP 8.5, i cili nuk reseton gjendjen e gjurmimit kur përfundon. Në rastin e parë, sulmi është i mundur në mod_php dhe PHP-FPM, ndërsa në të dytin vetëm në mod_php. Gjithashtu, përmendet një mundësi e papritur për të kryer sulmin në konfigurimet, në cilat janë direktivat që çojnë në shfaqjen e paralajmërrimeve në një fazë të hershme të përpunimit të kërkesës (për shembull, paralajmërimet për përdorimin e parametrave të shkëputura).
Pretendohet se bllokimi i plotë i vulnerabiliteteve është i mundur vetëm përmes instalimit të përditësimeve. Masat e mëposhtme lejojnë të reduktojnë probabilitetin e suksesit të sulmeve, por nuk e bëjnë sistemin plotësisht të sigurt:
- Caktimi i parametrave nĂ« php.ini âmemory_limit=-1â, qĂ« e bĂ«n tĂ« vĂ«shtirĂ« kontrollin e shterrjes sĂ« kufijve tĂ« memories nga sulmuesi.
- Caktimi i parametrave âpost_max_size = 8Mâ, nĂ«se nuk ka nevojĂ« pĂ«r ngarkimin e skedarĂ«ve tĂ« mĂ«dhenj. Vlera e parametrave âupload_max_filesizeâ duhet tĂ« jetĂ« mĂ« e vogĂ«l se parametri âpost_max_sizeâ.
- Caktimi i kufizimeve për konsumimin e memories në nivelin sistemor, përmes cgroup memory.max ose parametrave të konsumit të memories nga kontejneri, por jo përmes kufijve sistemorë RLIMIT_AS dhe RLIMIT_DATA, të cilat vetëm nxisin thirrjen problematike longjmp().
- Nëse performanca nuk është e rëndësishme, mund të kufizohet numri i kërkesave të përpunuara nga një proces punë me pm.max_requests=1 në PHP-FPM dhe MaxRequestsPerChild në Apache httpd.
- Caktimi nĂ« nivelin php.ini ose konfigurimit serverĂ« (jo pĂ«rmes ini_set() ose FPM .user.ini, pasi parametri duhet tĂ« veprojĂ« para fillimit tĂ« pĂ«rpunimit tĂ« kĂ«rkesĂ«s) tĂ« parametrave âsession.upload_progress.enabled=0.
- Kur pĂ«rdorni versionin PHP 8.5, duhet tĂ« caktoni parametrin âfatal_error_backtraces=0â.
- Eliminimi i ndërlikimeve të ndërlidhura me kërkesa të veçanta prej opsioneve të shkëputura ose gabim, që çojnë në shfaqjen e mesazheve diagnostike para inicializimit.
- Eliminimi në kodin PHP të situatave që çojnë në tejkalimin e kohëve të pritjes dhe gabimeve fatale, për shembull, të lidhura me dështimet në menaxhuesit e callback dhe përpunimin e ngarkesave.
- Për të bllokuar vulnerabilitetin e parë në kodin e versioneve të vjetra të PHP, mund të zëvendësoni thirrjen e longjmp() në trajtuesin e shkarkimit të memories me _exit().
- Për më tepër, mund të ulni vlerën e parametrave max_input_nesting_level në php.ini dhe të bllokoni kërkesat multipart, siç u demonstrua në njoftimin paraprak.
Statusi i zgjidhjes së vulnerabiliteteve në distributivët mund të vlerësohet në këto faqe: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
ShtesĂ« 1: Vulnerabilitetet u zbuluan me ndihmĂ«n e modeleve tĂ« AI GPTâ5.6 dhe Gemini 4 Argon. Kompania OpenAI publikoi njĂ« mjet php2shell-checker pĂ«r tĂ« kontrolluar nĂ«se faqet dhe skedarĂ«t ekzekutues lokalĂ« janĂ« tĂ« ekspozuar ndaj vulnerabiliteteve, por ky mjet kontrollon vetĂ«m numrin e versionit PHP qĂ« kthehet nga serveri HTTP ose komanda "php -v", pa analizĂ« tĂ« detajuar.
Shtesë 2: Autori i prototipit të eksploitatit që përdor vulnerabilitetin e shkaktuar nga çlirimi i dyfishtë i memories (double-free) njoftoi se problemi mbetet i pa rregulluar në versionin PHP 8.5.12 dhe eksploiti vazhdon të funksionojë. Më parë, përfaqësuesit e PHP thanë se ky vulnerabilitet nuk është i lidhur me riparimet e përgatitura dhe nuk është një problem real. Megjithatë, autori i eksploitatit pretendoi se ky është një vulnerabilitet krejtësisht ndryshe.
Burimi: opennet.ru
