PHP2Shell (CVE-2026-109618 și CVE-2026-109619): Ghid complet de identificare, patching și verificare de compromitere

Pe 21 octombrie 2026, proiectul PHP a lansat o versiune de urgență care adresază două vulnerabilități critice de execuție de cod la distanță (RCE), denumite colectiv PHP2Shell. Ambele primesc scorul 9.2 pe CVSS v4.0 și rezidă în motorul PHP — nu într-un framework, bibliotecă sau cod de aplicație. Practic, orice server web care rulează PHP (Apache cu mod_php, NGINX cu PHP-FPM, containere, VM-uri bare-metal) este expus. Atacantele pot declanșa exploit-ul printr-o simplă cerere neautentificată înainte ca orice cod de aplicație să ruleze, deci validarea input-ului, autentificarea sau actualizările Composer nu ajută. GitLab a confirmat că platforma sa nu este afectată (nu este scrisă în PHP), dar infrastructura ta probabil da. În acest articol parcurgem versiunile corectate per ramură și distribuție, metodele de descoperire a proiectelor PHP ascunse în organizație, automatizarea remedierei la scară largă și indicatoarele concrete de compromis pe care trebuie să le cauți în log-uri.

Ghid ServerSpan relevant: CVE-2026-12184: Ghid de Patch pentru DoS în PHP-FPM (8.3.32 / 8.4.21 / 8.5.6).

Versiunile corectate: ce să instalezi acum

PHP a publicat corecții pentru patru ramuri active: 8.5.12, 8.4.27, 8.3.36 și 8.2.35 (acesta intră în EOL la 31 decembrie 2026). Pentru PHP 8.6, fixul apare începând cu 8.6.0RC4 — imaginea oficială php:8.6-rc era pe RC3 la 21 octombrie și nu conține patch-ul. Ramurile 8.1, 8.0 și 7.4 nu primesc release-uri oficiale; PHP a publicat doar backport-uri de sursă minime, iar unele distribuții liverează pachete patchuite.

Dacă PHP vine din pachetele distribuției, upgrade-ează pachetul, nu compilă din sursă. Versiunile pachetelor corectate la 22 octombrie 2026:

Important: Ubuntu și Red Hat (pentru pachetele 7.4 și 8.0) păstrează numărul de versiune upstream vechi și backportează fixul. Compara versiunile pachetelor, nu ieșirea php -v. După upgrade, repornește toate procesele care rulează PHP (php-fpm, Apache, containere).

Pentru containere: dacă imaginea ta folosește un tag flotant (php:8, php:8.3, php:8.3-apache, php:latest), reconstruiește cu docker build --pull și redeploiează. Imaginile care punează versiunea de patch (php:8.3.35-apache) necesită schimbarea tag-ului la versiunea corectată înainte de rebuild. Derivatele (wordpress, drupal, frankenphp, bitnami/php-fpm) primesc fixul doar după ce mentainerii publică o imagine actualizată — verifică upstream înainte de rebuild.

Descoperirea proiectelor PHP în organizație: patru perspective

Un proiect care rulează PHP pentru a servi cereri web are nevoie de versiune corectată — inclusiv cele ușor de uitat: dashboard-uri interne, site-uri marketing, imagini de CI job. Două perspective sunt necesare: o vizibilitate statică (ce declară repository-urile și imaginile) și un inventar runtime (ce rulează de facto). GitLab acoperă vizibilitatea statică prin trei funcții; folosește-le în această ordine.

1. Container Scanning — detectează PHP instalat ca pachet OS

Container Scanning raportează vulnerabilități în pachete de sistem (apt, apk, dnf), deci găsește PHP instalat prin managerul de pachete și raportează cele două CVE odată ce ajung în baza de date a scanner-ului. Pentru a-l activa pe un proiect, adaugă template-ul în .gitlab-ci.yml:

Pentru mai multe detalii despre această parte a subiectului, vezi Actualizare Importantă: Securitate și Performanță PHP Îmbunătățite pentru Hosting Partajat.

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

Poți folosi și o politică de execuție la nivel de grup pentru a activa container scanning pe toate proiectele dintr-un grup odată. Rezultatele pentru branch-ul default apar în Vulnerability Report după finalizarea scan-ului. Poți adăuga și politici de aprobare Merge Request cu container scanning: dacă o schimbare reintroduce un PHP vulnerabil, politica blochează merge-ul fără aprobare.

