PHP2Shell (CVE-2026-109618 și CVE-2026-109619): Ghid complet de patching, detectare și investigare a compromiterii

Două vulnerabilități critice de execuție de cod la distanță în motorul PHP, denumite colectiv PHP2Shell, au fost corrigate pe 21 octombrie 2026. Ambele CVE-uri (CVE-2026-109618 și CVE-2026-109619) au scorul 9.2 pe CVSS v4.0 și sunt exploatabile fără autentificare pe orice server web care rulează PHP — fie că vorbim de Apache cu mod_php, NGINX cu PHP-FPM sau containere Docker. Deoarece flaw-urile există în interpretorul PHP înainte ca orice cod de aplicație să ruleze, niciun update de framework, validare de input sau autentificare nu mitigate riscul. Singura soluție este upgrade-ul runtime-ului PHP pe fiecare host și imagine de container. În acest ghid acoperim versiunile corectate per ramură și distribuție, metodele de inventariere a proiectelor PHP la scală cu GitLab, automatizarea remedierei prin GitLab Duo Agent Platform și indicatorii de compromitere pe care trebuie să-i monitorizezi în loguri.

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 — ce să instalezi acum

Proiectul PHP a lansat fixurile în patru ramuri active simultan: 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Atenție: PHP 8.2 ajunge la end of life pe 31 decembrie 2026, deci dacă încă ești pe 8.2, planifică migrarea către 8.3 sau 8.4 cât mai curând. Pentru PHP 8.6, release candidate-ul 4 (8.6.0RC4) include fixul; imaginea oficială php:8.6-rc era încă pe RC3 la 21 octombrie, deci reconstruiește-o explicit.

Dacă PHP vine din pachetele distribuției tale (apt, dnf, apk), upgrade-ează pachetul, nu doar binarul. Multe distribuții backportează fixul păstrând numărul de versiune upstream, așa că php -v poate arăta aceeași versiune deși fixul este aplicat. Comparam versiunile pachetelor:

După upgrade, repornește toate procesele care rulează PHP (php-fpm, Apache, containere). Pe servere dedicate sau VPS-uri administrate prin Ansible, Poți face asta cu un handler simplu:

- name: Restart PHP-FPM după upgrade
  ansible.builtin.systemd:
    name: "{{ php_fpm_service_name }}"
    state: restarted
  listen: "php upgraded"

Reconstruirea imaginilor Docker — evită tag-urile floating

Dacă folosești tag-uri floating ale imaginii oficiale php (php:8, php:8.3, php:8.3-apache, php:latest), reconstruiește imaginea cu docker build --pull și redeploy-ează. Imaginile care pînnesc o versiune de patch (php:8.3.35-apache) trebuie actualizate la tag-ul corectat (php:8.3.36-apache) înainte de rebuild. Derivatele precum wordpress, drupal, frankenphp sau bitnami/php-fpm primesc fixul doar după ce maintainer-ii lor publică o imagine actualizată — verifică upstream-ul înainte să reconstruiești.

Comanda sigură pentru rebuild forțat:

docker build --pull --no-cache -t registry.example.com/app/php-app:20261022-php8336 .
docker push registry.example.com/app/php-app:20261022-php8336

Dacă gestionezi infrastructură la scală pe servere dedicate sau cloud, automatizează acest proces prin pipeline-uri CI/CD care validează versiunea PHP în timpul build-ului. Pentru medii de hosting gestionat, consultă ofertele de servere dedicate care includ management de patching la nivel de OS.

Inventarierea proiectelor PHP la scală cu GitLab: Container Scanning, Orbit și Code Search

GitLab oferă trei instrumente complementare pentru a localiza proiectele care rulează PHP. 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

Sau aplică o scan execution policy la nivel de grup pentru a o activa pe toate proiectele odată. Container Scanning raportează vulnerabilitățile în pachete OS (apt, apk, dnf), deci va flag-ui CVE-urile odată ce ajung în baza de date a scanner-ului. Limitație: PHP compilat din sursă (inclusiv imaginile oficiale php) nu are înregistrare de pachet, așa că un proiect poate trece scanning-ul și tot rulează un PHP vulnerabil.

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

2. GitLab Orbit — graful interogabil al proiectelor

