Pe 21 octombrie 2026, proiectul PHP a publicat patch-uri de urgență pentru două vulnerabilități critice de execuție remote a codului, grupate sub numele de PHP2Shell (CVE-2026-109618 și CVE-2026-109619). Ambele au scorul maxim de 9.2 pe CVSS v4.0 și rezidă în motorul PHP, nu în framework-uri sau biblioteci, ceea ce înseamnă că niciun fix la nivel de aplicație nu există. Orice server web care rulează PHP — Apache cu mod_php, NGINX cu PHP-FPM, FrankenPHP, LiteSpeed sau php-cgi — este expus. Cercetătorii de la Wiz și Calif (asistat de GPT-5.6) au descoperit independent fall-urile, iar honeypot-urile Amazon au înregistrat primul încercare de exploatare pe 17 octombrie, încă sub embargo. Dacă administrezi servere dedicate sau VPS-uri care servesc aplicații PHP, actualizarea runtime-ului este singura countermeasure validă. În acest articol acoperim versiunile corectate per branch și distribuție, metodologia de inventariere a proiectelor PHP la scară largă cu GitLab, automatizarea remedierei ș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).
Actualizează PHP la o versiune corectată — acum
Fix-ul trebuie aplicat la runtime-ul PHP pe fiecare host și în fiecare imagine container. Actualizările Composer, validarea input-ului, autentificarea sau patch-urile la framework-uri (Laravel, Symfony, WordPress, Drupal, Magento) nu ajută, deoarece motorul PHP procesează request-ul înainte ca orice cod de aplicație să ruleze. Tabelul de mai jos centralizează versiunile corectate oficiale:
| 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 | — | | PHP 8.2.x | 8.2.35 | End of life: 31 decembrie 2026 | | PHP 8.6 RC | 8.6.0RC4 | RC3 (imaginea php:8.6-rc oficială) era vulnerabilă la 21 oct | | 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 livrare pachete patch-uite |
Dacă PHP vine din pachetele distribuției, actualizează pachetul respectiv — nu te baza pe php -v, căci Ubuntu și Red Hat păstrează numărul de versiune upstream și backportează fix-ul. 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.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ă upgrade, repornește fiecare proces care rulează PHP (php-fpm, apache2, nginx, frankenphp, litespeed). Pe serverele dedicate gestionate de tine sau pe VPS-uri de la https://www.dedicated-servers.ro/, comanda tipică este:
# Ubuntu/Debian
sudo apt update && sudo apt install --only-upgrade php8.3 php8.3-fpm php8.3-cli
sudo systemctl restart php8.3-fpm apache2 nginx
# RHEL/AlmaLinux/Rocky
sudo dnf update php php-fpm php-cli
sudo systemctl restart php-fpm httpd nginx
# Alpine
apk upgrade php83 php83-fpm php83-cli
rc-service php-fpm83 restartReconstruiește imaginile container. Dacă folosești tag-uri flotante (php:8, php:8.3, php:8.3-apache, php:latest), reconstruiește cu docker build --pull și redeploy-ează. Imaginile care pînnesc versiunea patch (php:8.3.35-apache) trebuie să aibă tag-ul schimbat la versiunea corectată înainte de rebuild. Derivatele (wordpress, drupal, bitnami/php-fpm, frankenphp) primesc fix-ul doar după ce maintainer-ii publică imagini actualizate — verifică upstream-ul înainte de rebuild.
Localizează proiectele PHP în grupurile GitLab
Orice proiect care rulează PHP pentru a servi request-uri web are nevoie de versiune corectată, inclusiv cele ușor de uitat: dashboard-uri interne, site-uri marketing, imagini de CI job. Găsirea lor necesită două perspective: o analiză statică a ceea ce declară repository-urile și imaginile, și un inventar runtime al ceea ce rulează de facto. GitLab acoperă vizualizația statică cu două funcții — folosește ambele, în această ordine.
1. Container Scanning
Container Scanning raportează vulnerabilități în pachetele de sistem de operare, deci detectează PHP instalat cu apt, apk sau dnf, și raportează cele două CVE odată ce ajung în baza de date a scanner-ului. Pentru a-l activa pe un proiect, adaugă template-ul în .gitlab-ci.yml:
Pentru mai multe detalii despre această parte a subiectului, vezi Actualizare Importantă: Securitate și Performanță PHP Îmbunătățite pentru Hosting Partajat.
include:
- template: Security/Container-Scanning.gitlab-ci.ymlPoți folosi și o politică de execuție la nivel de grup pentru a activa container scanning pe toate proiectele dintr-un grup odată. Când politica este activată, la următoarea rulare de pipeline, container scanning va fi inclus. Rezultatele pentru branch-ul default pot fi revizuite în Vulnerability Report după completarea scan-ului.
De asemenea, poți configura politici de aprobare Merge Request cu container scanning. Dacă o schimbare de cod conține PHP2Shell, politica va bloca merge-ul fără aprobarea părților selectate.
Limitare: Container scanning detectează doar PHP instalat ca pachet. PHP compilat din sursă, inclusiv imaginile oficiale
php:*, nu are înregistrare de pachet, deci un proiect poate trece container scanning și tot rulează un PHP vulnerabil. Code search acoperă această lacăună.
2. Code Search (Exact Code Search)
Exact code search găsește cele două tipuri de fișiere care indică un proiect PHP. Rulează aceste query-uri la nivelul grupului top-level cu regular expression mode activat (toggle-ul .* dreapta căsuței de căutare):
Imagini de bază container (Dockerfile-uri):
lang:Dockerfile ^FROM.*phpAcest pattern potrivește orice imagine a cărei nume sau tag conține php, găsind și derivate: wordpress, frankenphp, bitnami/php-fpm, etc. Așteaptă-te la câteva false positives 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 din build argument (FROM $BASE_IMAGE).
Exact code search acoperă doar branch-ul default. Pe GitLab.com este activat 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 la nivel de grup arată pachete Composer și versiuni de framework, dar nu versiunea runtime PHP.
3. 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 activate doar în configurație, pe host-uri configurate manual, sau containere care rulează încă în clustere fără un pipeline activ. Compară rezultatele statice cu un inventar al workload-urilor care rulează din configuration management (Ansible, Puppet, Chef), cloud sau tool-uri de inventar VM. Pentru Kubernetes, operational container scanning scanează imaginile care rulează în clustere, cu aceeași detectare doară-pachet. Tratează fiecare runtime PHP care apare doar într-una din cele două vizualizări ca un gap de investigat.
Remediere la scară largă cu GitLab Duo Agent Platform
Începe prin a întreba GitLab Duo Agentic Chat să:
- Colecteze toate finding-urile de container scanning pentru CVE-2026-109618 și CVE-2026-109619 în grup din Vulnerability Report (cere abonament Ultimate)
- Ruleze query-urile de code search de mai sus în grup, revizuiască fiecare hit și citească versiunea PHP din Dockerfile sau fișiere Composer
- Deschidă un merge request per proiect afectat care bumpează tag-ul imaginii de bază sau pachetul la versiunea corectată, și atasează-l maintainer-ului potrivit
- Urmărească efortul întreg într-un epic cu un issue per proiect, închis când versiunea corectată este deployată și confirmată
Din fiecare issue, Developer Flow poate deschide un merge request care actualizează tag-ul imaginii de bază sau pachetul la versiune corectată. Activează review-uri automate cu Code Review Flow pentru a obține o primă review care urmează instrucțiunile tale custom de review. Revizuiește și merge-uiește fiecare MR, apoi închide issue-ul odată ce versiunea corectată este deployată.
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 ceea ce declară codul de ce rulează de fapt. Un skill exemplu 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 glab CLI, precum Claude Code, Codex, și Cursor.
Skill-ul verifică imagini container, job-uri CI, pachete OS, variabile configuration management, pin-uri Composer, și environmente. Returnează un tabel de finding-uri citate cu dovezi de deployment, și gap-uri deschise. Skill-ul este read-only: nu face schimbări, și 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
Rapoartele de exploatare difere. Cercetătorii de securitate au raportat o încercare de exploatare pe 17 octombrie 2026, înainte de divulgarea publică, urmate de alte raporte după release. Proiectul PHP nu a identificat exploit-uri funcționale la momentul release-ului. Dacă un server internet-facing a rulat un PHP vulnerabil, revizuiește log-urile sale de la 17 octombrie 2026 încoace pentru:
- Request-uri multipart urmate de erori
memory_limitsau 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 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 worker-ul rulând, deci absența erorilor nu exclude compromiterea. Dacă găsești semne de exploatare, izolează serverul și pornește 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 chei pe care procesul PHP le-a putut citi.
Notă: Scannerele pot flag-ui imaginea de dependency scanning Gemnasium (
gemnasium:6), deprecata de GitLab 17.9, pentru PHP-ul său bundlat. Este folosită doar ca tool linie de comandă și nu gestionează request-uri HTTP, deci nu e exploatabilă, și o versiune corectată a fost livrată deja sub același tag.
–
Pași practici de acțiune imediată
- Inventariează toate host-urile și containerele care rulează PHP (inclusiv CI runners, build agents, sidecars)
- Actualizează runtime-ul PHP la versiunile corectate per tabelul de mai sus; reconstruiește și redeploy-ează toate imaginile container
- Activează Container Scanning + Exact Code Search în GitLab pentru a găsi proiectele PHP declarate
- Compară rezultatele statice cu inventarul runtime real (Ansible, cloud inventory, operational container scanning K8s)
- Folosește GitLab Duo Agent Platform pentru a automatiza colectarea finding-urilor, deschiderea MR-urilor și tracking-ul prin epic
- Auditează log-urile de la 17 oct 2026 pentru semne de compromitere; rotește secretele dacă e cazul
- Documentează întregul proces pentru audit și post-mortem
–
Concluzie
PHP2Shell demonstrează că vulnerabilitățile la nivel de runtime a limbajelor de programare au un blast radius masiv — orice aplicație care rulează pe motorul afectat este expusă, indiferent de calitatea codului propriu. Faptul că exploit-ul a fost observat înainte de divulgare (17 oct vs 21 oct) subliniază nevoia de procese de patch management rapide, automate și verificate. GitLab oferă tooling-ul pentru a descoperi, remedia și urări impactul la scară, dar responsabilitatea rămâne la echipele de platformă și securitate să acționeze acum. Dacă gestionezi infrastructură critică pe care rulează PHP — fie că vorbim de servere dedicate la https://www.dedicated-servers.ro/ sau de VPS-uri la https://www.serverspan.ro/ — fereastra de expunere se închide doar când ultimul proces PHP a fost repornit pe versiunea patch-uită.
–
