Pe 21 octombrie 2026, proiectul PHP a publicat o lansare de securitate de urgență care adresază două vulnerabilități critice de execuție de cod la distanță, cunoscute colectiv sub numele de PHP2Shell. Ambele primesc scorul maxim de 9.2 pe CVSS v4.0 și resida în motorul PHP — nu într-un framework, bibliotecă sau cod de aplicație. Aceasta înseamnă că nicio actualizare de framework, validare de input sau autentificare nu poate mitiga problema; singura soluție este actualizarea runtime-ului PHP pe fiecare gazdă și imagine de container. Atacurile au fost înregistrate de honeypot-urile Amazon (MadPot) încă din 17 octombrie, patru zile înainte de divulgarea publică, ceea ce transformă patching-ul într-o cursă împotriva timpului. În acest articol parcurgem versiunile corectate per ramură și per distribuție, metodele de inventariere a proiectelor PHP în GitLab, automatizarea remedierei cu GitLab Duo Agent Platform și indicatorii de compromitere pe care trebuie să îi monitorizezi.
Pentru mai multe detalii despre această parte a subiectului, vezi Actualizare Importantă: Securitate și Performanță PHP Îmbunătățite pentru Hosting Partajat.
Versiunile PHP Corectate și Pachetele de Distribuție — Ce Trebuie Să Instalezi Acum
Lansările oficiale PHP din 21 octombrie 2026 acoperă patru ramuri active:
| Ramură PHP | Versiune Corectată | 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 |
Pentru ramurile vechi (7.4, 8.0, 8.1) nu există lansări oficiale noi; PHP a publicat doar backport-uri minime de sursă, iar unele distribuții livră pachete patch-uite.
Important: Dacă PHP provine din pachetele distribuției, actualizează pachetul, nu compilă din sursă. 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.4fără 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
Ubuntu și Red Hat (pentru 7.4 și 8.0) mențin numărul de versiune upstream vechi și backport-ează fixul. Compara versiunile pachetelor, nu ieșirea php -v. După actualizare, repornește fiecare proces care rulează PHP (php-fpm, Apache cu mod_php, workeri CLI de lungă durată).
Reconstruire Imagini Container
Dacă folosești tag-uri flotante ale imaginii oficiale php (php:8, php:8.3, php:8.3-apache, php:latest), reconstruiește cu --pull și redesploy-ează:
docker build --pull -t registry.example.com/app:php2shell-fixed .
docker push registry.example.com/app:php2shell-fixedImaginile care fixează versiunea patch (php:8.3.35-apache) necesită schimbarea tag-ului la versiunea corectată înainte de rebuild. Derivatele (wordpress, drupal, bitnami/php-fpm, frankenphp) primesc fixul doar după ce maintainer-ii publică imagini actualizate — verifică upstream-ul înainte de rebuild.
Ghid ServerSpan relevant: CVE-2026-12184: Ghid de Patch pentru DoS în PHP-FPM (8.3.32 / 8.4.21 / 8.5.6).
Localizare Proiecte PHP în Grupurile GitLab — Inventar Static vs. Runtime
Orice proiect care rulează PHP pentru a servi cereri web necesită versiune corectată, inclusiv cele uite de ușor: dashboard-uri interne, site-uri marketing, imagini CI job. GitLab oferă trei instrumente pentru vizualizarea statică; folosește-le în această ordine:
1. Container Scanning — Detectează PHP Instalat ca Pachet OS
Container Scanning raportează vulnerabilități în pachete OS (apt, apk, dnf) și va semnala cele două CVE-uri odată ce intră în baza de date a scanner-ului. Activează-l per proiect adăugând în .gitlab-ci.yml:
include:
- template: Security/Container-Scanning.gitlab-ci.ymlSau, mai eficient, folosește o politică de execuție la nivel de grup pentru a-l porni pe toate proiectele odată. Rezultatele apar în Vulnerability Report pe default branch.
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 un PHP vulnerabil.
2. GitLab Orbit — Graf Interogabil de Proiecte, Pipeline-uri și Găsiri
Orbit indexează proiectele, pipeline-urile, găsirile 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ă.
Notă: Orbit nu parsează încă Dockerfile-urile (work item #1416). Folosește lista sa pentru a restrânge căutarea de cod din pasul 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 Proiecte Composer
Activează modul regex (toggle .* în caseta de căutare) la nivel de grup top-level:
Imagini de bază container:
lang:Dockerfile ^FROM.*phpAceasta găsește orice FROM a cărei nume sau tag conține php — inclusiv derivate (wordpress, frankenphp, bitnami/php-fpm). Exclud fals-pozitivele citind rezultatul.
Proiecte Composer (fără Dockerfile sau cu FROM $BASE_IMAGE):
file:composer\.json$Exact Code Search acoperă doar default branch. Pe GitLab.com e activ implicit pentru planuri plătite. Pe Self-Managed adminul trebuie să instaleze Zoekt. GitLab Dedicated nu îl suportă.
4. Compară cu Inventarul Runtime — Elimină Golurile
Container Scanning și Code Search arată ce declară și compilează proiectele, nu ce rulează de fapt. PHP poate rula în afara proiectelor GitLab: servere web cu mod_php sau PHP-FPM activate doar în configurație, gazde configureate manual, containere care rulează în clustere fără pipeline activ. Pentru Kubernetes, Operational Container Scanning scanează imaginile care rulează în clustere (aceeași detectare doar-pachete).
Tratează fiecare runtime PHP care apare într-o singură dintre cele două vizualizări (statică vs. runtime) ca un gol de investigat.
Remediere la Scală cu GitLab Duo Agent Platform — Automatizează Reprezentativ
Descoperirea de mai sus poate fi rulată de GitLab Duo prin Orbit și Code Search pe toate proiectele. De acolo, lasă agenții să facă munca repetitivă și ține 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 asignării issue-ului. Activează review-uri automate cu Code Review Flow pentru a obține o prima review care urmează instrucțiunile tale de review personalizate. Review-uiește și merge-uiește fiecare MR, apoi închide issue-ul odată ce versiunea corectată e deploy-uită.
Forțează 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 scanning menține Container Scanning activ în fiecare proiect — o regresie apare în Vulnerability Report.
Skill-ul PHP2Shell Inventory (Read-Only)
Echipa Developer Advocacy a publicat un skill exemplu care 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
- Environments
Returnează un tabel de găsiri citate cu dovezi de deployment și goluri deschise. E read-only — nu face schimbări; MR-urile de remediere rămân un pas separat, revizuit. Nu poate confirma ce rulează pe gazde la care nu are acces — verifică-le direct.
Verificare Compromitere — Indicatorii de Atac și Pașii de Urgență
Rapoartele de exploatare difere. Cercetătorii de securitate au raportat o încercare de exploit pe 17 octombrie 2026, înainte de divulgare publică, urmate de alte rapoarte post-release. Proiectul PHP n-a identificat exploit-uri funcționale la momentul lansării. Dacă un server internet-facing a rulat un PHP vulnerabil, revizuiește log-urile de la 17 octombrie 2026 înainte pentru:
- Cereri multipart urmate de erori
memory_limitsau răspunsuri HTTP 500 repetitive - Cookie-uri PHPSESSID anormal de mari sau malformate în răspuns
- 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
Atenție: Un exploit reușit poate returna HTTP 200 și lăsa worker-ul rulează — absența erorilor nu exclude compromiterea.
Dacă găsești semne de exploatare:
- Izoilează serverul imediat
- Pornește investigația de incident
- Captură memorie, disc și log-uri înainte de patching și restart
- Restart-ul workeri PHP poate șterge dovezi
- CVE-2026-109619 poate expune memoria procesului chiar și fără execuție de cod — rotesțe orice credențiale, token-uri sau chei pe care procesul PHP le putea citi
Notă: Scanerele pot semnala 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 gestionează cereri HTTP, deci nu e exploatabilă; o versiune corectată a fost livrată sub același tag.
–
Pași Practici de Acțiune Imediată
- Inventariează toate gazdele și containerele care rulează PHP (inclusiv CI jobs, sidecars, workeri batch) — folosește Ansible, Puppet, Chef sau inventory tools cloud
- Actualizează runtime-ul PHP la versiunile corectate de mai sus; pentru pachete OS, compară versiunile pachetelor, nu
php -v - Reconstruiește și redesploy-ează toate imaginile container cu tag-uri flotante folosind
docker build --pull - Activează Container Scanning via politică de grup în GitLab; rulează Exact Code Search pentru
FROM.*phpșifile:composer\.json$ - Compară rezultatele statice cu inventarul runtime (Operational Container Scanning pentru K8s, CMDB pentru VM/bare-metal)
- Automatizează MR-urile de remediere cu GitLab Duo Agent Platform + Developer Flow; forțează cu politici de aprobare MR
- Auditează log-urile de la 17 oct 2026 înainte pe serverele internet-facing; rotește credențialele dacă există îndoieli
–
Concluzie
PHP2Shell nu e o vulnerabilitate de aplicare — e o vulnerabilitate de motor, și asta schimbă tot jocul. Nu poți patch-uia codul tău; trebuie să patch-uiezi platforma pe care rulează. Distribuțiile au livrat pachete corectate în ore de la release, dar responsabilitatea rămâne a ta: să le instalezi, să reconstruiești containerele, să verifici că nicio instanță PHP nu a scăpat înventarului (chiar și dashboard-ul intern uitat din 2019), și să auditezi log-urile pentru semne de compromitere anterioară. GitLab oferă tooling-ul pentru a face asta la scală — Container Scanning, Orbit, Exact Code Search, și acum Duo Agent Platform — dar decisia de a actiona acum e a ta. Dacă gestionezi servere dedicate sau VPS-uri care rulează PHP, asigură-te că infrastructura ta e patch-uită end-to-end; o singură instanță neactualizată e suficientă pentru compromisare totală.
