Përditësimi i sigurisë PHP 2026: udhëzuesi i korrigjimit për PHP2Shell, CVSS 9.2

Vetë zbulimi ishte i pazakontë. Më 20 tetor ekipi i sigurisë së PHP-së publikoi një njoftim paraprak, caktoi publikimin për 21 tetor në ora 14:00 UTC dhe mbajti për vete të drejtën ta botonte më herët. Identifikuesit CVE i dolën në dritë një ditë para zbulimit, shoqëruar me pretendime të fryra për rëndësinë dhe versionet e prekura. Shpërndarësit kishin marrë tashmë patch-et për versionet e tyre, dhe CERT-et kombëtare filluan të publikonin udhëzime përpara se kodi të bëhej publik. Me fjalë të tjera: askush s'kishte justifikim të ligjshëm për vonesë sapo doli publikimi.

Dy të meta, një publikim urgjence

Asnjëra nga dy të metat nuk është gabim logjik në një aplikacion. Të dyja gjenden te mënyra se si PHP përgatit dhe mbyll një kërkesë, dhe pikërisht për këtë asnjë përditësim framework-i, shtojce ose rregull WAF nuk e zëvendëson përditësimin e interpretuesit.

CVE-2026-109618 — RCE përmes prishjes së gjendjes kur mbaron memoria. Kur i mbaron memoria, PHP ndërpret kërkesën në vend që të vazhdojë. Këshilla përshkruan një rrugë ku ky ndërprim e këput PHP-në pikërisht kur të dhënat e brendshme të kërkesës janë inicializuar vetëm pjesërisht, kështu që hapi i pastrimit të kërkesës i trajton më pas si të vlefshme të dhëna që nuk e janë. Një sulmues që arrin ta shtyjë përdorimin e memories deri në kufi mund të përcaktojë se çfarë ndodh më pas. Kjo është e meta që i bën këshillat e mitigimit kaq kundërintuitive: prodhuesi u kërkon administratorëve ta pengojnë PHP-në të mos e godasë tavanin e vet të memories, jo ta ngushtojnë kufirin.

CVE-2026-109619 — RCE nga gjendja globale e mbetur. Gjendja e brendshme që i përket një kërkese mund të mbijetojë edhe pasi të jetë liruar memoria që e mban. Kërkesa tjetër që i bie të njëjtit proces worker mund ta konsumojë atë gjendje të vjetruar përpara se inicializimi normal ta pastrojë. Në një worker jetëgjatë — pikërisht ç'janë PHP-FPM, mod_php dhe LiteSpeed — ripërdorimi i memories është gjendje normale dhe e përhershme, ndaj kjo nuk është rast i rrallë i konfigurimeve ekzotike.

Emri PHP2Shell nuk është etiketë zyrtare e projektit PHP; lindi nga kërkuesit dhe kompanitë e sigurisë dhe u ngjit, ndaj do ta hasni në daljet e skanerëve, në buletinet e hosterëve dhe në këshillat e CERT-eve, gjithmonë duke iu referuar pikërisht këtyre dy CVE-ve.

Kush është realisht i ekspozuar

Këshilla është e prerë: në rrezik janë të gjitha instalimet e PHP-së që u shërbejnë kërkesave web. Kjo përfshin PHP-FPM pas nginx ose Apache, Apache me mod_php, php-cgi, LiteSpeed dhe FrankenPHP. Dallimi mes tyre është sa punë i duhet sulmuesit.

Nëse strehoni WordPress, WooCommerce, Laravel, Magento, ERP-të e lidhura me Magento-n ose ndonjë portal rezervimesh në PHP për biznesin tuaj tregtar, ju bini në rreshtat e parë edhe kur kodi i aplikacionit është i përkryer. Për një vështrim më të gjerë mbi atë se kujt i takon ta zotërojë që në fillim mjedisin e ekzekutimit (runtime), shihni udhëzuesin tonë për outsourcing-un e IT-së në Turqi.

