Korrigjimet e dobësive në PHP mbyllin dy të meta kritike RCE
Dobësia në PHP e korrigjuar më 21 tetor 2026 përbëhet nga dy të meta kritike që mund t’i lejojnë një sulmuesi të paautentikuar, pra dikujt që nuk është identifikuar, të ekzekutojë nga larg kod në një server web. PHP publikoi versionet 8.5.12, 8.4.27, 8.3.36 dhe 8.2.35 për të trajtuar të dyja problemet. Faqet web që përdorin WordPress, Drupal, Magento, Joomla, Laravel ose çfarëdo aplikacioni tjetër PHP janë të ekspozuara kur instalimi bazë i PHP mbetet i cenueshëm.
Rreziku prek mënyrat kryesore me të cilat PHP përpunon kërkesat web, duke 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ë kërkesë keqdashëse mund të arrijë te e meta përpara se të fillojë ekzekutimi i kodit të vetë aplikacionit të faqes. Problemi ndodhet brenda PHP interpreter, software-it që ekzekuton kodin PHP, dhe jo në një sistem të caktuar për menaxhimin e përmbajtjes ose në një plugin.
Të metat janë CVE-2026-109618 dhe CVE-2026-109619, secila e vlerësuar Critical me rezultatin 9.2 sipas CVSS v4.0, një sistem standard për përshkrimin e ashpërsisë së dobësive. CVE-2026-109618 lidhet me out-of-memory handling. PHP mund të ndërpritet ndërkohë që informacioni i brendshëm i kërkesës është përgatitur vetëm pjesërisht, pas së cilës procesi i pastrimit mund ta trajtojë gabimisht informacionin e pavlefshëm si të ligjshëm. CVE-2026-109619 lejon që informacioni i brendshëm specifik për kërkesën të mbetet pasi memoria e tij të jetë liruar. Një kërkesë e mëvonshme, e përpunuar nga i njëjti worker, procesi PHP që trajton kërkesat, mund ta përdorë këtë informacion të vjetruar përpara se konfigurimi normal ta pastrojë.
Wiz Research, që i raportoi dobësitë te PHP, thotë se çdo version i PHP që nga 5.4 preket nga të paktën njëra e metë. Studiuesit e saj demonstruan remote code execution kundër container images më të fundit të WordPress, Drupal dhe Joomla, si edhe shfrytëzimin e një aplikacioni bazë Hello World. Një container është një paketë e izoluar që përmban një aplikacion dhe software-in që i nevojitet. Studiuesit demonstruan gjithashtu leximin e memories së PHP worker pa realizuar më parë code execution. Kjo memorie mund të përmbajë fjalëkalime, API keys dhe access tokens. Wiz thotë se patch-i i PHP korrigjon problemin bazë, duke përfshirë edhe variante të tjera.
Detajet dolën para kohe më 20 tetor, përpara publikimit të koordinuar të planifikuar, dhe problemi u bë i njohur si PHP2Shell. Kompania e sigurisë watchTowr konfirmoi përpara publikimit se dobësitë ishin reale. Në orën 07:34 UTC më 21 tetor, disa partnerë hosting i raportuan Patchstack incidente të shfrytëzimit aktiv. Cloudflare raportoi sulme të hershme në orën 07:43 UTC dhe vendosi rregullat fillestare të Web Application Firewall, të cilat kontrollojnë dhe filtrojnë kërkesat web, për rrugët e njohura të exploit. Në orën 13:52 UTC, PHP publikoi versionet e korrigjuara. Pesë minuta më vonë, Patchstack tha se telemetry e vet tregonte probing, por në atë moment nuk kishte prova të forta për komprometime, ndërsa paralajmëroi se kjo mund të ndryshonte pasi detajet e patch-it të bëheshin publike.
Disa shërbime dolën offline si masë paraprake përpara mbërritjes së korrigjimeve. Transmetuesi holandez NOS raportoi ndërprerje që prekën DigiD, MijnOverheid, faqen web të Dhomës së Përfaqësuesve të Holandës, Tweakers dhe faqen e Qendrës Kombëtare të Sigurisë Kibernetike të Holandës. ITmedia raportoi mirëmbajtje emergjente në shërbime japoneze, duke përfshirë Kodmon, Shadowverse: Worlds Beyond dhe Sakura Rental Server, që besohej se lidhej me dobësinë, ndërsa pritej që BASE dhe Xserver të vepronin më pas. Zhvilluesit e The SEO Framework thanë gjithashtu se i kishin nxjerrë serverët e tyre offline. CERT-EU publikoi një njoftim, ndërsa Qendra Kombëtare e Sigurisë Kibernetike e Mbretërisë së Bashkuar kërkoi përditësime të menjëhershme.
Cloudflare thotë se rregullat e saj fillestare të firewall janë të disponueshme për të gjithë klientët, duke përfshirë përdoruesit pa pagesë, por i përshkruan ato vetëm si një pengesë të përkohshme. Ato ndihmojnë vetëm kur origin server pranon trafik ekskluzivisht përmes Cloudflare. Ato nuk e zëvendësojnë përditësimin e sigurisë së PHP, sepse mund të mbeten të disponueshme rrugë të tjera drejt serverit ose variante sulmi që nuk njiheshin më parë.
Administratorët duhet të instalojnë PHP 8.5.12, 8.4.27, 8.3.36 ose 8.2.35, ose të marrin paketën përkatëse të korrigjuar nga furnizuesi i sistemit të tyre operativ. Distribucionet Linux dhe furnizuesit e mbështetjes afatgjatë i morën patch-et paraprakisht. PHP paralajmëroi se paketat rpms.remirepo.net, të mirëmbajtura nga vullnetarë, nuk do të përditësoheshin atë ditë dhe rekomandoi në vend të tyre paketat e distribucionit ose një build nga source. PHP 8.1 dhe versionet më të vjetra nuk marrin më korrigjime nga projekti PHP, megjithëse disa mirëmbajtës të jashtëm e kishin backported korrigjimin, që do të thotë se e kishin përshtatur për versionet më të vjetra.
Disponueshmëria e paketave ndryshonte më 22 tetor. Paketat nga packages.sury.org dhe ppa:ondrej/php mbulonin degët end-of-life nga PHP 5.6 deri në 8.1, ndërsa Ubuntu 22.04 e korrigjoi paketën e vet PHP 8.1 si php8.1 8.1.2-1ubuntu2.28. Ubuntu Pro mbulonte versionet nga 14.04 deri në 20.04, ndërsa 14.04 dhe 16.04 kërkonin Legacy add-on. Freexian ELTS mbulonte PHP 7.0 në Debian 9, 7.3 në Debian 10 dhe 7.4 në Debian 11. Mbështetja e vetë Debian për Debian 11 përfundoi më 31 gusht 2026, megjithëse paketa php7.4 e Sury ofronte një alternativë pa pagesë.
AlmaLinux publikoi korrigjime për PHP streams në versionet 8, 9 dhe 10, duke përfshirë streams end-of-life, por nuk garantoi korrigjime në të ardhmen. Red Hat kishte korrigjime për php:7.4 në RHEL 8 dhe PHP 8.0 në RHEL 9, por jo për streams të nxjerra nga përdorimi, si 7.2 dhe 8.1 në RHEL 9. Remi mbulonte 7.4, 8.0 dhe 8.1 në RHEL 8 dhe 9, por jo 7.2 ose 7.3. CloudLinux publikoi paketa të korrigjuara EasyApache 4 ea-php, nga ea-php52 deri në ea-php85, për cPanel. TuxCare ELS po shpërndante gradualisht korrigjime specifike për çdo degë, ndërsa Zend tha se build-et e saj me mbështetje afatgjatë të PHP 7.2, 7.3, 7.4 dhe 8.1 ishin të patch-uara që në publikim. PHP Docker images zyrtare nuk morën korrigjim për PHP 8.1 ose versione më të vjetra.
PHP publikoi gjithashtu source backports për 7.4, 8.0 dhe 8.1 si zgjidhje të fundit. Këto janë masa lehtësuese të kufizuara dhe jo mbështetje e rinovuar: ato çaktivizojnë session upload progress pavarësisht nga php.ini dhe nuk shtojnë hard memory limit. Në Ubuntu dhe në build-et më të vjetra të Sury që ruajnë numrat e versioneve upstream, administratorët duhet të kontrollojnë changelog-et e paketave për të dyja CVE-të. Paketat e Debian dhe paketat më të reja të Sury mund të paraqesin vetëm një version të ri upstream, ndërsa changelog-et e streams RHEL 8.2 dhe 8.3 mund të shënojnë vetëm rebase; PHP këshillon përdorimin e dnf updateinfo në këto raste. Nëse nuk ekziston korrigjim nga furnizuesi, kaloni në një version me mbështetje. PHP 8.2 merr korrigjime sigurie vetëm deri më 31 dhjetor 2026 dhe PHP 8.3 deri më 31 dhjetor 2027, ndaj PHP rekomandon synimin për versionin 8.4 ose 8.5.
Çdo instalim PHP kërkon vëmendje, duke përfshirë serverët production, container, faqet staging, pajisjet dhe produktet e palëve të treta që përfshijnë PHP. Plugin-et jozyrtare të korrigjimit dhe fragmentet e kopjuara të kodit duhet të shmangen, sepse nuk janë verifikuar dhe mund të prishin një faqe. Nëse një shërbim me rrezik të lartë nuk mund të patch-ohet menjëherë, nxjerrja e tij offline ose vendosja në maintenance mode është një alternativë e rekomanduar edhe nga UK NCSC.
Vetëm përditësimi e korrigjon plotësisht dobësinë në PHP.