Două vulnerabilități critice de execuție remote de cod (RCE) în motorul PHP, denumite colectiv PHP2Shell, au fost remediate pe 21 octombrie 2026. CVE-2026-109618 și CVE-2026-109619 obțin scorul de 9.2 pe CVSS v4.0 și permit unui atacant neautentificat să execute cod arbitrar pe orice server web care rulează PHP — înainte ca orice cod de aplicație să fie invocat. Deoarece defectele se află în nucleul PHP, nu există mitigări la nivel de framework, validare de input sau actualizări Composer. Singura soluție este actualizarea runtime-ului PHP pe fiecare gazdă și în fiecare imagine de container. Acest ghid acoperă versiunile remediate per ramură și distribuție, metode practice de descoperire a proiectelor PHP în GitLab, automatizarea remedierii la scară largă și indicatoarele de compromis pentru serverele expuse pe internet.
Ghid ServerSpan relevant: CVE-2026-12184: Ghid de Patch pentru DoS în PHP-FPM (8.3.32 / 8.4.21 / 8.5.6).
Actualizează PHP la o versiune remediată acum
Primul pas, necondiționat: actualizează runtime-ul PHP pe fiecare gazdă și în fiecare imagine de container. Versiunile oficiale remediate, publicate de proiectul PHP pe 21 octombrie 2026, sunt:
| Ramură PHP | Versiune remediată | Notă | |––––|––––––-|––| | 8.5.x | 8.5.12 | — | | 8.4.x | 8.4.27 | — | | 8.3.x | 8.3.36 | — | | 8.2.x | 8.2.35 | End of life: 31 decembrie 2026 | | 8.6 RC | 8.6.0RC4 | RC3 (imaginea php:8.6-rc din 21 oct) nu conține fixul | | 8.1 și mai vechi | Niciun release oficial | Există backport-uri minime de sursă pentru 7.4, 8.0, 8.1; unele distribuții liverează pachete patch-uite |
Atenție la pachetele de distribuție. Ubuntu, Debian, RHEL și Alpine mențin numărul de versiune upstream vechi și backport-ează fixul. Compară versiunea pachetului, nu ieșirea php -v. Versiunile pachetelor remediate la 22 octombrie 2026:
- Ubuntu 26.04:
php8.5 8.5.4-0ubuntu1.5 - Ubuntu 24.04:
php8.3 8.3.6-0ubuntu0.24.04.13 - Ubuntu 22.04:
php8.1 8.1.2-1ubuntu2.28 - Debian 13:
php8.4 8.4.27-1~deb13u1 - Debian 12:
php8.2 8.2.35-1~deb12u1 - Alpine 3.24:
php83 8.3.36,php84 8.4.27,php85 8.5.12 - RHEL 10:
php 8.3.36-1.el10_2(RHSA-2026:87070),php8.4 8.4.27-1.el10_2(RHSA-2026:87071) - RHEL 9:
php 8.0.30-8.el9_8.1(RHSA-2026:87151),php:8.2 8.2.35-1(RHSA-2026:87072),php:8.3 8.3.36-1(RHSA-2026:87079);php:8.4nu avea fix la 22 oct - RHEL 8:
php:7.4 7.4.33-8(RHSA-2026:87080); stream-urile retrase (7.2, 7.3, 8.0) nu primesc fix
După actualizarea pachetului, repornește fiecare proces care rulează PHP (php-fpm, Apache cu mod_php, workere CLI de lungă durată).
Reconstruiește imaginile de container
Dacă imaginea ta folosește un tag flotant al imaginii oficiale php (php:8, php:8.3, php:8.3-apache, php:latest), reconstruiește-o cu docker build --pull și redeploiează. Imaginile care pin-uiesc o versiune de patch (php:8.3.35-apache) trebuie să aibă tag-ul schimbat la versiunea remediată înainte de rebuild. Imaginile bazate pe derivate (wordpress, drupal, bitnami/php-fpm, frankenphp) primesc fixul doar după ce menținătorii publică o imagine actualizată — verifică upstream înainte de rebuild.
# Exemplu: rebuild forțat pentru o imagine care folosește tag flotant
docker build --pull -t registry.exemplu.ro/app/php:8.3.36-apache .
docker push registry.exemplu.ro/app/php:8.3.36-apache
# Actualizează deployment-ul Kubernetes / Docker Compose / Nomad la noul tagPentru infrastructuri găzduite pe servere dedicate sau VPS, asigură-te că procesele PHP-FPM și Apache sunt repornite după actualizare. Pe dedicated-servers.ro poți găsi servere dedicate cu management inclusiv pentru aplicarea rapidă a patch-urilor de securitate.
Localizează proiectele PHP în grupurile GitLab
Orice proiect care rulează PHP pentru a servi cereri web are nevoie de versiune remediată — inclusiv cele ușor de uitat: dashboade interne, site-uri de marketing, imagini de job CI. Descoperirea necesită două perspective: o analiză statică a ceea ce declară repository-urile și imaginile conțin, și un inventar runtime de ceea ce rulează de fapt. GitLab acoperă vizualizarea statică cu trei funcționalități. Folosește-le în această ordine.
1. Container Scanning
Container Scanning raportează vulnerabilități în pachete de sistem de operare, deci detectează PHP instalat cu apt, apk sau dnf, și raportează cele două CVE-uri odată ce ajung în baza de date a scanner-ului. Pentru a-l activa pe un proiect, adaugă template-ul în .gitlab-ci.yml:
include:
- template: Security/Container-Scanning.gitlab-ci.yml
container_scanning:
variables:
# Experimental, doar Ultimate: raportează și runtime-uri instalate fără package manager
CS_BINARY_SCAN: "true"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 ramura default pot fi revizuite în Vulnerability Report după finalizarea scanării.
Limitare importantă: Imaginile oficiale php compilă PHP din sursă, lăsând nicio înregistrare de pachet. Un proiect poate trece container scanning și tot rulează o versiune vulnerabilă. Analyzer-ul container scanning v8.7.0 (lansat 29 oct) adaugă un scan binar experimental care raportează runtime-uri instalate fără package manager — disponibil pe Ultimate, oprit implicit. Activează-l cu CS_BINARY_SCAN: "true". Dacă îl lași oprit, Orbit și code search de mai jos acoperă-l.
2. GitLab Orbit
GitLab Orbit indexează proiectele, pipeline-urile, constatările de securitate și codul sursă (inclusiv PHP) într-un graf interogabil, permițând unui agent să revizuiască un întreg grup. Cu Orbit activat pe grupul de 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 despre proiectele care au constatări deschise pentru CVE-2026-109618 sau CVE-2026-109619 odată ce scanările au rulat. Orbit indexează doar ramura default și este în beta pentru Premium și Ultimate pe GitLab.com și GitLab Self-Managed.
3. Exact Code Search
Exact Code Search poate găsi cele două tipuri de fișiere care indică un proiect PHP. Rulează-le la grupul de top-level cu modul regular expression activat (toggle-ul .* din dreapta căsuței de căutare):
Imagini de bază container:
lang:Dockerfile ^FROM.*phpModelează orice imagine al cărei nume sau tag conține php, găsind și derivate: wordpress, frankenphp, bitnami/php-fpm. Așteaptă câteva false positive pe care le poți elimina citind rezultatul.
Proiecte Composer:
file:composer\.json$Găsește proiecte care folosesc PHP chiar dacă nu au Dockerfile, sau dacă Dockerfile-ul ia imaginea dintr-un argument de build (FROM $BASE_IMAGE).
Notă: Exact code search acoperă doar ramura default. Pe GitLab.com e activ implicit pentru planurile plătite. Pe GitLab Self-Managed un administrator trebuie să instaleze Zoekt mai întâi. GitLab Dedicated nu suportă exact code search.
Pentru fiecare rezultat, confirmă versiunea. Verifică linia FROM php:<tag> sau rulează php -v în containerul care rulează și compară cu tabelul de mai sus. Lista de dependențe a grupului arată pachete Composer și versiuni de framework, dar nu versiunea runtime-ului PHP.
4. Compară cu inventarul tău runtime
Container scanning și code search arată ce declară și construiesc proiectele tale, 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 gazde configurate manual, sau în containere care încă rulează în clustere fără pipeline activ. Compară rezultatele statice cu un inventar al workload-urilor active din configuration management (Ansible, Puppet, Chef), instrumente de inventar cloud/VM. Pentru Kubernetes, operational container scanning scanează imaginile care rulează în clustere, cu aceeași detecție doar-pachete ca container scanning. Tratează fiecare runtime PHP care apare într-una singură din cele două vizualizări ca o lacună de investigat.
Pentru monitorizare continuă a infrastructurii și detectare automată a serviciilor expuse, soluțiile de la serverspan.ro oferă vizibilitate completă asupra stack-ului tău.
Remediază 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 ține oamenii pe review și merge.
Automatizează fixul
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 remediată. Un flow trigger pe evenimentul Assign îl pornește în momentul în care issue-ul este atribuit. Activează review-uri automate cu Code Review Flow pentru a obține o primă review care urmează instrucțiunile tale de review personalizate. Revizuiește și merge fiecare MR, apoi închide issue-ul odată ce versiunea remediată este deployată.
Impune cu politici
Politica de aprobare merge request din Pasul 1 blochează orice schimbare care reintroduce o versiune PHP vulnerabilă fără aprobare, iar politica de execuție scanare ține container scanning activ în fiecare proiect, astfel încât o regresie apare în raportul de vulnerabilități.
Pentru mai multe detalii despre această parte a subiectului, vezi Actualizare Importantă: Securitate și Performanță PHP Îmbunătățite pentru Hosting Partajat.
Căutările găsesc candidați, dar un inginer de securitate sau platformă trebuie să revizuiască fiecare potrivită, să rezolve include-urile CI, și să distinge între ce declară codul și ce rulează de fapt. Un exemplu de skill agent de la echipa GitLab Developer Advocacy gestionează această muncă. Rulează pe GitLab Duo Agent Platform și cu agenți care folosesc GitLab MCP server sau CLI-ul glab, precum Claude Code, Codex, și Cursor.
Skill-ul verifică imaginile container, job-urile CI, pachetele OS, variabilele configuration management, pin-urile Composer și mediile. Returnează un tabel de constatări citat cu dovezi de deployment și lacune deschise. Skill-ul este read-only: nu face modificări, iar MR-urile de remediere rămân un pas separat, revizuit. Nu poate confirma ce rulează pe gazde la care nu are acces, deci verifică-le direct. Adaptează skill-ul la mediul tău înainte de utilizare.
Verifică semne de compromis
Rapoartele de exploatare difere. Cercetători de securitate au raportat o încercare de exploatare pe 17 octombrie 2026, înainte de divulgarea publică, urmate de alte rapoarte după lansare. Proiectul PHP nu a identificat exploate funcționale la momentul lansării. Dacă un server expus pe internet rula o versiune PHP vulnerabilă, revizuiește log-urile sale de la 17 octombrie 2026 încoace pentru:
- Cereri multipart urmate de erori de limită de memorie sau răspunsuri HTTP 500 repetate
- Cookie-uri de răspuns
PHPSESSIDneobișnuit de mari sau malformate - Reporniri neexplicate ale worker-ilor PHP, sau procese shell pornite de worker-i PHP
- Fișiere neașteptate pe serverul web PHP, conexiuni outbound de la worker-i PHP, sau intrări cron neașteptate
Un exploit reușit poate returna HTTP 200 și lăsa worker-ul rulând, deci absența erorilor nu exclude compromisul. Dacă găsești semne de exploatare, izolează serverul și inițiază 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. CVE-2026-109619 poate expune și memoria procesului, chiar când atacatorul nu realizează execuție de cod. Rotește orice credențiale, token-uri sau cheie pe care procesul PHP le poate citi.
Notă: Scanerele pot semnala imaginea Gemnasium dependency scanning (
gemnasium:6), deprecata din GitLab 17.9, pentru PHP-ul său bundlat. Ea este folosită doar ca instrument de linie de comandă și nu gestionează cereri HTTP, deci nu e exploatabilă, și o versiune remediată a fost livrată deja sub același tag.
Pași practici de acțiune imediată
- Inventariează toate gazdele și imaginile container care rulează PHP (inclusiv CI jobs, sidecars, dashboade interne).
- Actualizează runtime-ul PHP la versiunea remediată corespunzătoare ramurii (tabelul de mai sus) sau pachetul de distribuție patch-uit; repornește toate procesele PHP.
- Reconstruiește și redeploiează toate imaginile container cu tag-uri flotante folosind
docker build --pull; actualizează tag-urile la versiuni patch-uite fixe. - Activează Container Scanning (cu
CS_BINARY_SCAN: "true"pe Ultimate) pe toate proiectele via scan execution policy la nivel de grup. - Rulează Orbit și Exact Code Search (
lang:Dockerfile ^FROM.*phpșifile:composer\.json$) pentru a găsi proiecte rateate de container scanning. - Compară rezultatele statice cu inventarul runtime real (Ansible, cloud inventory, operational container scanning pentru K8s).
- Automatizează remedierea cu GitLab Duo Agent Platform (Developer Flow + Code Review Flow + merge request approval policies).
- Auditează log-urile serverelelor expuse de la 17 oct 2026 încoace pentru IOC-urile listate; rotește secretele dacă e cazul.
Concluzie
PHP2Shell demonstrează cât de periculose pot fi vulnerabilitățile la nivel de motor de runtime: fără autentificare, înainte de codul aplicației, cu impact pe orice server care servește PHP. Singura apărare reală este actualizarea runtime-ului — nu WAF-uri, nu validare input, nu actualizări framework. Folosește tooling-ul GitLab (Container Scanning, Orbit, Exact Code Search, Duo Agent Platform) pentru a descoperi, remediază și preveni regresiile la scară largă. Și, critical, verifică compromisul pe serverele expuse: lipsa erorilor nu garantează siguranța. Acționează acum, documentează pașii, și integrează verificările PHP2Shell în procesul tău standard de vulnerability management.
