Siguri

PHP2Shell: RCE kritike pa autentikim në PHP — çfarë duhet bërë

Nga Creaks Agency 23 Tet 2026
PHP2Shell: RCE kritike pa autentikim në PHP — çfarë duhet bërë

Dy cenueshmëri kritike të zbuluara këtë javë në vetë motorin e PHP-së — CVE-2026-109618 dhe CVE-2026-109619, të njohura si PHP2Shell — i lejojnë një sulmuesi anonim të ekzekutojë kodin e tij në serverin tuaj përpara se kodi i aplikacionit tuaj të ekzekutohet fare. Të dyja vlerësohen CVSS v4.0 9.2 nga 10, asnjëra nuk kërkon autentikim, dhe mangësitë janë në çdo version PHP që nga 5.4 (2012). Rreth 70% e web-it punon mbi PHP. Që kodi juaj të jetë i pastër nuk ju mbron.

Si u zhvillua java

Detajet u rrjedhën në rrjetet sociale përpara një zbulimi të koordinuar të planifikuar për 22 Tetor, kështu që ekipi i PHP-së e nxori release-in e urgjencës përpara, më 21 Tetor në 14:00 UTC. Trafiku i sulmit po mbërrinte edhe para se patch-i të ekzistonte — Cloudflare regjistroi proba në 07:43 atë mëngjes, gjashtë orë më parë. Një mjet exploit publik pritet së shpejti.

Trafik sulmi i vënë re para se patch-i të ekzistonte Pritet shfrytëzim masiv mjeti exploit pritet së shpejti Kodi i cenueshëm del hyri me PHP 5.4.0 Njoftim paraprak detajet u rrjedhën herët 8.5.12 / 8.4.27 8.3.36 / 8.2.35 2012 20 Tet 21 Tet · 07:43 UTC 21 Tet · 14:00 UTC 22 Tet → Patch-at u publikuan
Fig. 1 — Kronologjia e zbulimit. Probat e sulmit u regjistruan përpara se patch-i të ekzistonte (burimi: php.net, Cloudflare, Sansec).

CVE-2026-109618: ekzekutim kodi nëpërmjet shterjes së kujtesës

Kur dështon rezervimi i kujtesës në mes të një kërkese, PHP mund ta braktisë kërkesën ndërsa strukturat e brendshme janë vetëm pjesërisht të inicializuara. Rutinat e pastrimit ekzekutohen gjithsesi — dhe e trajtojnë atë të dhënë të pavlefshme e gjysmë të ndërtuar sikur të ishte e vlefshme. Sulmuesi e detyron këtë gjendje me një kërkesë multipart të sajuar që e shteron kujtesën duke dukur se hyn në limitet e konfiguruara.

Nën Apache mod_php, pastrimi ekzekutohet edhe kur dështon nisja e kërkesës, pra exploit-i shpërthen përpara se çdo rresht i aplikacionit tuaj të ekzekutohet — përmes HTTP të thjeshtë, me limitet e parazgjedhura, në çdo worker prefork.

CVE-2026-109619: ekzekutim kodi nëpërmjet gjendjes së vjetër

Gjendja e brendshme që i takon një kërkese mund të mbijetojë pasi kujtesa e saj të jetë çliruar. Kërkesa tjetër që e trajton i njëjti worker mund ta përdorë atë gjendje të vjetër përpara se inicializimi normal ta zerojë — një use-after-free i kthyer në ekzekutim kodi, i vërtetuar si për mod_php ashtu edhe për PHP-FPM.

Rrugët e konfirmuara të sulmit nuk kërkojnë gjë ekzotike: progresi i ngarkimit të sesionit (aktiv si parazgjedhje — aplikacioni s’ka nevojë të thërrasë session_start()) dhe, në PHP 8.5, backtrace-et e gabimeve fatale (gjithashtu të aktivizuara si parazgjedhje).

CVE-2026-109618 Kërkesë multipart e sajuar hyn në limite, shteron kujtesën OOM në mes të inicializimit të dhënat gjysmë të ndërtuara procesimi braktiset Pastrimi ekzekutohet gjithsesi edhe në dështim nisjeje (mod_php) Të dhëna pavlefshme si të vlefshme → RCE para kodit të aplikacionit pa autentikim, rregullime parazgjedhje CVE-2026-109619 Kërkesa A gabim fatal / backtrace / progres ngarkimi sesioni Kërkesa mbaron kujtesa çlirohet, por referencat e vjetruara mbeten Kërkesa B — i njëjti worker lexon gjendjen e vjetër para reinicializimit Use-after-free → RCE + zbulim kujtese “ngjashëm me Heartbleed” funksionon në mod_php dhe PHP-FPM
Fig. 2 — Mekanika e sulmit. Të dyja rrugët përfundojnë në ekzekutim kodi pa autentikim; 109619 lejon gjithashtu leximin e kujtesës së worker-it.

Kush është i prekur

Çdo instalim PHP që shërben kërkesa web — PHP-FPM, Apache mod_php, php-cgi, FrankenPHP dhe LiteSpeed; mod_php me rrezikun më të lartë. Ekzekutim kodi pa autentikim u demonstrua kundër softuerit real: Magento 2.4.9, WordPress 7.1.2, Drupal 11.4.3, Joomla 6.1.4, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony dhe WHMCS. Meqë cenueshmëria është në motor, asgjë nuk ndryshon nga fakti që aplikacioni është pa gabime.