Orbit indexează proiecte, pipeline-uri, findings de securitate și cod sursă (inclusiv PHP) într-un graf interogabil. Cu Orbit activat pe grupul top-level, poți interoga un agent: „Listează toate proiectele care conțin cod PHP” — inclusiv cele care compilă PHP sau folosesc imagini php oficiale, pe care Container Scanning le ratează. Notă: Orbit nu parsează încă Dockerfile-urile (issue #1416), deci folosește lista pentru a restrânge Code Search-ul următor. Orbit este în beta pentru Premium/Ultimate pe GitLab.com și Self-Managed.

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

Activează Exact Code Search (pe GitLab.com e on-by-default pentru planuri plătite; pe Self-Managed necesită instalarea Zoekt). Rulează la nivel de grup top-level cu regular expression mode (toggle .*):

Baze de imagini container:

lang:Dockerfile ^FROM.*php

Găsește orice FROM care conține php — inclusiv derivate: wordpress, frankenphp, bitnami/php-fpm. Verifică manual rezultatele pentru false positives.

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

file:composer\.json$

Pentru fiecare rezultat, confirmă versiunea PHP citind linia FROM php:<tag> sau rulând php -v în containerul pornit, apoi compară cu tabelul de mai sus. Lista de dependențe a grupului arată pachete Composer și versiuni de framework, nu versiunea runtime-ului PHP.

4. Compară cu inventarul runtime — elimină punctele orb

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/PHP-FPM configurat manual, host-uri gestionate prin Ansible/Puppet/Chef, containere în clustere fără pipeline activ. Pentru Kubernetes, operational container scanning (GitLab Cluster Agent) scanează imaginile care rulează efectiv în cluster. Tratează orice runtime PHP care apare într-unul singur din cele două perspective (static vs. runtime) ca pe o găună de investigat.

Dacă administrezi o fermă de servere fizice sau virtuale, un inventar centralizat via soluții de infrastructure management reduce riscul de servere „uitate” care rulează PHP vulnerabil.

Remediere la scală cu GitLab Duo Agent Platform

GitLab Duo poate executa pașii de descoperire de mai sus 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 corectată. Un flow trigger pe evenimentul Assign pornește procesul în momentul atribuirii. Activează review-uri automate cu Code Review Flow care respectă custom review instructions ale tale. Review-uiește și merge MR-ul, apoi închide issue-ul odată ce versiunea corectată e deployată.

Impune cu policies. Policy-ul de approval MR din Pasul 1 blochează orice schimbare care reintroduce un PHP vulnerabil fără approval, iar scan execution policy-ul menține Container Scanning activ în fiecare proiect ca o regresie să apară în Vulnerability Report.

Un example agent skill din echipa GitLab Developer Advocacy (disponibil în repo-ul tanuki-iot-platform) automatizează inventariera: verifică imagini container, job-uri CI, pachete OS, variabile de configuration management, pin-uri Composer și medii. Returnează un tabel de findings 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, deci verifică-le direct. Adaptează skill-ul la mediul tău înainte de producție.

Indicatori de compromitere — ce să cauți în loguri începând cu 17 octombrie 2026

Honeypot-urile Amazon au înregistrat prima încercare de exploatare cunoscută pe 17 octombrie 2026, patru zile înainte de divulgarea coordonată. Dacă un server internet-facing a rulat un PHP vulnerabil, analizează logurile de la 17 octombrie înainte pentru:

Request-uri 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 inexplicate ale worker-ilor PHP sau procese shell pornite de worker-i PHP
Fișiere neașteptate pe web server-ul 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 funcțional, așa că absenta erorilor nu exclude compromiterea. Dacă găsești semne, izolează serverul și inițiază investigația de incident. Unde e posibil, capturează memorie, disc și loguri înainte de patching și restart — restartul worker-ilor PHP poate șterge dovezi. CVE-2026-109619 poate expune memoria procesului chiar și fără execuție de cod, deci roatează toate credențialele, token-urile și cheile pe care procesul PHP le putea citi.

Notă: Scannerele pot flag-ui imaginea Gemnasium dependency scanning (gemnasium:6), deprecată din GitLab 17.9, pentru PHP-ul său bundlat. E folosită doar ca tool CLI și nu procesează request-uri HTTP, deci nu e exploatabilă. O versiune corectată a fost deja lansată sub același tag.

Pași practici de acționat azi

Upgrade-ează imediat runtime-ul PHP pe toate host-urile și containere la versiunile corectate (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 sau pachetele distribuției).
Reconstruiește toate imaginile Docker care folosesc tag-uri floating php:* cu docker build --pull și redeploy-ează.
Activează Container Scanning pe toate proiectele GitLab (via template sau group policy).
Rulează Code Search la nivel de grup pentru lang:Dockerfile ^FROM.*php și file:composer\.json$; validează versiunea fiecărui rezultat.
Compară rezultatele statice cu inventarul runtime (Ansible, CMDB, Kubernetes operational scanning) și investighează discrepantele.
Auditează logurile de la 17 octombrie 2026 pentru indicatorii de compromitere listați mai sus; roate credențialele dacă e cazul.
Configurează merge request approval policies care blochează reintroducerea PHP vulnerabil.
Planifică migrarea de pe PHP 8.2 înainte de EOL (31 dec 2026) către 8.3 sau 8.4.

Concluzie

PHP2Shell demonstrează cât de critic este patching-ul la nivel de runtime când vulnerabilitatea se află în motorul de execuție, nu în codul aplicației. Niciun WAF, validare de input sau configurare de framework nu poate opri un exploit care se declanșează înainte ca orice linie de cod a ta să ruleze. Strategia robustă combine: upgrade imediat și validat al tuturor runtime-urilor, inventariere continuă statică și runtime cu instrumentele GitLab (Container Scanning, Orbit, Exact Code Search), automatizare a remedierei prin GitLab Duo Agent Platform, și monitorizare activă a indicatorilor de compromitere pe o fereastră de timp care începe înainte de divulgarea publică. Dacă gestionezi infrastructură fizică sau virtuală la scală, asigură-te că providerul tău de hosting oferă visibilitate și control complet asupra stack-ului PHP — de la OS la container și aplicație.

–