Verifikoni versionin tuaj në dy minuta

Kurthi këtu është aritmetika e versioneve. Shpërndarjet mbajnë PHP 8.3.6 ose 8.2.x për vite me radhë dhe i kthejnë korrigjimet e sigurisë brenda të njëjtit numër versioni të dukshëm, ndaj vetëm php -v nuk ju tregon nëse jeni të mbrojtur. Krahasoni tre gjëra.

1. Versioni i dukshëm i PHP-së dhe SAPI-ja që i shërben trafikut.

2. Versioni i paketës së shpërndarjes, jo ai upstream. Në Debian dhe Ubuntu historiku i ndryshimeve është përgjigja e sinqertë; në sistemet RPM kërkoni historikun e ndryshimeve të paketës.

Nëse historiku i ndryshimeve përmend të dyja CVE-të te versioni i instaluar, jeni të korrigjuar edhe pse php -v vazhdon të tregojë 8.3.6. Ky është dallimi mes një përgjigjeje reale të sigurisë dhe një bestytnie mbi numrat e versioneve.

3. Nëse procesi aktiv e ka ringarkuar binarin e korrigjuar. Një përditësim pakete të cilit nuk i vjen pas një rinisje e lë kodin e vjetër në memorie. Krahazoni kohën e nisjes së shërbimit me kohën e instalimit të paketës:

Te cPanel, Plesk, DirectAdmin ose një platformë e menaxhuar, ekuivalenti është zgjedhësi i versionit PHP plus buletini i sigurisë i vetë hosterit: identifikoni versionin të integruar që ka realisht sajti juaj, jo versionin më të ri që reklamon paneli. Nëse hosteri juaj nuk di të tregojë një datë korrigjimi, trajtojeni sajtin si të pakorrigjuar. Shërbimet tona të infrastrukturës digitale mbulojnë këtë auditim dhe vetë përditësimin; mund edhe thjesht të na kontaktoni me stack-un tuaj dhe t'ju themi se çfarë do të verifikonim ne.

Versionet e korrigjuara dhe gremina EOL

PHP e mban një degë dy vite në zhvillim aktiv dhe edhe dy të tjera vetëm me korrigjime sigurie. Pikërisht kjo politikë nxori katër korrigjime njëkohësisht më 21 tetor — dhe po ajo i lë degët e vjetra vetëm.

Dy paralajmërime praktike nga këshilla. Së pari, nëse e merrni PHP-në nga një repositori komuniteti dhe jo nga shpërndarja juaj, ai repositori mund të mbetet pas dritares së sigurisë: mirëmbajtësit e paketave Remi, që përdoren gjerësisht, deklaruan se nuk do të kishin përditësime po atë ditë, ndaj rruga e sigurt janë paketat e shpërndarjes suaj ose një ndërtim nga burimi. Së dyti, nëse jeni në PHP 8.1 e më të vjetrat, "të presim hosterin tonë" është një vendim sigurie që po merrni në emër të klientëve tuaj — ose dokumentojeni, ose ndryshojeni.

Korrigjoni një server në produksion pa incident

Përditësimet e sigurisë brenda së njëjtës nën-version rrallë i prishin aplikacionet; rinisjet e paprovuara i prishin. Renditja më poshtë është ajo që ne përdorim në platforma tregtare në produksion dhe e mban të shkurtër dritaren e rrezikut pa e vënë sajtin në bast.

