Sulmet PHP2Shell vazhdojnë, pa u konstatuar komprometim të WordPress
Sulmet PHP2Shell po vazhdojnë, por deri më 28 tetor 2026, Wordfence nuk dinte për asnjë faqe WordPress të komprometuar përmes CVE-2026-109618 ose CVE-2026-109619. Ekipet e saj të pastrimit të faqeve dhe reagimit ndaj incidenteve nuk kishin trajtuar asnjë rast WordPress që i atribuohej ndonjërës prej këtyre cenueshmërive. Ky konstatim nuk do të thotë se një server pa përditësimet përkatëse është i sigurt: veprimi i nevojshëm mbetet përditësimi i gjuhës së programimit PHP që përdoret nga faqja dhe rinisja e shërbimit që e ekzekuton atë.
Dy cenueshmëritë kritike të PHP morën secila një vlerësim prej 9.2 nga 10 sipas CVSS v4.0, një shkallë standarde për vlerësimin e cenueshmërive të sigurisë. Të dyja mund të mundësojnë remote code execution pa autentikim, që do të thotë se dikush që nuk është identifikuar mund të jetë në gjendje të ekzekutojë kodin e vet në server. Njëra cenueshmëri lidhet me mënyrën se si PHP trajton një kërkesë që shteron memorien e disponueshme. Tjetra mund të lërë të dhëna nga një kërkesë e përfunduar brenda një procesi PHP, duke i lejuar një kërkese të mëvonshme t'i keqpërdorë ato. Këto janë cenueshmëri në vetë PHP, jo në WordPress, plugins ose themes.
Wordfence tha se një rregull i posaçëm monitorimi regjistroi rreth 77,600 kërkesa të lidhura me këto cenueshmëri nga më shumë se 2,000 adresa IP, nga 23 deri më 27 tetor, në mbi 5 milionë faqet që ndihmon të sigurohen. Shqyrtimi i saj nuk gjeti përputhje që ngjanin me aktivitet normal të vizitorëve ose të faqeve. Kërkesat përmbanin tregues sulmi, identifikoheshin si mjete skanimi ose dukeshin si teste të automatizuara. Më 22 tetor u vëzhgua gjithashtu një grup i koordinuar prej 27 adresash IP, ku 26 prej tyre i nisën kërkesat brenda një periudhe 13-minutëshe. Kërkesa të tilla tregojnë aktivitet të tentuar, jo nëse kodi u ekzekutua vërtet.
Kërkesat u përpoqën të kontrollonin nëse mund të ekzekutoheshin komanda, të nxirrnin fjalëkalime të databazës dhe sekrete të tjera nga skedarët wp-config.php dhe .env, të instalonin skedarë backdoor për qasje të vazhdueshme në direktoritë e uploads, plugins ose themes dhe, më rrallë, të shkarkonin e ekzekutonin kod tjetër keqdashës. Wordfence pa gjithashtu mjete të krijuara për këto cenueshmëri rreth katër orë përpara publikimit të informacionit më 21 tetor. Edhe Amazon raportoi tentativa kundër honeypots të saj, të cilat janë sisteme karrem që përdoren për të vëzhguar sulmet, përpara publikimit të informacionit.
Raportimet jashtë WordPress mbeten të përziera. Dream tha se një sulmues përshtati një PHP2Shell exploit për një platformë firewall të paidentifikuar dhe më pas përdori një cenueshmëri privilege escalation në kernel Linux, e cila i lejon një sulmuesi të marrë leje më të larta në sistem. Sipas Dream, sulmuesi mori kontroll të plotë mbi 24 firewalls të ekspozuar në internet dhe një server të brendshëm menaxhimi, nxori fjalëkalimin e një llogarie shërbimi LDAP dhe listoi përdoruesit dhe grupet në një mjedis të lidhur me qeverinë amerikane. Dream nuk e identifikoi prodhuesin dhe nuk i publikoi artefaktet e rikuperuara, ndërsa Wordfence nuk e kishte verifikuar në mënyrë të pavarur incidentin. Ai nuk përfshinte WordPress.
Veçmas, Palo Alto Networks raportoi shfrytëzim aktiv të drejtuar ndaj ndërfaqeve të menaxhimit PAN-OS të ekspozuara në internet, pa e lidhur këtë aktivitet me raportimin e Dream. Wiz tha më 27 tetor se asnjë nga tentativat që kishte vëzhguar nuk pati sukses dhe se provat më të forta publike që kishte shqyrtuar përfshinin sulme të suksesshme ndaj honeypots. Morphisec raportoi më 28 tetor code execution te një klient që përdorte Windows, IIS dhe PHP-CGI, një konfigurim në të cilin PHP përpunon kërkesat web përmes Common Gateway Interface. Raportimi i saj publik nuk përfshinte WordPress dhe nuk përmbante hollësi të mjaftueshme teknike që Wordfence të verifikonte në mënyrë të pavarur nëse përgjegjës ishte PHP2Shell.
Shfrytëzimi i besueshëm duket se varet shumë nga objektivi. Në laboratorin e Wordfence, kodi i testimit u ekzekutua kundër një PHP build të konfiguruar posaçërisht, por vetëm shkaktoi crash të një build normal të optimizuar të të njëjtit version. Wiz raportoi dështime në faza të ndryshme në konfigurime të ndryshme, ndërsa Hacktron zbuloi se një exploit që funksiononte në një mjedis kërkonte ndryshime të konsiderueshme për një mjedis tjetër. PHP builds, extensions, kufijtë e memories dhe trajtimi i kërkesave mund të ndikojnë të gjitha në rezultat. Address Space Layout Randomization, ose ASLR, ndryshon gjithashtu vendin ku një program ruan të dhënat në memorie, duke e bërë më të vështirë parashikimin e objektivit nga sulmuesi. Administratorët Linux mund të ekzekutojnë cat /proc/sys/kernel/randomize_va_space; rezultati 2 nënkupton randomizim të plotë. Këto pengesa mund ta vështirësojnë një sulm, por nuk korrigjojnë asnjërën cenueshmëri.
Versionet e korrigjuara të PHP janë 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35. Njoftimi i PHP thotë se çdo instalim që shërben kërkesa web është në rrezik, përfshirë PHP-FPM, Apache me mod_php, php-cgi, FrankenPHP dhe LiteSpeed. PHP-FPM është një shërbim që menaxhon proceset PHP për faqet web. Një paketë e prodhuesit është gjithashtu e pranueshme nëse ofruesi i saj konfirmon se janë shtuar të dyja korrigjimet. Përditësimi i vetë WordPress nuk do ta përditësojë PHP.
Në hosting të menaxhuar ose të përbashkët, pronarët e faqeve duhet të pyesin nëse shërbimit PHP për llogarinë e tyre i janë aplikuar korrigjimet për të dyja CVE-të dhe nëse është rinisur. Administratorët e serverit të tyre ose të një virtual private server, që zakonisht quhet VPS, duhet të krijojnë një backup, të instalojnë paketat e përditësuara dhe të rinisin Apache, PHP-FPM ose shërbimin përkatës PHP, në mënyrë që një proces i vjetër të mos vazhdojë të përdorë kodin e cenueshëm. Containers duhet të rindërtohen dhe të rivendosen nga një image e përditësuar. Agjencitë duhet të kontrollojnë mjediset production, staging dhe ato më të vjetra, jo vetëm faqen kryesore publike.
WordPress e tregon versionin PHP te Tools, Site Health, Info dhe më pas Server. Kjo vlerë mund të ndryshojë nga rezultati i php -v në një command prompt. Vetëm numri i versionit mund të mos e sqarojë çështjen, sepse Linux distributions dhe ofruesit e long-term support ndonjëherë shtojnë security patches pa ndryshuar versionin kryesor. Pronarët që shohin një numër më të vjetër duhet të pyesin nëse ajo paketë e saktë i përmban të dyja korrigjimet.
Shenjat paralajmëruese përfshijnë skedarë PHP të panjohur në wp-content/uploads ose në direktoritë e plugins dhe themes, veçanërisht skedarë të krijuar më 17 tetor ose pas kësaj date, llogari administratori të panjohura, detyra të planifikuara të papritura, lidhje dalëse të pashpjegueshme, crashes të përsëritura të PHP, uploads formularësh me madhësi jashtëzakonisht të madhe ose një proces PHP apo web-server që nis një command shell. Ruani backups dhe logs të web, PHP, firewall dhe sistemit, të paktën që nga 17 tetori deri në momentin kur PHP u korrigjua dhe u rinis. Një log që duket normal nuk provon se nuk ka ndodhur asgjë. Nëse shfaqen prova të dyshimta, ruajeni faqen aktuale si backup, ndryshoni fjalëkalimin e databazës dhe sekretet e ruajtura në wp-config.php ose .env dhe filloni një pastrim të plotë.
PHP 8.1 dhe versionet më të hershme nuk marrin më releases nga projekti PHP, prandaj përdoruesve të prekur u nevojitet një korrigjim i ofruar nga prodhuesi ose një upgrade. Source patches minimale u publikuan për PHP 7.4, 8.0 dhe 8.1, ndërsa disa ofrues të long-term support mund t'i shtojnë ato në paketat më të vjetra. PHP 8.2 arrin end of life më 31 dhjetor 2026, duke e bërë PHP 8.3 ose një version të mëvonshëm rrugën afatgjatë të upgrade të përshkruar nga Wordfence.
Një cenueshmëri tjetër e pakorrigjuar, CVE-2026-115560, u publikua më 23 tetor. Ajo zbatohet vetëm kur një aplikacion ndryshon formatin e të dhënave të session në PHP ndërsa është duke u ekzekutuar dhe më pas nis një session ndërkohë që session upload progress është aktivizuar.