Patch-i për PHP2Shell u shpërnda në një infrastrukturë të gjerë hosting-u
Përpjekjet për exploit të PHP2Shell po arrinin tashmë te faqet e internetit më 21 tetor 2026, ndërsa inxhinierët e hosting-ut prisnin rregullimet për dy cenueshmëri kritike të PHP. Kinsta thotë se reagoi me filtrim nga Cloudflare, ndryshime të përkohshme të konfigurimit të PHP dhe një shpërndarje patch-esh në të gjithë platformën, që mbuloi qindra mijëra container. Deri më 23 tetor, këta filtra kishin bllokuar më shumë se 550,000 kërkesa të lidhura, ndërsa hetimet e host-it nuk gjetën prova se ndonjë përpjekje kishte pasur sukses.
Ekipi i sigurisë së PHP njoftoi paraprakisht më 20 tetor se një release kritik do të mbërrinte të nesërmen. Më pas, cenueshmëritë u identifikuan si CVE-2026-109618 dhe CVE-2026-109619. Të dyja prekin mënyrën e brendshme se si PHP administron memorien dhe, në kushte të caktuara, mund të lejojnë remote code execution, që do të thotë se një sulmues i paautentikuar mund ta detyrojë serverin të ekzekutojë kod. Rezultati i tyre sipas CVSS 4.0 ishte 9.2. CVSS, ose Common Vulnerability Scoring System, është një shkallë standarde për të shprehur sa serioze është një cenueshmëri sigurie.
Për pronarët e faqeve WordPress, vendndodhja e cenueshmërive ishte thelbësore. PHP është runtime, pra software-i bazë që ekzekuton WordPress, ndaj përditësimi i një plugin-i, theme-je ose i vetë WordPress nuk mund ta korrigjonte kodin e cenueshëm të PHP. runtime duhej të merrte patch nga pala që e administronte. Kinsta raporton se inxhinierët e saj filluan të shihnin kërkesa që synonin këto cenueshmëri gjatë orëve të para të 21 tetorit dhe i inspektuan manualisht faqet e shënjestruara për prova komprometimi.
Çdo production environment dhe staging environment në platformën e Kinsta ishte tashmë pas Cloudflare. staging environment është një kopje private që përdoret për të testuar ndryshimet e faqes. Cloudflare prezantoi rregulla emergjente të Web Application Firewall përpara publikimit të PHP2Shell. WAF është një filtër që shqyrton trafikun web dhe mund të refuzojë kërkesat që përputhen me teknika të njohura sulmi. Kinsta thotë se inxhinierët e saj shqyrtuan çdo rregull të ri në changelog-un e Cloudflare dhe e ndryshuan veprimin e tij në Block në të gjithë platformën, pa u kërkuar klientëve të konfiguronin faqet individualisht.
Ky filtrim ofroi mbrojtje të përkohshme ndërsa përgatiteshin paketat PHP me patch. Cloudflare vazhdoi t'i ndryshonte mekanizmat e detection ndërsa sulmuesit ndryshonin payload-et e tyre për t'iu shmangur rregullave ekzistuese. Gjithashtu prezantoi full transaction detection, i cili merr parasysh informacionin si nga kërkesa hyrëse HTTP, ashtu edhe nga përgjigjja e serverit, dhe mund të ndalojë që një përgjigje përkatëse të arrijë te kërkuesi. Deri më 23 tetor, mbrojtjet që mbulonin faqet e Kinsta kishin refuzuar më shumë se 550,000 kërkesa të lidhura me PHP2Shell. Ky numër përfaqëson kërkesa të bllokuara, jo sulmues unikë, komprometime të suksesshme apo domosdoshmërisht 550,000 fushata të veçanta sulmi.
Kinsta çaktivizoi gjithashtu funksionin session upload progress të PHP përmes setting-ut session.upload_progress.enabled. Njoftimi i PHP e identifikoi këtë ndryshim si një masë zbutëse për disa rrugë exploit-i, megjithëse nuk mbulonte çdo rrugë të mundshme drejt cenueshmërive. Më 23 tetor, ekipi i PHP dha udhëzim të mëtejshëm që funksioni të mbahej i çaktivizuar deri në një release të mëvonshëm për rregullimin e bug-eve. Kinsta e mbajti aktiv këtë ndryshim konfigurimi dhe rregullat e Cloudflare gjatë gjithë deployment-it dhe verifikimit të patch-eve.
Rregullimet zyrtare mbërritën më 21 tetor si PHP 8.2.35, 8.3.36, 8.4.27 dhe 8.5.12. Host-it i nevojiteshin gjithashtu paketa për PHP 7.4, 8.0 dhe 8.1, degë që nuk merrnin më release rutinë sigurie drejtpërdrejt nga projekti PHP. Ofruesi i paketave, Freexian, siguroi rregullime për këto degë më të vjetra me mbështetje afatgjatë përmes backporting, i cili zbaton një korrigjim sigurie në software më të vjetër pa detyruar një upgrade të menjëhershëm në një degë më të re. Kjo do të thotë gjithashtu se vetëm numri i versionit të PHP nuk provon gjithmonë nëse një instalim i mirëmbajtur nga një vendor përmban një rregullim të caktuar.
Paketat mbërritën gradualisht. PHP 8.5.12 hyri në mirror-in e Kinsta në orën 14:24 UTC më 21 tetor, deployment-i filloi në orën 15:54 dhe dhjetëra mijëra container u përditësuan deri në orën 17:45. PHP 8.3.36 u bë i disponueshëm në orën 18:50, ndërsa rollout-i i tij filloi së bashku me PHP 8.5 deri në orën 19:04. Paketat me patch për PHP 7.4, 8.0 dhe 8.1 mbërritën midis orës 21:17 dhe 22:28, ndërsa deployment-et filluan në orën 22:28. Paketat për PHP 8.2 dhe 8.4 u shfaqën në orën 23:25, të ndjekura nga deployment-i në orën 01:37 më 22 tetor. container është një mjedis software i izoluar që përdoret për të ekzekutuar një faqe dhe shërbimet që e mbështesin atë.
Në orën 04:31 UTC më 22 tetor, 1,888 container, afërsisht 0.5% e totalit, kërkonin ende vëmendje shtesë. Kinsta thotë se inxhinierët punuan me këto mjedise në vend që ta trajtonin disponueshmërinë e paketave si provë instalimi. Në orën 08:26, kompania raportoi mbulim 100% të mbrojtjes dhe e shënoi incidentin publik si të zgjidhur. Kompania vazhdoi t'i kontrollonte mjediset edhe më pas, ndërsa masat zbutëse përmes firewall dhe konfigurimit të PHP mbetën aktive.
Numri i kërkesave të bllokuara nuk mund të përcaktonte nëse përpjekjet e mëparshme kishin pasur sukses, ndaj inxhinierët vazhduan inspektimet manuale dhe monitorimin e trafikut. Kinsta thotë se shkëmbeu informacion për kërcënimet me Patchstack, partnerin e saj për Vulnerability Protection, dhe diskutoi vëzhgimet dhe praktikat me ofrues të tjerë hosting-u. Cloudflare siguroi filtrimin e sulmeve, ndërsa Freexian ofroi paketat me patch. Sipas Kinsta, këto hetime nuk gjetën asnjë provë për shkelje të suksesshme të lidhur me PHP2Shell, një përfundim i kufizuar me kujdes, i cili nuk do të thotë se sulmet munguan.
Shqetësimi çoi gjithashtu në mbyllje parandaluese. National Cyber Security Centre i Holandës e hoqi përkohësisht faqen e vet nga interneti, ndërsa faqet qeveritare në Gjermani, Francë, Belgjikë dhe Finlandë u pezulluan. Kryeministri i Japonisë u bëri thirrje operatorëve të aplikonin patch sa më shpejt ose t'i ndalonin përkohësisht shërbimet nëse nuk mund t'i përditësonin. Klientët e Kinsta pezulluan në mënyrë proaktive rreth 3,000 faqe, ndërsa të tjerë aktivizuan sfida verifikimi në të gjithë faqen ose kërkuan bllokime trafiku në nivel serveri. Kinsta nuk rekomandoi që faqet e hostuara të hiqeshin nga interneti, sepse filtrimi i saj emergjent ishte tashmë aktiv. Pas aplikimit të patch-eve, ajo identifikoi dhe riaktivizoi mjediset e pezulluara posaçërisht për shkak të PHP2Shell, ndërsa pezullimet e palidhura i la të paprekura.
Incidenti tregon pse pronarët e faqeve duhet të përcaktojnë se kush e kontrollon runtime e tyre PHP, sa shpejt mund të vendosë ajo palë një rregullim emergjent dhe çfarë mbrojtjesh të përkohshme janë të disponueshme përpara mbërritjes së patch-eve. Platformat e menaxhuara mund t'i kryejnë në mënyrë të centralizuar përditësimet e runtime, por pronarët duhet të kërkojnë gjithsesi konfirmim të qartë për mbulimin dhe gjetjet e incidentit. Si një alternativë e përshtatshme për lexuesit që po rishikojnë këtë përgjegjësi, AEU Hosting është hosting i menaxhuar për WordPress, i siguruar nga fillimi deri në fund.
Mësimi kryesor është se PHP2Shell nuk mund të zgjidhej brenda dashboard-it të WordPress. Reagimi efektiv kërkonte filtrim me disa shtresa, një masë të kufizuar zbutëse përmes konfigurimit, paketa PHP me patch për degët aktuale dhe ato më të vjetra, verifikim në çdo mjedis dhe kontrolle të bazuara në prova për komprometim.