Përditësimi i sigurisë për PHP rregullon dy dobësi RCE të shënjestruara aktivisht
Një përditësim sigurie për PHP trajton dy dobësi kritike që mund t’i lejojnë një sulmuesi të paautentikuar të ekzekutojë kod në një web server. Termi remote code execution (RCE) do të thotë se një sulmues mund ta bëjë sistemin e prekur të ekzekutojë komanda pa u identifikuar më parë. Dobësitë, CVE-2026-109618 dhe CVE-2026-109619, kanë secila një rezultat CVSS v4.0 prej 9.2 dhe Sucuri raportoi më 21 tetor 2026 se tashmë po vëreheshin përpjekje për shfrytëzimin e tyre.
PHP ka publikuar katër versione të rregulluara: PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 dhe PHP 8.2.35. Administratorët që përdorin serverin e tyre ose një virtual private server duhet ta instalojnë versionin e duhur përmes sistemit operativ, ofruesit të paketave, panelit të kontrollit ose procesit të përcaktuar të deployment. Klientët e shared hosting ose managed hosting duhet të konfirmojnë se ofruesi i tyre ka instaluar një PHP build të rregulluar ose një paketë që përmban një backport të qartë të rregullimeve nga ofruesi.
Këto janë dobësi në PHP runtime, software-i i serverit që ekzekuton aplikacionet PHP, dhe jo në WordPress, në një sistem tjetër të menaxhimit të përmbajtjes, në ndonjë plugin ose në ndonjë theme. Prandaj, përditësimi i WordPress core dhe i shtesave të tij nuk e eliminon sjelljen e cenueshme të serverit. Sipas njoftimit, çdo instalim PHP që u shërben kërkesave web duhet të konsiderohet si potencialisht i ekspozuar, përfshirë PHP-FPM, Apache me mod_php, php-cgi, FrankenPHP dhe LiteSpeed. PHP e konsideron mod_php konfigurimin me rrezikun më të lartë, sepse një exploit i demonstruar mund të aktivizohet nga një kërkesë e paautentikuar përpara se të fillojë ekzekutimi i kodit të aplikacionit të faqes.
CVE-2026-109618 lidhet me një out-of-memory condition, që ndodh kur një proces nuk mund të sigurojë memorien që i nevojitet. PHP mund të ndërpritet kur të dhënat e brendshme të kërkesës janë inicializuar vetëm pjesërisht. Gjatë cleanup, ai mund t’i marrë gabimisht këto të dhëna të paplota si informacion të vlefshëm, të shkaktojë memory corruption dhe potencialisht të lejojë remote code execution.
CVE-2026-109619 përfshin stale internal state. Një PHP worker, proces që trajton kërkesat e faqes, mund të ruajë një referencë te të dhënat e një kërkese pasi memoria bazë të jetë liruar. Një kërkesë e mëvonshme, e përpunuar nga i njëjti PHP worker, mund të arrijë tek informacioni i vjetruar përpara se PHP ta rivendosë atë. Rezultati mund të jetë zbulimi i informacionit ose remote code execution.
Proof-of-concept code publik, që demonstron se si mund të aktivizohet një dobësi, qarkulloi përpara se të shfaqeshin rregullimet zyrtare. Hadrian tha se po shihte shfrytëzim në shkallë të gjerë të PHP2Shell dhe raportoi se një pjesë e madhe e aktivitetit të vërejtur abuzonte me session upload-progress path të PHP. Ai paralajmëroi gjithashtu se ka të ngjarë të shfaqen rrugë të tjera shfrytëzimi. WatchTowr, Patchstack, Cloudflare dhe Vega raportuan veçmas aktivitet keqdashës ose përpjekje të lidhura me këto dobësi. Një përpjekje për exploit nuk provon në vetvete se një server është komprometuar me sukses, por kodi publik dhe vëllimi i aktivitetit e bëjnë të rëndësishëm aplikimin e shpejtë të patch-it.
Pas instalimit të përditësimit të sigurisë për PHP, administratorët duhet të rinisin ose të ringarkojnë PHP workers dhe të gjitha shërbimet përkatëse, në mënyrë që proceset aktive të përdorin build-in e ri. Më pas, ata duhet të verifikojnë versionin që po i shërben realisht faqes aktive. Versioni i shfaqur nga komanda php -v në command line mund të ndryshojë nga ai që përdor web server. Testimi duhet të përfshijë identifikimet, checkout, formularët, file uploads, scheduled tasks, application programming interfaces (APIs) dhe faqet administrative.
Faqet që përdorin PHP 8.1 ose versione më të vjetra kërkojnë kujdes shtesë. Këto degë janë jashtë ciklit normal të mbështetjes së PHP dhe nuk do të marrin point releases standarde upstream. Për shkak se këto dobësi janë të rënda, PHP publikoi source backport emergjente për PHP 7.4, PHP 8.0 dhe PHP 8.1, ndërsa distribucionet Linux dhe ofruesit e long-term support mund të ofrojnë paketat e tyre të rregulluara. Numri i shfaqur i versionit nuk mjafton për të përcaktuar nëse një instalim më i vjetër është i sigurt, sepse ofruesit mund të aplikojnë një rregullim sigurie pa ndryshuar numrin e degës. Administratorët duhet të konfirmojnë se paketa e instaluar trajton posaçërisht të dy identifikuesit CVE. Këto backport emergjente nuk e rikthejnë long-term support, ndaj kalimi në një degë PHP të mbështetur mbetet zgjidhja më e sigurt afatgjatë.
Sucuri tha se web application firewall (WAF) i saj, një shtresë filtrimi që shqyrton kërkesat përpara se ato të arrijnë te një faqe, po bllokonte tashmë disa modele keqdashëse të lidhura me dobësitë. Ajo ka shtuar rregulla më të synuara të virtual patching për rrugët e njohura të PHP2Shell. Këta filtra mund ta zvogëlojnë ekspozimin ndërsa po instalohet një përditësim, por nuk e rregullojnë vetë PHP dhe mund të bllokojnë vetëm kërkesat që njohin. PHP deklaron se instalimi i një build me patch është e vetmja zgjidhje e plotë.
Filtrimi me firewall varet gjithashtu nga kalimi i trafikut përmes tij. Nëse një sulmues mund të lidhet drejtpërdrejt me origin server, kompjuteri ku hostohet realisht faqja, rregullat e filtrimit mund të anashkalohen. Administratorët që përdorin WAF të Sucuri duhet të kufizojnë aksesin e drejtpërdrejtë IPv4 dhe IPv6, të pranojnë trafik web vetëm nga adresat e miratuara të Sucuri Firewall dhe të heqin DNS records të vjetra ose emra alternativë hosti që zbulojnë origin. Mjediset staging, development, test dhe backup kanë gjithashtu nevojë për mbrojtje ose kufizime aksesi. Ekipet duhet të kontrollojnë që subdomains të pambrojtura dhe portet alternative të mos ekspozojnë të njëjtin aplikacion dhe që containers të vjetër, server images ose autoscaling templates të mos vazhdojnë të instalojnë PHP builds të cenueshme.
Nëse patch nuk mund të aplikohet menjëherë, çaktivizimi në nivel serveri i session upload progress me `session.upload_progress.enabled = Off` mund të zvogëlojë ekspozimin ndaj rrugëve të konfirmuara që lidhen me session për CVE-2026-109619. Ky setting duhet të aplikohet përmes php.ini, një FPM pool ose një konfigurimi tjetër që ngarkohet përpara request parsing, dhe më pas duhet të riniset çdo PHP worker i prekur. Kjo është vetëm një masë e përkohshme: nuk mbulon çdo rrugë drejt CVE-2026-109619, nuk bën asgjë kundër CVE-2026-109618 dhe mund të ndikojë tek aplikacionet që shfaqin ecurinë e PHP upload. PHP ka dhënë gjithashtu udhëzime të përkohshme për rrugën out-of-memory në njoftimin e saj të plotë, por asnjë workaround nuk e bën të sigurt një instalim pa patch.
Administratorët duhet të hetojnë skedarë PHP të panjohur, scheduled tasks të papritura, llogari administratori të panjohura, lidhje dalëse të dyshimta dhe kërkesa të pazakonta që lidhen me uploads. Për pronarët e WordPress që parapëlqejnë operacione të specializuara për faqen në vend që të menaxhojnë gjithçka vetë, AEU Hosting ofron managed WordPress hosting të siguruar nga fillimi në fund; pavarësisht ofruesit, pronarët duhet të konfirmojnë përsëri se PHP build aktiv i përmban të dy rregullimet. Prioritetet e menjëhershme janë instalimi i një versioni të rregulluar ose i një backport të konfirmuar, rinisja e PHP, verifikimi i versionit web aktiv dhe sigurimi që asnjë firewall të mos mund të anashkalohet përmes aksesit të drejtpërdrejtë në origin.