Sulmet PHP2Shell vazhdojnë pa raste të konfirmuara në WordPress
PHP2Shell po vazhdon të shfrytëzohet në tentativa sulmi, por Wordfence thotë se, deri më 28 tetor 2026, nuk kishte dijeni për asnjë komprometim të konfirmuar të WordPress përmes dy dobësive kritike në PHP. PHP është gjuha e programimit mbi të cilën funksionon WordPress. Mungesa e një rasti të konfirmuar nuk e bën të sigurt një server të pakorrigjuar: reagimi i nevojshëm është instalimi i PHP 8.5.12, 8.4.27, 8.3.36 ose 8.2.35, ose i një pakete nga furnizuesi që është konfirmuar se përfshin të dyja korrigjimet, dhe më pas rinisja e PHP.
PHP2Shell është pseudonimi për CVE-2026-109618 dhe CVE-2026-109619. Secila mori vlerësimin 9.2 nga 10 sipas CVSS v4.0, një shkallë standarde për vlerësimin e ashpërsisë së dobësive. Të dyja dobësitë mund të lejojnë remote code execution pa autentikim, që do të thotë se dikush që nuk është identifikuar në sistem mund të jetë në gjendje të ekzekutojë kodin e vet në server. Njëra dobësi lidhet me mënyrën se si PHP trajton një kërkesë që shteron memorien e disponueshme. Tjetra përfshin një proces PHP që ruan të dhëna nga një kërkesë e përfunduar, të cilat mund të keqpërdoren nga një kërkesë e mëvonshme. Këto janë dobësi në vetë PHP, jo në WordPress, në një theme apo në një plugin.
Wordfence analizoi logs nga më shumë se 5 milionë faqe të mbrojtura dhe tha se ekipet e saj për pastrimin e faqeve dhe reagimin ndaj incidenteve nuk kishin trajtuar asnjë shkelje të WordPress që t’i atribuohej ndonjërës prej dobësive. Një rregull i posaçëm monitorimi regjistroi rreth 77.600 kërkesa të lidhura me to, nga më shumë se 2.000 adresa IP, ndërmjet 23 dhe 27 tetorit. Wordfence shqyrtoi çdo përputhje dhe gjeti shenja sulmesh, mjete skanimi që identifikoheshin vetë ose forma të tjera testimi të automatizuar, dhe jo aktivitet normal të vizitorëve apo të faqeve. Gjithashtu, më 22 tetor vëzhgoi 27 adresa IP të koordinuara, prej të cilave 26 i nisën kërkesat brenda një periudhe prej 13 minutash.
Kërkesat tentuan të ekzekutonin komanda që do të tregonin nëse shfrytëzimi kishte funksionuar, të nxirrnin fjalëkalime të bazës së të dhënave dhe sekrete të tjera nga skedarët e konfigurimit wp-config.php dhe .env, si dhe të krijonin backdoors në direktoritë upload, plugin ose theme. Një backdoor është një skedar ose mekanizëm i fshehur që i lejon një ndërhyrësi të rikthehet më vonë. Më rrallë, kërkesat u përpoqën të shkarkonin dhe ekzekutonin kod tjetër keqdashës. Këto të dhëna tregojnë synimin e sulmuesve, jo ekzekutim të suksesshëm. Amazon raportoi gjithashtu tentativa kundër honeypots, të cilat janë sisteme karrem që përdoren për të vëzhguar sulmet, përpara publikimit të informacionit më 21 tetor. Wordfence pa mjete të krijuara për këto dobësi rreth katër orë përpara atij publikimi.
Raportimet jashtë WordPress mbeten të rëndësishme, por përmbajnë pyetje të pazgjidhura. Dream tha se një sulmues e përshtati PHP2Shell për një platformë firewall të paemërtuar dhe më pas përdori një dobësi privilege escalation në Linux kernel për të marrë kontrollin e plotë të 24 firewalls të ekspozuar në internet dhe të një serveri të brendshëm menaxhimi. Dream tha se sulmuesi nxori fjalëkalimin e një llogarie shërbimi LDAP, që përdorej për qasje në një direktori qendrore përdoruesish, dhe inventarizoi përdoruesit dhe grupet në një mjedis të lidhur me qeverinë amerikane. Raporti publik nuk e identifikoi furnizuesin dhe nuk paraqiti artefakte të rikuperuara, ndërsa Wordfence tha se nuk e kishte verifikuar në mënyrë të pavarur. Palo Alto Networks raportoi veçmas shfrytëzim aktiv kundër interface-ve të menaxhimit PAN-OS të ekspozuara në internet, pa e lidhur atë aktivitet me raportin e Dream.
Wiz raportoi më 27 tetor se asnjëra nga tentativat që kishte vëzhguar nuk ishte përfunduar me sukses dhe tha se prova më e fortë publike që kishte shqyrtuar përfshinte shfrytëzimin e suksesshëm të honeypots. Më 28 tetor, Morphisec raportoi code execution në serverin Windows të një klienti që përdorte IIS, softuerin web-server të Microsoft, dhe PHP-CGI, një metodë për ekzekutimin e PHP për kërkesa web. Raporti i saj publik nuk përfshinte WordPress dhe nuk jepte hollësi të mjaftueshme teknike që Wordfence të verifikonte në mënyrë të pavarur se incidenti ishte shkaktuar nga PHP2Shell.
Shfrytëzimi i besueshëm duket se varet ndjeshëm nga konfigurimi i objektivit. Wordfence zbuloi se një exploit testues ekzekutonte kod në një build PHP të konfiguruar posaçërisht, por vetëm shkaktonte crash në një build normal të optimizuar të të njëjtit version. Wiz raportoi dështime në faza të ndryshme në konfigurime të ndryshme serverësh, ndërsa Hacktron zbuloi se një exploit që funksiononte në një mjedis kërkonte modifikime të konsiderueshme për një tjetër. Faktorët përfshijnë build-in e PHP, extensions e instaluara, kufijtë e memories, trajtimin e kërkesave dhe ASLR, ose Address Space Layout Randomization, që ndryshon vendin ku një program ruan të dhënat në memorie, në mënyrë që sulmuesi ta ketë më të vështirë të parashikojë se ku duhet të synojë. Në Linux, administratorët mund të ekzekutojnë cat /proc/sys/kernel/randomize_va_space; rezultati 2 tregon randomizim të plotë. Këto pengesa mund ta vështirësojnë shfrytëzimin në shkallë të gjerë, por nuk e zëvendësojnë instalimin e korrigjimeve.
Sipas këshillimit të sigurisë nga PHP, çdo instalim PHP që u shërben kërkesave web është në rrezik, duke përfshirë PHP-FPM, Apache me mod_php, php-cgi, FrankenPHP dhe LiteSpeed. Prandaj, një instalim i përditësuar i WordPress mund të mbetet i ekspozuar, sepse përditësimi i WordPress nuk e përditëson PHP. Në WordPress, Tools, Site Health, Info, Server tregon versionin që po i shërben realisht faqes, i cili mund të ndryshojë nga rezultati i php -v në një command prompt. Një version që duket më i vjetër nuk është gjithmonë provë përfundimtare, sepse distribucionet Linux dhe furnizuesit e mbështetjes afatgjatë ndonjëherë shtojnë korrigjime sigurie pa ndryshuar numrin kryesor të versionit. Në atë rast, ofruesi i hosting ose furnizuesi duhet të konfirmojë se paketa e tij përmban të dyja korrigjimet.
Në hosting të menaxhuar ose të përbashkët, pronarët e faqeve duhet të pyesin nëse shërbimi PHP për llogarinë e tyre specifike është korrigjuar për të dyja CVE-të dhe është rinisur. Administratorët e serverit të tyre ose të një virtual private server, një mjedis serveri me qira, duhet të krijojnë një kopje rezervë, të instalojnë paketat e përditësuara dhe të rinisin Apache, PHP-FPM ose shërbimin përkatës PHP, në mënyrë që proceset e vjetra të mos mbajnë kodin e cenueshëm. Containers duhet të rindërtohen dhe të vendosen sërish nga një image i përditësuar. Agjencitë duhet të kontrollojnë mjediset publike, staging dhe të vjetra, në vend që të inspektojnë vetëm faqen kryesore.
PHP 8.1 dhe versionet më të vjetra nuk marrin më përditësime nga projekti PHP, ndaj përdoruesve u duhet ose një korrigjim i ofruar nga furnizuesi, ose një upgrade. Disa distribucione Linux dhe furnizues të mbështetjes afatgjatë kanë shtuar korrigjime në release më të vjetra, ndërsa ekipi i sigurisë së PHP publikoi source patches minimale për PHP 7.4, 8.0 dhe 8.1. Një release i mbështetur është zgjedhja më e mirë afatgjatë. PHP 8.2 arrin end of life më 31 dhjetor 2026, ndaj PHP 8.3 ose një version më i ri shmang një tjetër migrim në të ardhmen e afërt.
Pronarët e faqeve duhet të kontrollojnë për skedarë PHP të panjohur në wp-content/uploads dhe në dosjet plugin ose theme, veçanërisht skedarë të krijuar më 17 tetor ose pas kësaj date. Shenja të tjera paralajmëruese përfshijnë llogari administratori të panjohura, skedarë konfigurimi të ndryshuar, cron jobs të papritura, që janë detyra të planifikuara automatikisht, lidhje dalëse të pashpjegueshme, crashes të përsëritura të PHP, ngarkime formularësh me përmasa jashtëzakonisht të mëdha ose një proces web që nis një command shell. Ruani kopjet rezervë dhe logs të web-server, PHP, firewall dhe sistemit, të paktën që nga 17 tetori deri në momentin kur u rinis shërbimi i korrigjuar PHP. Fakti që një log duket i pastër nuk provon se nuk ka ndodhur asgjë.
Nëse shfaqen prova të dyshimta, fillimisht krijoni një kopje rezervë të gjendjes aktuale të faqes për të ruajtur provat.