1. Së pari, snapshot-i. Një snapshot i hypervisor-it ose i volumit, rikthimin e të cilit e keni provuar për vete, kthehet prapa në minuta dhe e kthen vendimin për të korrigjuar në një vendim pa kosto.
2. Riprodhoni versionin në staging. E njëjta degë, të njëjtat shtesa, të njëjtat skedarë konfigurimi të PHP-së dhe një kopje e të dhënave të produksionit. Provoni rrugët e porosisë (checkout), të kërkesës për ofertë dhe të pagesës, jo vetëm faqen kryesore.
3. Përditësoni grupin e paketave si një tërësi. Përzierja e një CLI të përditësuar me një binar FPM të vjetër është mënyra si njerëzit përfundojnë me një php -v të korrigjuar dhe një rrugë web të pakorrigjuar: apt-get update && apt-get install --only-upgrade 'php8.3-*', ose dnf update --security 'php*' në hostat RPM.
4. Rinisni procesin që shërben kërkesat, pastaj verifikoni që u rinis. systemctl restart php8.3-fpm (ose ringarkoni Apache-n / rinisni LiteSpeed), pastaj rikontrolloni kohën e nisjes së shërbimit dhe përsërisni pyetjet e versionit dhe të historikut të ndryshimeve.
5. Vëzhgoni një orë log-un e gabimeve. Mesazhet OOM, nënshkrimet e reja të gabimeve fatale dhe përqindjet e pazakonshme të 5xx janë sinjalet se rregullimet e mitigimit më poshtë mund të duan akordim — jo arsye për ta shtyrë përditësimin.
6. Regjistroni provat. Versioni i paketës, rreshti i historikut të ndryshimeve që përmend të dyja CVE-të, koha e rinisjes. Klientët, auditorët dhe rishikimet e kontrolleve në stilin ISO 27001 kërkojnë saktësisht këto, dhe duhen dhjetë sekonda për t'i ruajtur.

Aty ku përditësimi duhet të presë — një integrim ERP i validuar, një kalendar publikimesh i embarguar, një cikël miratimi nga klienti — vendosni atë ditë një kontroll kompensues para tij, në vend që ta lini portën hapur me shpresë. Pikërisht këtë rekomanduan këshillat e CERT-eve kombëtare për këtë situatë: të izolohen aplikacionet PHP të ekspozuara ndaj internetit nga rrjeti publik atje ku korrigjimi i menjëhershëm nuk është i mundur.

Mitigime të përkohshme: ngushtojeni dritaren, mos e mbyllni

Këshilla e PHP-së e thotë troc se nuk ka mitigim të plotë dhe se përditësimi është e vetmja zgjedhje e sigurt. Trajtojini të mëposhtmet si mbrojtje për ditë, jo për javë, të aplikuar në një nivel që aplikacioni nuk mund ta anashkalojë, dhe me çdo worker të rinisur më pas.

Kundër CVE-2026-109618 (rruga e mbarimit të memories)

• Lërini PHP-së të harxhojë memorien e makinës në vend të kufirit të vet: memory_limit = -1, në ideal si php_admin_value memory_limit = -1, që kodi i aplikacionit të mos mund ta vendosë përsëri tavanin.
• Mbani trupat e kërkesave të vegjël te interpretuesi: udhëzimi i këshillës flet për rreth 8 MB kur nuk ka ngarkime skedarësh dhe rreth 32 MB kur ka, me upload_max_filesize nën post_max_size.
• Zbatoni kufijtë e kushtueshëm te proxy-ja, sepse dëmtimi vjen nga kërkesa e dekoduar, jo nga madhësia në tela: madhësia gjithsej e trupit të dekoduar, numri i fushave hyrëse, numri i pjesëve multipart, numri i header-ave, thellësia e hierarkisë së të dhënave — dhe përfshini kërkesat që arrijnë pa një Content-Length të përdorshëm.
• Përmbajeni rrezja e shpërthimit me një kufi memories të container-it ose cgroup, i atillë që një worker i vrarë të mbetet një problem disponueshmërie, jo një problem i hostit. Mos i zëvendësoni me RLIMIT_AS ose RLIMIT_DATA: ato shkaktojnë pikërisht dështimin e alokimit që ndodhet në rrugën e cenueshme.

