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

Pe 21 octombrie 2026, proiectul PHP a lansat actualizări de urgență pentru două vulnerabilități critice de remote code execution, colectiv denumite PHP2Shell (CVE-2026-109618 și CVE-2026-109619), ambele evaluate la CVSS v4.0 9.2. Spre deosebire de vulnerabilitățile obișnuite din biblioteci sau framework-uri, aceste defecte se află în motorul PHP însuși — ceea ce înseamnă că nicio validare la nivel de aplicație, nicio actualizare Composer și niciun WAF nu pot mitiga riscul. Orice server web care rulează PHP pentru a servi cereri HTTP este expus: Apache cu mod_php, NGINX cu PHP-FPM, containere Docker bazate pe imagini oficiale php:*, și chiar instanțe gestionate manual. GitLab a confirmat că produsele sale (GitLab.com, Self-Managed, Dedicated) nu sunt afectate, deoarece aplicația nu este scrisă în PHP și nu rulează PHP pentru request-uri web. Totuși, pentru majoritatea furnizorilor de hosting, agențiilor web și echipelor DevOps care întrețin stive PHP — WordPress, Drupal, Magento, Laravel, Symfony sau aplicații custom — acțiunea este obligatorie și imediată. Acest ghid acoperă versiunile corectate per branch și distribuție, metodele de inventariere a runtime-urilor PHP în organizație, automatizarea remedierii la scară largă ș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 Corectate și Pachetele pe Distribuții — Ce Trebuie să Instalezi Astăzi

Actualizarea runtime-ului PHP este singura mitigare reală. Framework-urile, bibliotecile, validarea input-ului sau autentificarea nu ajută, pentru că PHP procesează request-ul înainte ca orice cod de aplicație să ruleze. Iată versiunile minime corectate pentru fiecare branch activ:

| Branch PHP | Versiune Corectată | Notă | |––––|––––––-|––| | PHP 8.5.x | 8.5.12 | — | | PHP 8.4.x | 8.4.27 | — | | PHP 8.3.x | 8.3.36 | Recomandat pentru producție (LTS până la nov. 2026) | | PHP 8.2.x | 8.2.35 | End of Life: 31 decembrie 2026 — planifică migrarea | | PHP 8.6 RC | 8.6.0RC4 | RC3 (imaginea php:8.6-rc oficială pe 21 oct) nu conține fixul | | PHP 8.1 și mai vechi | Niciun release oficial | Există backport-uri minime de sursă pentru 7.4, 8.0, 8.1; unele distribuții livreză pachete patchuite |

Dacă PHP vine din pachetele distribuției, actualizează pachetul — nu compara php -v, ci versiunea pachetului. Distribuțiile mențin numărul de versiune upstream vechi și backportează fixul. Versiunile pachetelor corectate 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.4 nu avea fix la 22 oct
RHEL 8: php:7.4 7.4.33-8 (RHSA-2026:87080); stream-urile retractate (7.2, 7.3, 8.0) nu primesc fix

După actualizare, repornește fiecare proces care rulează PHP — systemctl restart php8.3-fpm, systemctl restart httpd (mod_php), sau redeploy-ează containerele. Pe serverele dedicate administrate de dedicated-servers.ro, recomandăm verificarea versiunii pachetului cu dpkg -l | grep php sau rpm -qa | grep php înainte și după restart.

Reconstruiește Imaginile Container — Floating Tags Sunt Periculoase

Dacă imaginea ta Docker 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 redeploy-ează. Tag-urile flotante au fost mutate pe versiunile corectate, dar imaginile locale vechi rămân vulnerabile. Pentru imagini care punează o versiune de patch explicită (php:8.3.35-apache), actualizează tag-ul în Dockerfile la versiunea corectată (php:8.3.36-apache) înainte de rebuild.

Imaginile derivate — wordpress, drupal, frankenphp, bitnami/php-fpm — primesc fixul doar după ce maintainer-ii publică o imagine actualizată. Verifică upstream înainte de rebuild. Un pattern sigur în Dockerfile:

# Explicit patch version — nu floating tags
FROM php:8.3.36-fpm-alpine3.24

# Sau pentru varianta Apache
FROM php:8.3.36-apache-bullseye

Pentru infrastructuri Kubernetes, operational container scanning din GitLab scanează imaginile care rulează efectiv în clustere, cu aceeași limitare: detectează doar PHP instalat ca pachet OS. PHP compilat din sursă (imaginile oficiale php:*) nu are înregistrare de pachet și trece scanning-ul de container clasic. Pentru acoperire completă, activează scanning-ul binar experimental (CS_BINARY_SCAN: "true", disponibil pe GitLab Ultimate, analyzer v8.7.0+ lansat la 29 octombrie).

Inventariază Proiectele PHP la Scară Largă — Container Scanning, Orbit și Code Search

Găsirea tuturor workload-urilor PHP necesită două perspective: o vizualizare statică (ce declară repo-urile și imaginile) și una runtime (ce rulează de fapt). GitLab acoperă vizualizarea statică cu trei funcții — folosește-le în această ordine:

1. Container Scanning — Detectează PHP Instalat ca Pachet OS

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

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

container_scanning:
  variables:
    # Experimental, Ultimate only: raportează și runtimes instalate fără package manager
    CS_BINARY_SCAN: "true"

La nivel de grup, o scan execution policy activează container scanning pentru toate proiectele odată. Rezultatele apar în Vulnerability Report pe branch-ul default. Merge Request Approval policies cu container scanning blochează merge-ul dacă o schimbare reintroduce o versiune vulnerabilă fără aprobare.

Limitare: Container scanning detectează doar PHP instalat prin apt/apk/dnf. Imaginile oficiale php compilă din sursă, lăsând nicio urmă de pachet — un proiect poate trece scanning-ul și tot rula PHP vulnerabil. Scanning-ul binar experimental (v8.7.0+) închide această gaură.

2. GitLab Orbit — Interoghează Graficul de Cunoaștere al Organizației

