Kërkohet urgjentisht përditësimi i sigurisë për PHP ndërsa përhapen përpjekjet për exploit
Një përditësim sigurie për PHP nevojitet urgjentisht për dy dobësi kritike që mund t’i lejojnë një sulmuesi të paautentikuar, domethënë dikujt që nuk ka bërë hyrjen në sistem, të ekzekutojë kod në një web server të prekur. Dobësitë, CVE-2026-109618 dhe CVE-2026-109619, kanë secila një rezultat CVSS v4.0 prej 9.2. CVSS është një shkallë standarde për vlerësimin e rëndësisë së dobësive. Material publik për exploit është i disponueshëm dhe disa kompani sigurie kanë raportuar përpjekje për shfrytëzim.
PHP, software server-side që përdoret për të gjeneruar shumë faqe dhe aplikacione web, ka publikuar versione të rregulluara për katër degë që mbështeten: PHP 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35. Administratorët e serverëve të tyre ose të virtual private servers (VPSs), që janë serverë të hostuar në distancë dhe të caktuar për një klient, duhet ta instalojnë menjëherë versionin përkatës. Klientët që përdorin hosting të përbashkët ose të menaxhuar duhet të konfirmojnë se ofruesi i tyre ka vendosur ose një version të rregulluar, ose një paketë të patch-uar në mënyrë të qartë.
Të dyja dobësitë lidhen me mënyrën se si PHP përpunon të dhënat e brendshme të kërkesës, pra informacionin që merret kur një browser ose një sistem tjetër kontakton një faqe. Ato janë dobësi në PHP runtime, software bazë që ekzekuton kodin PHP, dhe jo në WordPress, një sistem tjetër për menaxhimin e përmbajtjes, në një plugin, një theme ose një aplikacion të veçantë. Përditësimi i këtyre komponentëve vazhdon të jetë praktikë e mirë sigurie, por nuk do t’i korrigjojë këto dy dobësi të PHP.
CVE-2026-109618 mund të shfaqet kur PHP mbetet pa memorie ndërkohë që të dhënat e kërkesës janë përgatitur vetëm pjesërisht. Gjatë pastrimit, PHP mund t’i trajtojë të dhënat e paplota si të vlefshme. Kjo mund të shkaktojë memory corruption, ku informacioni i mbajtur përkohësisht nga një program dëmtohet ose trajtohet gabimisht, dhe në fund mund të lejojë remote code execution. remote code execution, që zakonisht shkurtohet RCE, do të thotë se një sulmues mund ta detyrojë serverin të ekzekutojë komanda nga një vendndodhje tjetër.
CVE-2026-109619 lidhet me stale internal state. Një PHP worker, proces aktiv që trajton kërkesat web, mund të ruajë një referencë ndaj të dhënave të kërkesës pasi memoria pas tyre të jetë liruar. Një kërkesë e mëvonshme, e përpunuar nga i njëjti PHP worker, mund të arrijë informacionin e vjetër përpara se PHP ta rivendosë atë. Rezultati mund të jetë zbulim informacioni ose remote code execution.
Këshillimi i Sucuri thotë se çdo instalim PHP që u shërben kërkesave web duhet të konsiderohet potencialisht i ekspozuar. Kjo përfshin PHP-FPM, ose FastCGI Process Manager, që administron grupe procesesh PHP worker, si dhe Apache me mod_php, php-cgi, FrankenPHP dhe LiteSpeed. PHP e konsideron mod_php konfigurimin me rrezikun më të lartë, sepse një kërkesë e paautentikuar mund të aktivizojë një exploit të demonstruar përpara se të nisë ekzekutimi i kodit të vetë aplikacionit të faqes.
proof-of-concept code publik, që demonstron se si mund të shfrytëzohet një dobësi, qarkulloi përpara rregullimeve zyrtare. Hadrian raportoi se kishte parë shfrytëzim të PHP2Shell në shkallë të gjerë dhe tha se pjesa më e madhe e aktivitetit të vëzhguar përdorte rrugën session upload-progress të PHP. Kompania paralajmëroi gjithashtu se kishte gjasa të shfaqeshin rrugë të tjera. WatchTowr, Patchstack, Cloudflare dhe Vega raportuan veçmas aktivitet keqdashës ose përpjekje të lidhura me dobësitë. Një përpjekje për exploit nuk provon vetvetiu se një server është komprometuar, por kodi publik dhe vëllimi i aktivitetit të raportuar e shtojnë urgjencën e patching.
Pas instalimit të PHP 8.5.12, 8.4.27, 8.3.36 ose 8.2.35 përmes sistemit operativ, panelit të kontrollit të hosting, ofruesit të paketave ose procesit të përcaktuar të deployment, administratorët duhet të rinisin ose të ringarkojnë proceset dhe shërbimet përkatëse PHP worker. Më pas duhet të verifikojnë versionin që po i shërben realisht faqes aktive. Versioni i kthyer nga udhëzimi command-line php -v mund të ndryshojë nga versioni i lidhur me web server. Hyrjet në sistem, rrjedhat e checkout, formularët, ngarkimet, detyrat e planifikuara, application programming interfaces (APIs) dhe faqet e administrimit duhet të testohen të gjitha pas ndryshimit.
Klientët e hosting të përbashkët mund të kërkojnë një zgjedhës të versionit PHP në panelin e tyre të kontrollit. Nëse nuk shfaqet asnjë version i rregulluar, duhet ta pyesin ofruesin nëse ka instaluar një vendor-backported fix, që do të thotë se riparimi i sigurisë është shtuar në një degë më të vjetër të software, ose se kur do të bëhet i disponueshëm një version i rregulluar. Vetëm numri i shfaqur i versionit nuk mjafton, sepse ofruesit e sistemeve operative dhe të mbështetjes afatgjatë ndonjëherë shtojnë riparime sigurie pa ndryshuar numrin e degës.
PHP 8.1 dhe versionet më të vjetra janë jashtë ciklit normal të mbështetjes së projektit dhe nuk do të marrin upstream point releases standarde. Megjithatë, për shkak të rëndësisë së këtyre dobësive, PHP ka publikuar emergency source backports për PHP 7.4, PHP 8.0 dhe PHP 8.1. Shpërndarjet Linux dhe ofruesit e mbështetjes afatgjatë mund të ofrojnë gjithashtu paketa të patch-uara. Operatorët duhet të kalojnë në një degë që mbështetet, të instalojnë një paketë që adreson në mënyrë të qartë si CVE-2026-109618, ashtu edhe CVE-2026-109619, ose të aplikojnë emergency source backport përkatës. Këto riparime emergjente nuk e rikthejnë mbështetjen afatgjatë, ndaj migrimi në një degë PHP që mbështetet mbetet zgjidhja më e sigurt afatgjatë.
Sucuri deklaron se rregullat ekzistuese të web application firewall (WAF) po refuzonin tashmë disa modele kërkesash keqdashëse të lidhura me dobësitë dhe se ka shtuar rregulla më specifike virtual patching për rrugët e njohura PHP2Shell. Një WAF është një shërbim filtrimi i vendosur përpara një faqeje për të inspektuar kërkesat hyrëse. virtual patching nënkupton bllokimin e trafikut të njohur të exploit përpara se të arrijë software e cenueshëm, por nuk e heq vetë defektin dhe nuk mund ta zëvendësojë përditësimin e sigurisë për PHP.
Filtrimi me firewall dështon gjithashtu nëse një sulmues mund të kontaktojë origin server, pajisjen që hoston realisht faqen, pa kaluar përmes shërbimit të filtrimit. Operatorët duhet të kufizojnë aksesin e drejtpërdrejtë IPv4 dhe IPv6, të lejojnë trafik web vetëm nga adresa firewall të miratuara dhe të kontrollojnë që DNS records të vjetra ose hostnames alternative të mos e ekspozojnë origin. Mjediset staging, development, test dhe backup duhet të mbrohen ose t’u kufizohet aksesi, ndërsa subdomains të pambrojtura dhe ports alternative nuk duhet të ofrojnë një rrugë tjetër drejt të njëjtit aplikacion. Duhet të kontrollohen gjithashtu containers të vjetër, server images dhe autoscaling templates, në mënyrë që të mos vazhdojnë të vendosin builds të cenueshme të PHP.
Nëse patching i menjëhershëm është i pamundur, PHP thotë se përditësimi mbetet e vetmja zgjidhje e plotë. Meqë një pjesë e madhe e aktivitetit të vëzhguar ka synuar session upload progress, administratorët mund të vendosin përkohësisht session.upload_progress.enabled = Off në php.ini, në një FPM pool ose në një konfigurim tjetër në nivel serveri që zbatohet përpara parsing të kërkesës, dhe më pas të rinisin çdo proces PHP worker të prekur. Kjo masë bllokon vetëm rrugët e konfirmuara që lidhen me session për CVE-2026-109619. Ajo nuk mbulon çdo rrugë për atë dobësi, nuk bën asgjë kundër CVE-2026-109618 dhe mund të ndikojë tek aplikacionet që shfaqin PHP upload progress. PHP ofron këshilla të tjera të përkohshme për rrugën out-of-memory, por të gjitha këto masa duhet të trajtohen si zgjidhje të përkohshme dhe jetëshkurtra.