Nuk është vetëm ekzekutim kodi. Kërkuesit demonstruan gjithashtu zbulimin e kujtesës së worker-it pa autentikim — fjalëkalime, token-ë sesioni, çelësa API dhe çelësa privatë TLS — të arritshme përmes një cookie-je sesioni PHP. Çdo ekspozim para patch-imit trajtojeni si rrjedhje e mundshme sekretesh.

Çfarë nuk ju mbron

24 orët e para prodhuan një valë këshillash që shkojnë nga të padobishmet deri te aktivisht dëmtueshmet. Dështimet e dokumentuara:

Limitet RLIMIT_AS / RLIMIT_DATA. Aktivisht dëmtuese — mund të shkaktojnë pikërisht dështimin e rezervimit që aktivizon CVE-2026-109618. Prodhuesi paralajmëron shprehimisht kundër tyre.

Fshehja e gabimeve me error_reporting, display_errors ose @. Kjo ndryshon atë që shihni ju, jo atë që bën motori; nuk pengon qasjen në gjendjen e vjetër.

Vendosja e session.upload_progress.enabled=0 me ini_set() ose .user.ini. Shumë vonë — zbatohen pasi analiza e kërkesës ta ketë prekur tashmë rrugën e cenueshme. Rregullimi duhet bërë në mënyrë administrative, përpara analizës, e pastaj worker-ët të rinisën.

Limiti i kujtesës container/cgroup si zgjidhje. Dështimet e rezervimit mbeten të mundshme; në rastin më të mirë është kufi disponueshmërie, dhe nëse worker-ët nuk izolohen mund të vrasë master-in dhe të gjithë worker-ët njëherësh.

Të besuarit WAF-it. Exploit-i udhëton me trafik multipart normal në pamje brenda limiteve të zakonshme; Cloudflare vuri re tashmë përpjekje për ta shmangur. WAF-i është mbrojtje shtesë, jo zgjidhje.

“S’ka logje të dyshimta, pra jemi të sigurt.” Mungesa e regjistrave nuk është provë sigurie — një shfrytëzim i suksesshëm i korruptimit të kujtesës nuk lë pas gabime PHP treguese.

Pritja e dritares së radhës së patch-eve. Trafiku i sulmit është edhe më i vjetër se patch-i vetë; ky është përditësim urgjence, jashtë ciklit.

Si mbroheni

Një fjali e këshillës zyrtare qeverison gjithçka: “Nuk ka zbutje të plota — përditësimi është zgjedhja e vetme e sigurt.” Përditësoni në PHP 8.5.12, 8.4.27, 8.3.36 ose 8.2.35 sipas degës suaj — publikuar më 21 Tetor; te php.net, distribucioni juaj Linux apo ofruesi LTS dhe imazhet zyrtare Docker. Për PHP 8.1, 8.0 e 7.4 ka vetëm backport-e nga kodi; depoja e Remi nuk ka asgjë.

Pas patch-imit: rinis çdo worker PHP dhe verifiko versionin në ekzekutim, jo versionin e paketës (php-fpm -i ose një faqe phpinfo()). Pastaj ndryshoni sekretet e arritshme nga shtresa web — fjalëkalime baze të dhënash, çelësa API dhe, nëse ekspozimi para patch-imit është i besueshëm, çelësat privatë TLS. Kontrollo rrënjët web për skedarë të papritur dhe planifiko daljet: PHP 8.2 arrin fundin e jetës më 31 Dhjetor 2026.

Nëse nuk mund ta patch-oni sot

Këto ngushtojnë rrugë të caktuara sulmi ndërsa planifikoni përditësimin; nuk e bëjnë të sigurt një instalim të pa-patch-uar. Zbatoni rregullimet në shtresën administrative (php.ini, pool FPM ose konfigurim Apache) që aplikacionet të mos mund t’i anashkalojnë, rinis worker-ët dhe kini parasysh se secila ka kosto.

; --- CVE-2026-109618: hiq aktivizuesin e parashikueshëm OOM ---
memory_limit = -1              ; vetëm në nivel administrativ; verifiko që asgjë nuk rikthen limit të fundit
post_max_size = 8M             ; 32M nëse ju duhen ngarkime; mbaje upload_max_filesize nën të
; --- CVE-2026-109619: mbyll rrugët e konfirmuara të gjendjes së vjetër ---
session.upload_progress.enabled = 0
fatal_error_backtraces = 0     ; vetëm PHP 8.5
; opsionale, me kosto performance:
; pm.max_requests = 1          ; FPM: worker i ri për çdo kërkesë

Për të lexuar më tej

Burimi autoritativ është njoftimi zyrtar në php.net, me këshillat e veçanta GHSA-w8hw-w9fx-j79w dhe GHSA-6wmf-4rv5-p3rp. Analiza të reagimit të parë që ia vlen të lexohen: Qualys, Rapid7, Sansec, watchTowr, CERT-EU 2026-018 dhe njoftimi i NCSC-UK.