Kundër CVE-2026-109619 (rruga e gjendjes së vjetruar)

• Çaktivizoni progresin e ngarkimit të sesioneve me session.upload_progress.enabled = 0, të vendosur në php.ini, në pool-in FPM ose në konfigurimin e serverit — diku që hyn në fuqi përpara analizës së kërkesës. Pastaj rinisni çdo worker, sepse FPM ndan nga kërkesa në kërkesë gjendjen e modulit të inicializuar. ini_set() dhe .user.ini vijnë shumë vonë.
• Në PHP 8.5 vendosni fatal_error_backtraces = 0 dhe rinisni.
• Hiqni rregullimet për kërkesa që janë të pavlefshme ose të hequra nga përdorimi dhe për këtë nxjerrin diagnostikë gjatë inicializimit të hershëm. Fshehja e mesazhit me error_reporting, display_errors ose @ nuk e heq rrugën e kodit.
• Gjurmoni gabime fatale të arritshme nga sulmuesi dhe pritje të gjata në trajtuesit e ngarkimeve dhe importeve, në kodet callback dhe në rutinat e pastrimit — të njëjtat vende ku qëndrojnë të dyja të metat.

Një CDN ose WAF para origjinës e vazhdon të paguajë veten: kufizimi i shpejtësisë, bllokimi i formave anormale të kërkesave dhe patch-im virtual reduktojnë zhurmën dhe i ngadalësojnë skanimet oportuniste. Për një sulmues të synuar janë vetëm një pengesë shpejtësie, jo një kontroll që mund ta kaloni si trajtim të plotë.

Çfarë t'i kërkoni sot ofruesit tuaj të hostingut

Skriptet e mbështetjes i përgjigjen kësaj pyetjeje me "gjithmonë e kemi të korrigjuar". Kërkoni në vend të kësaj prova që mund t'i vendosni në dosje:

• Versionin e integruar të PHP-së që i është caktuar llogarisë sonë, dhe nëse është paketë e shpërndarjes apo ndërtim vendor-i.
• Datën kur korrigjimet për CVE-2026-109618 dhe CVE-2026-109619 arritën në parkun tuaj të serverave, me vargun e plotë të versionit të brendshëm të paketës.
• Nëse korrigjimi ka zbatim për SAPI-në që i shërben sajtit tonë (FPM, LiteSpeed, mod_php) dhe për çdo nyje staging ose backup që mund të na duhet të restaurojmë.
• Nëse platforma s'është korrigjuar ende: cili kontroll kompensues qëndron në fuqi dhe deri kur.
• Politiken tuaj të qëndrueshme për degët EOL — çfarë ndodh me sajtin tim më 1 janar 2027, kur mbaron mbështetja e sigurisë e PHP 8.2.

Një ofrues që i përgjigjet këtyre pesë pyetjeve brenda një emaili të vetëm është ofrues që ia vlen të mbahet. Ai që ju kthehet me tekst marketingje është një bisedë migrimi; po ai kujdes zbatohet edhe në punën tonë të vlerësimit të hendekut ISO 27001, ku dorëzohet provë, jo qetësim.

A duhet ta pranoni se jeni komprometuar?

Jo automatikisht — por kontrollojeni, mos e hamendësoni, sidomos nëse serveri qëndroi i ekspozuar ndaj internetit publik gjatë dritares përpara korrigjimit tuaj.

