Dobësitë PHP2Shell vënë në rrezik pothuajse çdo PHP web server
Dobësitë PHP2Shell i lejojnë një sulmuesi pa llogari të ekzekutojë kod përmes PHP runtime, motorit softuerik që përpunon faqet PHP në një web server. PHP ka publikuar korrigjime në versionet 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35. Këshillimi i sigurisë i PHP thotë se instalimi i një PHP runtime të përditësuar është e vetmja mbrojtje e plotë.
Dy dobësitë janë CVE-2026-109618 dhe CVE-2026-109619. Secila mori rezultatin 9.2 sipas CVSS v4.0, një shkallë standarde për vlerësimin e ashpërsisë së dobësive. Studiues nga Wiz, Calif dhe OpenAI raportuan problemet, të cilat prekin pothuajse çdo version të PHP duke nisur nga PHP 5.4. Meqenëse defektet ndodhen brenda PHP dhe jo në kodin e aplikacionit të një faqeje, edhe një faqe bazë pa logjikë komplekse aplikacioni mund të jetë e ekspozuar.
Sipas këshillimit, mënyrat e prekura të ofrimit të PHP përfshijnë PHP-FPM, Apache mod_php, php-cgi, FrankenPHP dhe LiteSpeed. Apache mod_php, ku PHP funksionon brenda Apache web server, paraqet rrezikun më të lartë të dokumentuar. Studiuesit demonstruan se një kërkesë e vetme pa autentikim mund të aktivizonte një exploit përpara se të fillonte ekzekutimi i kodit të vetë faqes. Përditësimi i WordPress, Laravel ose i një aplikacioni tjetër nuk e riparon motorin PHP që ndodhet poshtë tij.
PHP-FPM, i cili kryen punën e PHP në procese të veçanta, sillet ndryshe sepse një worker mbyllet kur një kërkesë dështon herët gjatë konfigurimit. Analiza e PHP tregon se PHP-FPM është i cenueshëm ndaj njërës dobësi, megjithëse nuk ishte demonstruar ende një exploit i plotë për atë rrugë. U tregua se dobësia tjetër arrin remote code execution, që do të thotë se komandat mund të ekzekutohen nga një sistem tjetër, si përmes mod_php, ashtu edhe përmes PHP-FPM. Rruga e saj përmes PHP-FPM varet nga një veprim i kryer nga aplikacioni që është në funksionim.
Ndikimi nuk kufizohet vetëm te marrja e kontrollit të një procesi. Studiuesit demonstruan gjithashtu leximin e memories aktive nga PHP workers kundër aplikacioneve që ata nuk i kontrollonin. Kjo memorie mund të përmbajë fjalëkalime, authentication tokens, API keys dhe certifikata që lidhen me kërkesa të tjera. Kjo teknikë nuk kërkon që sulmuesi të arrijë më parë ekzekutimin e kodit dhe nuk varet nga ndonjë dobësi në aplikacionin e instaluar mbi PHP.
Administratorët duhet të instalojnë PHP 8.5.12, 8.4.27, 8.3.36 ose 8.2.35, në varësi të branch që përdoret. Më pas duhet të rinisin Apache, PHP-FPM dhe çdo PHP worker tjetër afatgjatë, në mënyrë që të ngarkohet kodi i korrigjuar. PHP 8.1 dhe versionet më të vjetra nuk mbështeten më nga projekti PHP, megjithëse ekipi i tij i sigurisë publikoi source backports, pra korrigjime të përshtatura për kod më të vjetër, për PHP 7.4, 8.0 dhe 8.1. PHP 8.2 është planifikuar të arrijë end of life më 31 dhjetor 2026.
Linux distributions dhe furnizuesit e mbështetjes afatgjatë i morën patches paraprakisht. Për këtë arsye, packages e tyre mund ta përmbajnë korrigjimin, ndërkohë që ruajnë një numër versioni PHP që duket më i vjetër. Debian këshillon kontrollimin e package changelog për identifikuesin përkatës CVE, në vend që të mbështeteni vetëm te versioni i shfaqur.
Ndryshimet e përkohshme të konfigurimit trajtojnë vetëm pjesë të attack surface. Për CVE-2026-109618, këshillimi rekomandon vendosjen e memory_limit=-1, në mënyrë që aplikacionet të mos mund ta ndryshojnë, mbajtjen e post_max_size në nivel të ulët dhe kufizimin e madhësive të kërkesave në web server ose proxy. PHP paralajmëron që RLIMIT_AS ose RLIMIT_DATA të mos trajtohen si zëvendësues, sepse mund të aktivizojnë të njëjtën rrugë të cenueshme. Për CVE-2026-109619, administratorët mund të vendosin session.upload_progress.enabled=0 dhe të rinisin çdo worker. Sistemet PHP 8.5 duhet të vendosin gjithashtu fatal_error_backtraces=0. Çaktivizimi i session upload progress bllokon rrugët e konfirmuara që lidhen me session, por jo çdo variant të mundshëm, dhe nuk bën asgjë për CVE-2026-109618.
Përditësimi vendos një kufi të prerë të memories. Nëse ky kufi arrihet, PHP e përfundon procesin pa ekzekutuar shutdown handlers, të cilat janë detyra që normalisht kryhen kur një kërkesë mbyllet. Prandaj, pas instalimit të patch, administratorët duhet të rishikojnë memory_limit dhe post_max_size kundrejt kërkesave legjitime të aplikacioneve të tyre. Për të zbuluar një komprometim të mundshëm më të hershëm, studiuesit rekomandojnë kërkimin e multipart requests të pazakonta, të cilat përdoren zakonisht për ngarkimin e skedarëve dhe të formularëve, të pasuara nga gabime të kufirit të memories ose gabime të përsëritura HTTP 500 të serverit. Shenja të tjera paralajmëruese përfshijnë cookies përgjigjeje PHPSESSID me madhësi të madhe të papritur dhe rinisje të pashpjegueshme të PHP workers.
Është vërejtur tashmë trafik sulmesh, por në kohën e përditësimit më të fundit nuk ishte konfirmuar komprometimi i ndonjë serveri specifik. Cloudflare raportoi sulme të hershme dhe më pas tha se sulmuesit ndryshuan payloads e tyre për t’iu shmangur rregullave të firewall që kompania i aktivizoi si parazgjedhje në orën 03:02 UTC më 21 tetor. Kompania i përshkroi këto rregulla si masë të përkohshme dhe bëri thirrje për instalimin e patch. watchTowr fillimisht raportoi në orën 11:26 UTC se nuk kishte exploitation in the wild, por më pas, në orën 14:19 UTC, tha se po shihte përpjekje aktive kundër të dyja dobësive. Në atë moment të mëparshëm, asnjëra CVE nuk ishte në katalogun Known Exploited Vulnerabilities të CISA.
Disa shërbime u nxorën jashtë funksionit si masë paraprake dhe jo për shkak të një ndërhyrjeje të konfirmuar. BambooHR pezulloi shërbimin në Shtetet e Bashkuara, Kanada dhe Irlandë, duke paralajmëruar se përpunimi i pagave do të ndërpritej, pa dhënë një afat për rikthimin e shërbimit. Sipas NOS, jashtë funksionit dolën gjithashtu shërbime holandeze, duke përfshirë MijnOverheid, DigiD, faqen e internetit të dhomës së ulët të parlamentit, qendrën kombëtare të sigurisë kibernetike dhe disa sisteme arsimore. Qendra tha se nuk kishte vërejtur abuzim, por këshilloi organizatat të instalonin patch.
Orari i publikimit u ndërpre përpara se korrigjimet të bëheshin të disponueshme. Një postim në Hacker News më 20 tetor përmendi të dyja CVE-të dhe pretendoi se publikimi i tyre ishte planifikuar për më 22 tetor. PHP dha një njoftim paraprak atë mbrëmje dhe e zhvendosi publikimin afërsisht në orarin e planifikuar të versionit të ri, në orën 14:00 UTC më 21 tetor. PHP i vlerëson të dyja dobësitë me 9.2 dhe jo me rezultatin 10.0 të pretenduar në rrjedhjen e informacionit. PHP Foundation tha më vonë se Calif publikoi gabimisht një video të një proof of concept funksional rreth orës 20:00 UTC më 20 tetor. Më pas, Chainguard publikoi built images që përmbanin patch në orën 07:41 UTC më 21 tetor, afërsisht gjashtë orë përpara korrigjimit zyrtar, duke bërë të mundur që ndryshimet të studioheshin ndërsa përdorues të tjerë ende prisnin.
Kodi i cenueshëm kishte ekzistuar për më shumë se një dekadë. PHP Foundation tha se një zhvillues i core kishte vënë re shenja të problemit out-of-memory pas CVE-2026-109618 gjatë një auditimi të jashtëm në vitin 2024, por në atë kohë nuk ishte përcaktuar ndonjë rrugë konkrete drejt ekzekutimit të kodit. Riparimet e propozuara rrezikonin të shkaktonin probleme pajtueshmërie, kushte denial-of-service ose ndryshime për extensions të palëve të treta, dhe puna ngeci ndërsa ekipi i vogël përpiqej të arrinte një vendim. Foundation e përshkroi këtë si një dështim strukturor dhe tha se që atëherë ka ndryshuar vendimmarrjen e vet për sigurinë, duke shtuar njëkohësisht staf dhe mjete.
Raportet e paraqitura në vitin 2026 nga Calif, OpenAI dhe Wiz vërtetuan një exploit funksional dhe rritën përparësinë e dobësisë. Studiuesit thanë se modelet e inteligjencës artificiale ndihmuan një studiues të përfundonte brenda rreth një jave punën për të cilën ata besonin se, në të kundërt, një ekipi do t’i duheshin muaj.