PHP2Shell: Actualizare Critică PHP pentru CVE-2026-109618 și CVE-2026-109619 — Ghid Complet de Remediere

Pe 21 octombrie 2026, proiectul PHP a publicat actualizări de urgență pentru două vulnerabilități critique de executare a codului la distanță (RCE), cunoscute colectiv sub numele de PHP2Shell (CVE-2026-109618 și CVE-2026-109619). Ambele au scor CVSS v4.0 de 9.2 și rezidă în motorul PHP, nu în framework-uri sau biblioteci, ceea ce înseamnă că nicio validare de input, autentificare sau actualizare Composer nu poate mitiga riscul. Orice server web care rulează PHP — Apache cu mod_php, NGINX cu PHP-FPM, containere Docker — este expus. Atacantele au fost observate încă din 17 octombrie, patru zile înainte de divulgarea coordinată, conform honeypot-urilor Amazon MadPot. Pentru echipele de infrastructură și hosting, singura soluție reală este actualizarea runtime-ului PHP pe fiecare gazdă și în fiecare imagine de container, urmată de restartul proceselor și verificarea semnelor de compromitere.

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

Versiunile PHP Corectate și Pachetele de Distribuție

Fixurile oficiale acoperă patru ramuri active: PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35 (aceasta ultima ajungând la end-of-life pe 31 decembrie 2026). Candidaturile de lansare 8.6 RC4 includ deja patch-ul, dar imaginea php:8.6-rc de pe Docker Hub rămâne pe RC3 vulnerabilă până la reconstruire. Pentru ramurile vechi (8.1, 8.0, 7.4), PHP a publicat backport-uri minime de sursă, iar unele distribuții livrez pachete patch-uite.

Dacă PHP provine din pachetele distribuției, actualizați pachetul, nu compilați din sursă — Ubuntu, Debian, Alpine și RHEL mențin numerele de versiune upstream vechi și backport-ează corecția. Versiunile pachetelor corectate la 22 octombrie 2026:

Comandă de verificare pe Ubuntu/Debian:

apt list --installed | grep ^php
apt update && apt upgrade php8.3  # exemplu pentru Ubuntu 24.04
systemctl reload php8.3-fpm nginx apache2

Pe RHEL/AlmaLinux/Rocky:

dnf list installed php*
dnf update php php-cli php-fpm
systemctl reload php-fpm httpd nginx

Compară versiunile pachetelor, nu output-ul php -v, deoarece backport-urile păstrează numărul de versiune original.

Reconstruirea Imaginilor Container și Verificarea Runtime-ului

Imaginile container care folosesc tag-uri flotante (php:8, php:8.3, php:8.3-apache, php:latest) trebuie reconstruite cu docker build --pull și redeploy-uite. Imaginile care punează versiunea de patch (php:8.3.35-apache) necesită schimbarea tag-ului în versiunea corectată înainte de rebuild. Derivatele precum wordpress, drupal, frankenphp sau bitnami/php-fpm primesc fix-ul doar după ce maintainer-ii publică imagini actualizate — verifică upstream înainte de rebuild.

Exemplu Dockerfile și rebuild:

# Înainte (vulnerabil)
FROM php:8.3-apache

# După (corectat)
FROM php:8.3.36-apache

docker build --pull -t myapp:php2shell-fix .
docker push registry.example.com/myapp:php2shell-fix
# Actualizează deployment-ul Kubernetes/Compose/Swarm cu noua imagine
kubectl set image deployment/myapp myapp=registry.example.com/myapp:php2shell-fix

Atenție: Container Scanning-ul GitLab detectează implicit doar PHP instalat ca pachet (apt, apk, dnf). Imaginile ufficiale compilează PHP din sursă, lăsând nicio urmă de pachet — un proiect poate trece scanning-ul și tot rulează o versiune vulnerabilă. Analyzer-ul Container Scanning v8.7.0 (29 octombrie) adaugă CS_BINARY_SCAN: "true" (experimental, Ultimate only) pentru a detecta runtime-uri instalate fără manager de pachete.

Localizarea Proiectelor PHP în Grupurile GitLa — Scanning, Orbit și Code Search

GitLab oferă trei instrumente complementare pentru inventarierea statică a proiectelor PHP. Folosește-le în această ordine:

1. Container Scanning

Activează template-ul în .gitlab-ci.yml:

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

container_scanning:
  variables:
    CS_BINARY_SCAN: "true"  # Ultimate only, experimental

Sau aplică o politică de execuție la nivel de grup pentru a-l activa pe toate proiectele simultan. Rezultatele apar în Vulnerability Report pe branch-ul default.

2. GitLab Orbit (Beta, Premium/Ultimate)

Orbit indexează proiectele, pipeline-urile, finding-urile și codul sursă într-un graf interogabil. Cu Orbit activat pe grupul top-level, un agent poate lista toate proiectele care conțin cod PHP, inclusiv cele care compilează PHP sau folosesc imagini php oficiale — pe care Container Scanning le ratează. Interoghează Orbit pentru proiecte cu finding-uri deschise pentru CVE-2026-109618/109619 după ce scan-urile au rulat.

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