• Kërkoni procese, shërbime në dëgjim dhe zëra cron që nuk i keni krijuar ju, dhe lidhje dalëse nga përdoruesi i worker-it të PHP-së.
• Krahasoni me diff direktoret e shkrueshme të aplikacionit kundrejt një burimi të sigurt deploy-i: skedarë të rinj PHP, dosje ngarkimesh të ndryshuara, dosje temp të papritura të ekzekutueshme.
• Kërkoni në log-et e web-it stuhi kërkesash rreth orëve të zbulimit, trupa multipart jashtëzakonisht të mëdhenj, ose kërkesa që u kthyen me 500 me nënshkrime OOM në log-un e gabimeve të PHP-së.
• Kontrolloni se binari i korrigjuar po ekzekutohet vërtet — krahasimi i kohëve të rinisjes më lart e përgjigjon këtë.
• Nëse gjendet diçka e gabuar, trajtojeni si incident: ruajeni diskun dhe log-et, ndërroni çdo kredencial që aplikacioni mund të lexojë dhe rindërtoni nga një imazh i njohur i mirë. Instalimi i paketës PHP për së dyti mbi një host të komprometuar nuk përbën trajtimin e duhur.

Një shembull i zbatuar nga infrastruktura jonë

Ne e mbajmë worldwidetradex.com në Ubuntu 24.04 LTS me nginx dhe PHP-FPM, ndaj më 22 tetor i aplikuam kontrollet e mësipërme ndaj vetes. Rezultatet e ilustrojnë bukur pse ka rëndësi aritmetika e versioneve:

Mësimi vlen për çdo stack: qëndrimi juaj i sigurisë është versioni i paketës plus historiku i ndryshimeve plus rinisja, jo vargu i versionit të marketingut në panelin e hostingut.

Bëjeni korrigjimin rutinë, jo heroizëm

PHP2Shell nuk mbahet mend se ishte ekzotike; mbahet mend se interpretuesi mbi të cilin rron pjesa më e madhe e web-it kishte një të metë kritike para autentikimit dhe mijëra hosta duhej të reagonin brenda orëve. Ekipet që e kaluan pa u zgjuar nuk ishin me fat — kishin automatizim.

• Përditësime sigurie pa ndërhyrje për interpretuesin, me versionin dhe rinisjen e regjistruara automatikisht.
• Një inventar që di cilën SAPI dhe cilën degë PHP përdor çdo sajt, përfshirë staging-un, backup-et dhe atë një WordPress-in e vitit 2019.
• Një rrugë rikthimi e provuar në përsëritje, që "korrigjoje tani" të mos peshojë kurrë kundrejt "s'e kthejmë dot mbrapsht".
• Një plan degësh: asgjë në një version PHP mbështetja e sigurisë e të cilit mbaron brenda dymbëdhjetë muajve të ardhshëm.
• Një përgjegjës me emër për çdo server dhe një rrugë eskalimi e shkruar për ditët kur një korrigjim bie në ora 14:00 UTC të një mërkure.

Nëse këtë aftësi do ta blinitë sesa ta stafonit, ne i marrim përsipër platformat PHP në produksion — ritmin e korrigjimeve, monitorimin, backup-et dhe rikthimet e dokumentuara — si pjesë të punës sonë në infrastrukturën e menaxhuar. Nisni me një përmbledhje të shkurtër dhe me sasi: kërkoni një ofertë.

Pyetje të shpeshta

Burimet

• PHP — këshilla e sigurisë "Critical remote code execution vulnerabilities, update now" dhe njoftimet e publikimit të 21 tetorit 2026, përfshirë udhëzimet e mitigimit dhe afatin e mbështetjes te versionet e mbështetura.
• Këshillat e sigurisë të GitHub-it për depon e PHP-së: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) dhe GHSA-6wmf-4rv5-p3rp (CVE-2026-109619).
• CERT-EU — Këshilla e sigurisë 2026-018, "Critical Vulnerabilities in PHP", me të dyja CVE-të.
• Infosecurity Magazine — "Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches" (21 tetor 2026) dhe "PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure" (22 tetor 2026).

Dëshironi që përditësimi t'ju trajtohet nga ne? Për të diskutuar korrigjimin, një auditim versionesh, migrimin në një platformë PHP të menaxhuar dhe të korrigjuar ose infrastrukturën rreth saj, na kontaktoni ose telefononi në +90 505 679 78 03.