GitLab Orbit indexează proiecte, pipeline-uri, găsiri de securitate și cod 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 compilă PHP sau folosește imagini php oficiale — pe care container scanning le ratează. Orbit nu parseau încă Dockerfile-uri (issue #1416), deci folosește lista pentru a reduce scopul code search-ului următor. Poți întreba Orbit și ce proiecte au găsiri deschise pentru CVE-2026-109618/109619 după 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

Activează Exact Code Search (pe GitLab.com e on-by-default pentru planurile plătite; pe Self-Maintained trebuie instalat Zoekt; GitLab Dedicated nu-l suportă). Rulează la nivel de grup top-level cu regex mode (toggle .* dreapta căsuței de căutare):

Imagini de bază container (inclusiv derivate: wordpress, frankenphp, bitnami/php-fpm):

lang:Dockerfile ^FROM.*php

Proiecte Composer (fără Dockerfile sau cu FROM $BASE_IMAGE):

file:composer\.json$

Pentru fiecare rezultat, confirmă versiunea — citește 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-ului PHP.

4. Compară cu Inventarul Runtime — Găsește Gap-urile

Container scanning și code search arată ce proiectele declară și construiesc, nu ce rulează. PHP poate rula în afara proiectelor GitLab: servere web cu mod_php sau PHP-FPM activat doar în configurație, host-uri configure manual, containere care rulează în clustere fără pipeline activ. Compară rezultatele statice cu un inventar al workload-urilor rulante din configuration management (Ansible, Puppet, Chef), cloud inventory sau VM inventory tools. Tratează fiecare runtime PHP care apare într-o singură vizualizare ca un gap de investigat.

Remediere Automatizată la Scară — GitLab Duo Agent Platform

Descoperirea este doar primul pas. GitLab Duo Agent Platform poate executa pașii de mai sus pentru tine, în toate proiectele, prin Orbit și code search. Apoi, 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 corectată. Un flow trigger pe eventul Assign îl pornește în momentul atribuirii issue-ului. Activează review-uri automate cu Code Review Flow pentru un primul review care urmează instrucțiunile tale custom. Review-uiește și merge-uiește fiecare MR, apoi închide issue-ul odată ce versiunea corectată e deployată.

Impune cu policy-uri. MR approval policy-ul din Pasul 1 blochează orice schimbare care reintroduce o versiune PHP vulnerabilă fără aprobare, iar scan execution policy-ul menține container scanning activ în fiecare proiect, astfel încât o regresie apare în Vulnerability Report.

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ă review-uiască fiecare potrivire, să rezolve include-urile CI și să distingă ce declară codul de ce rulează de fapt. Un exemplu de agent skill de la echipa GitLab Developer Advocacy gestionează această muncă. Rulează pe GitLab Duo Agent Platform și cu agenți care folosesc GitLab MCP server, glab CLI, Claude Code, Codex sau Cursor. Skill-ul verifică imagini container, job-uri CI, pachete OS, variabile configuration management, pin-uri Composer și medii. Returnează un tabel de găsiri citate cu dovezi de deployment și gap-uri deschise. 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. Adaptează skill-ul la mediul tău înainte de utilizare.

Verifică Semne de Compromitere — Log-uri, Procese, Fișiere

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

Request-uri multipart urmate de erori de memory limit sau răspunsuri HTTP 500 repetate
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 de la workeri PHP, sau intrări cron neașteptate

Un exploit reușit poate returna HTTP 200 și lăsa workerul rulând — absența erorilor nu exclude compromiterea. 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. Restartarea workerilor PHP poate șterge dovezi. CVE-2026-109619 poate expune și memoria procesului, chiar când atacatorul nu atinge execuția de cod. Roatează orice credențiale, token-uri sau chei pe care procesul PHP le putea citi.

Notă: Scanerele pot flag-ului imaginea Gemnasium dependency scanning (gemnasium:6), deprecata din GitLab 17.9, pentru PHP-ul său bundled. E folosită doar ca tool linie de comandă și nu gestionează request-uri HTTP, deci nu e exploatabilă. O versiune corectată a fost livrată deja sub același tag.

–

Pași Practici Imediți

Actualizează PHP pe toate host-urile și containere la versiunile minime corectate (8.5.12, 8.4.27, 8.3.36, 8.2.35 sau pachetele distribuției) — astăzi.
Reconstruiește toate imaginile Docker care folosesc tag-uri flotante php:* cu docker build --pull; actualizează tag-urile pinuite la versiunile corectate; verifică imaginile derivate (wordpress, drupal, bitnami) upstream.
Repornește toate procesele PHP (php-fpm, apache/mod_php, containere) după upgrade.
Activează container scanning + CS_BINARY_SCAN pe toate proiectele GitLab via scan execution policy; adaugă MR approval policy pentru a bloca regresiile.
Rulează Orbit și Exact Code Search (regex lang:Dockerfile ^FROM.*php și file:composer\.json$) pentru a inventaria proiectele PHP; confirmă versiunea fiecărui rezultat.
Compară cu inventarul runtime (Ansible, cloud inventory, operational container scanning K8s) — investighează gap-urile.
Auditează log-urile de la 17 oct 2026 pentru indicatori de compromitere; roatează credențialele accesibile procesului PHP dacă e suspectat exploit.

–

PHP2Shell demonstră că vulnerabilitățile la nivel de runtime necesită o abordare la nivel de infrastructură, nu de aplicație. Echipelor care gestionează sute de proiecte PHP — de la site-uri WordPress la API-uri Laravel critice — le este esențială automatizarea inventarierii, a remedierii și a validării continue. GitLab oferă tooling-ul; disciplința de a-l folosi constant separă incidentele minore de compromisurile majore. Pentru infrastructură care trebuie să ruleze PHP în condiții de siguranță și performanță maxime, exploră ofertele de servere dedicate optimizate pentru hosting PHP sau soluțiile de cloud VPS cu management inclus care includ patching proactiv și monitorizare de securitate 24/7.