Limitare: Container scanning detectează doar PHP instalat ca pachet. PHP compilat din sursă, inclusiv imaginile oficiale php, nu are înregistrare de pachet — un proiect poate trece scanning-ul și tot rula PHP vulnerabil. Code search acoperă această latență.

2. GitLab Orbit — interogare graf a proiectelor, pipeline-urilor și findings

GitLab Orbit indexează proiectele, pipeline-urile, finding-urile de securitate și codul sursă (inclusiv PHP) într-un graf interogabil. Cu Orbit activat pe grupul top-level, un agent poate lista fiecare proiect care conține cod PHP, inclusiv cele care compilează PHP sau folosesc imaginile oficiale php — pe care container scanning le ratează. Orbit nu parsează încă Dockerfile-uri (issue #1416), deci folosește lista pentru a delimita code search-ul următor, care confirmă imaginea de bază și versiunea în fiecare proiect. Poți întreba Orbit și ce proiecte au finding-uri deschise pentru CVE-2026-109618 sau CVE-2026-109619 odată ce scan-urile au rulat. Orbit indexează doar branch-ul default și este în beta pentru Premium/Ultimate pe GitLab.com și Self-Managed.

3. Exact Code Search — găsește Dockerfile-uri și proiecte Composer

Exact code search (accesibil la nivel de grup top-level, modul regex activat — butonul .* din dreapta căsuței de căutare) găsește cele două tipuri de fișiere care indică un proiect PHP:

Imagini de bază container: caută în toate fișierele detectate ca Dockerfile; pattern-ul potrivește orice imagine a cărei nume sau tag conține php (găsește și derivate: wordpress, frankenphp, bitnami/php-fpm):

lang:Dockerfile ^FROM.*php

Proiecte Composer: găsește proiecte care folosesc PHP chiar dacă nu au Dockerfile, sau dacă Dockerfile-ul ia imaginea dintr-un build argument (FROM $BASE_IMAGE):

file:composer\.json$

Exact code search acoperă doar branch-ul default. Pe GitLab.com e activat implicit pentru planurile plătite. Pe Self-Managed, un admin trebuie să instaleze Zoekt. GitLab Dedicated nu suportă exact code search.

Pentru fiecare rezultat, confirmă versiunea. Verifică linia FROM php:<tag> sau rulează php -v în containerul rulant și compară cu tabelul de mai sus. Lista de dependențe de grup arată pachete Composer și versiuni de framework, nu versiunea runtime PHP.

4. Compară cu inventarul tău runtime

Container scanning și code search arată ce declară și construiesc proiectele, nu ce rulează. PHP poate rula în afara proiectelor GitLab: pe servere web cu mod_php sau PHP-FPM activat doar în configurație, pe host-uri configurate manual, sau în containere care rulează încă în clustere fără pipeline activ. Compară rezultatele statice cu un inventar al workload-urilor rulante din configuration management (Ansible, Puppet, Chef), tool-uri cloud sau VM inventory. Pentru Kubernetes, operational container scanning scanează imaginile care rulează în clustere, cu aceeași detectare doar-pachet. Tratează fiecare runtime PHP care apare într-o singură dintre cele două perspective ca o latență de investigat.

Remediere la scară largă cu GitLab Duo Agent Platform

GitLab Duo poate rula pașii de descoperire de mai sus pentru tine, pe toate proiectele, prin Orbit și code search. De acolo, lasă agenții să facă munca repetitivă și păstrează oamenii pe review și merge.

Automatizează fix-ul. Folosește Agentic Chat pentru a crea un epic cu un issue per proiect afectat și atribuie Developer Flow fiecăruia. Flow-ul deschide un merge request care actualizează tag-ul imaginii de bază sau pachetul la versiunea corectată. Un flow trigger pe evenimentul Assign pornește flow-ul în momentul atribuirii issue-ului. Activează review-uri automate cu Code Review Flow pentru a obține o primă review care urmează instrucțiunile tale de review personalizate. Review-uiește și merge fiecare MR, apoi închide issue-ul odată ce versiunea corectată e deployată.

Impune cu politici. Politica de aprobare MR din Pasul 1 blochează orice schimbare care reintroduce o versiune PHP vulnerabilă fără aprobare, iar politica de execuție scan ține container scanning activ în fiecare proiect, astfel încât o regresie apare în vulnerability report.

Căutările găsesc candidați, dar un inginer de securitate sau platformă trebuie să revizuiască fiecare potrivire, să rezolve include-urile CI și să distingă ce declară codul de ce rulează de facto. Un exemplu de skill agent de la echipa GitLab Developer Advocacy gestionează această lucrare. Rulează pe GitLab Duo Agent Platform și cu agenți care folosesc GitLab MCP server sau glab CLI (Claude Code, Codex, Cursor). Skill-ul verifică imagini container, job-uri CI, pachete OS, variabile configuration management, pin-uri Composer și medii. Returnează un tabel de finding-uri citat cu dovezi de deployment și gap-uri deschise. Skill-ul e read-only: nu face modificări, MR-urile de remediere rămân un pas separat, revizuit. Nu poate confirma ce rulează pe host-uri la care nu are acces — verifică-le direct.

Verificarea compromiterii: ce să cauți în log-uri

Rapoartele de exploatare difera. Cercetători de securitate au raportat o încercare de exploit pe 17 octombrie 2026, înainte de divulgarea publică, urmate de alte rapoarte după release. Proiectul PHP n-a identificat exploit-uri funcționale la momentul release-ului. Dacă un server expus pe internet a rulat o versiune PHP vulnerabilă, revizuiește log-urile sale de la 17 octombrie 2026 încolo pentru:

Cereri multipart urmate de erori memory_limit sau răspunsuri HTTP 500 repetitive
Cookie-uri de răspuns PHPSESSID anormal de mari sau malformate
Restart-uri neexplicate ale worker-ilor PHP, sau procese shell pornite de workeri PHP
Fișiere neașteptate pe serverul web PHP, conexiuni outbound din workeri PHP, sau intrări cron neașteptate

Un exploit reușit poate returna HTTP 200 și lăsa workerul rulând, deci absența erorilor nu exclude compromiterea. Dacă găsești semne de exploatare, izoilează serverul și inițiează o investigație de incident. Unde e posibil, capturează memorie, disc și log-uri înainte de patching și restart. Repornirea worker-ilor PHP poate șterge dovezi. Notă: CVE-2026-109619 poate expune memoria procesului chiar dacă atacatorul nu realizează execuție de cod. Rotirește orice credențiale, token-uri sau chei pe care procesul PHP le putea citi.

Notă: Scanerele pot flagui imaginea Gemnasium dependency scanning (gemnasium:6), deprecata din GitLab 17.9, pentru PHP-ul său bundlat. E folosită doar ca tool CLI și nu gestionează cereri HTTP, deci nu e exploatabilă; o versiune corectată a fost livrată deja sub același tag.

–

Pași practici imediată

Inventariează toate host-urile, containerele și imaginile care rulează PHP (incluzând VM-uri bare-metal, Kubernetes, funcții serverless, CI runners).
Upgrade-ează runtime-ul PHP la versiunea corectată corespunzătoare ramurii tale (vezi tabelul de mai sus) — pachete de distribuție sau imagini oficiale.
Reconstruiește imaginile container cu docker build --pull și redeploiează; pentru derivate, așteaptă upstream.
Repornește toate procesele PHP (systemd, docker, k8s rollout) după patching.
Activează Container Scanning + politică de execuție la nivel de grup în GitLab.
Rulează Exact Code Search cu cele două query-uri de mai sus pe grupul top-level.
Interoghează GitLab Orbit pentru proiecte PHP și finding-uri deschise CVE-2026-109618/109619.
Compară rezultatele statice cu inventarul runtime (Ansible, cloud inventory, operational container scanning).
Auditează log-urile de la 17 oct 2026 pentru semnele de compromis listate mai sus.
Rotirește secretele (chei API, token-uri DB, certificat TLS) citibile de procesul PHP pe host-urile suspecte.

–

PHP2Shell nu e o vulnerabilitate de framework — e o vulnerabilitate de motor de execuție. Singura apărare reală e upgrade-ul runtime-ului pe fiecare instanță, urmat de verificare că nu s-a întâmplat nimic rău în fereastra de expunere. Drulezi servere dedicate sau VPS-uri cu PHP în producție? Verifică oferta noastră de servere dedicate gestionate sau soluții VPS cu patching automat pentru a reduce suprafața de atac și timpii de reacție la vulnerabilități critice de acest gen.