3. Exact Code Search (Regex mode)

La nivel de grup top-level, activează toggle-ul .* și rulează:

Imagini de bază container (Dockerfile):

lang:Dockerfile ^FROM.*php

Găsește și derivate: wordpress, frankenphp, bitnami/php-fpm.

Proiecte Composer (fără Dockerfile sau cu ARG-uri):

file:composer\.json$

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 a grupului arată pachete Composer și versiuni framework, dar nu versiunea runtime PHP.

Inventar Runtime vs. Declarat — Identificarea Breșelor

Scanning-ul și code search-ul arată ce declară și construiesc proiectele, nu ce rulează efectiv. PHP poate rula în afara proiectelor GitLab: servere web cu mod_php sau PHP-FPM configurate manual, gazde gestionate prin Ansible/Puppet/Chef, containere în clustere fără pipeline activ. Compară rezultatele statice cu un inventar al workload-urilor rulante din:

Configuration management (Ansible facts, PuppetDB)
Cloud/VM inventory (AWS SSM, Azure Resource Graph, vCenter)
Kubernetes: Operational Container Scanning GitLab (scanează imaginile care rulează în clustere, aceeași limitare de detectare doar-pachet)

Orice runtime PHP care apare doar într-una din cele două viziuni este o breșă de investigat. Pentru medii de hosting gestionat, această comparație este esențială — clienții pot rula PHP în containere sau VM-uri în afara controlului GitLab. Platforme precum dedicated-servers.ro oferă vizibilitate la nivel de hardware și sistem de operare pentru a completa imaginea.

Verificarea Compromiterii și Rotirea Credențialelor

Rapoartele de exploatare difere: cercetătorii au observat încercări de exploit pe 17 octombrie (înainte de divulgare), urmate de altele după lansare. Proiectul PHP n-a identificat exploit-uri funcționale la momentul lansării. Dacă un server internet-facing a rulat PHP vulnerabil, analizează log-urile de la 17 octombrie 2026 onward pentru:

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

Critical: Un exploit reușit poate returna HTTP 200 și lăsa workerul rulând — absența erorilor nu exclude compromiterea. CVE-2026-109619 poate expune și memoria procesului, chiar fără execuție de cod. Daca găsești semne de exploatare:

Isolează serverul imediat
Capturează memorie, disc și log-uri înainte de patching și restart (restartul workerilor PHP poate șterge dovezi)
Inițiează investigație de incident
Roatește toate credențialele, token-urile și cheile pe care procesul PHP le putea citi

Notă: Scanerele pot semnala imaginea gemnasium:6 (deprecated din GitLab 17.9) pentru PHP-ul bundlat. Este folosit doar ca tool CLI și nu gestionează cereri HTTP, deci nu este exploatabil — o versiune corectată a fost deja publicată sub același tag.

Pași Practici de Acțiune Imediată

Actualizează PHP pe toate gazdele și containerele la versiunile corectate (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau pachetele distribuției)
Reconstruiește toate imaginile container cu docker build --pull și tag-uri pinate la versiuni corectate; redeploy-ează
Activează Container Scanning + CS_BINARY_SCAN pe toate proiectele GitLab via politikă de grup
Rulează Exact Code Search pentru lang:Dockerfile ^FROM.*php și file:composer\.json$ la nivel de grup top-level
Activează GitLab Orbit pe grupul top-level și interoghează pentru proiecte PHP și finding-uri CVE-2026-109618/109619
Compară inventarul static cu cel runtime (Ansible, cloud inventory, Kubernetes Operational Container Scanning)
Analizează log-urile de la 17 octombrie pentru semne de compromitere; roatează credențialele dacă e cazul
Aplică politici de approvare Merge Request cu Container Scanning pentru a preveni regresiile

Concluzie

PHP2Shell demonstrează cum o vulnerabilitate la nivel de motor de limbaj bypass-ează toate apărarile la nivel de aplicație — validare input, autentificare, WAF-uri, actualizări framework. Singura دفاعă reală este igiena de runtime: actualizare promptă a tuturor instanțelor PHP, reconstruire imagini container, inventariere continuă (statică + runtime) și monitorizare activă pentru compromitere. Echipele care folosesc GitLab au la dispoziție un set puternic de instrumente — Container Scanning, Orbit, Exact Code Search, GitLab Duo Agent Platform — dar automatizarea nu înlocuiește verificarea manuală a workload-urilor care rulează în afara controlului de sursă. Pentru infrastructuri de hosting la scară largă, combinarea acestor instrumente cu vizibilitatea la nivel de server fizic și virtual oferită de platforme specializate ca serverspan.ro asigură o acoperire completă. Patch-ează acum, verifică continuu, și tratează orice discrepănță între declarat și rulant ca pe un incident de securitate.

–