PHP2Shell (CVE-2026-109618 și CVE-2026-109619): Ghid complet de remedieri pentru infrastructură PHP

Două vulnerabilități critice de execuție a codului la distanță în motorul PHP — denumite colectiv PHP2Shell — au fost remedate pe 21 octombrie 2026 prin versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Cu scoruri CVSS v4.0 de 9.2, CVE-2026-109618 și CVE-2026-109619 afectează orice server web care rulează PHP (Apache cu mod_php, NGINX cu PHP-FPM, containere, VM-uri), indiferent de framework sau aplicație. Deoarece exploatarea are loc înainte ca orice cod de aplicație să ruleze, actualizarea runtime-ului este singura mitigare reală. Acest ghid acoperă versiunile remediate per distribuție, reconstrucția imaginilor container, inventarierea proiectelor PHP la scară largă cu GitLab, ș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 remediate și pachetele per distribuție

Proiectul PHP a publicat corecții pentru cele patru ramuri active. Dacă folosești pachete din distribuție, compară versiunea pachetului, nu php -v — Ubuntu, Debian și RHEL backportează fixurile păstrând numărul de versiune upstream.

| Ramură PHP | Versiune fixată | 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 | EOL 31 decembrie 2026 — planifică migrarea către 8.3+ | | 8.6 RC | 8.6.0RC4 | RC3 (imaginea php:8.6-rc la 21 oct) nu conține fixul | | 8.1 și mai vechi | Fără release oficial | Există backport-uri minime de sursă pentru 7.4, 8.0, 8.1; unele distribuții livrez pachete patchuite |

Pachete distribuție (stare 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 fără fix la 22 oct
RHEL 8: php:7.4 7.4.33-8 (RHSA-2026:87080); stream-urile retrograde (7.2, 7.3, 8.0) nu primesc fix

Acțiune imediată: apt update && apt upgrade php* / dnf update php* / apk upgrade php83 php84 php85 pe toate gazdele și containerele care servesc cereri HTTP. Repornește toate procesele PHP (php-fpm, apache, containere) după upgrade.

Reconstruire imagini container: floating tags vs. pinned tags

Imaginile oficiale php:* compilează PHP din sursă — nu lăsând urmă de pachet — deci Container Scanning standard nu le detectează. Reguli practice:

# ❌ Floating tag — reconstruiește CU --pull
FROM php:8.3-apache
# sau
FROM php:8.3-fpm

# ✅ Pinned tag — actualizează tag-ul la versiune fixată
FROM php:8.3.36-apache
FROM php:8.3.36-fpm

Reconstruire forțată (floating tags):

docker build --pull --no-cache -t myapp:php2shell-fix .
docker push myapp:php2shell-fix
# redeploy în Kubernetes / Swarm / Compose
kubectl rollout restart deployment/myapp

Imagini derivate (wordpress, drupal, frankenphp, bitnami/php-fpm): fixul ajunge doar după ce maintainer-ul upstream publică imaginea actualizată. Verifică docker pull <image>:<tag> și reconstruiește local dacă e necesar.

Notă: Imaginea gemnasium:6 (deprecită din GitLab 17.9) este semnalată de scanere pentru PHP-ul inclus, dar nu procesează cereri HTTP — nu este exploatabilă. O versiune fixată există sub același tag.

Inventariere proiecte PHP la scară largă cu GitLab

Găsirea tuturor workload-urilor PHP necesită două perspective: statică (ce declară repo-urile și imaginile) și runtime (ce rulează de facto). GitLab acoperă vista statică cu trei instrumente — folosește-le în această ordine:

1. Container Scanning (cu binary scan experimental)

Activează template-ul în .gitlab-ci.yml sau via Scan Execution Policy la nivel de grup:

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

container_scanning:
  variables:
    # Ultimate only: detectează runtimes instalate fără package manager
    CS_BINARY_SCAN: "true"

Analyzer-ul v8.7.0 (29 oct 2026) adaugă CS_BINARY_SCAN care raportează PHP compilat din sursă (imaginile php:* oficiale). Rezultatele apar în Vulnerability Report pe default branch. Adaugă Merge Request Approval Policy cu Container Scanning pentru a bloca merge-uri care reintroduc versiuni vulnerabile.

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 (beta, Premium/Ultimate)

Orbit indexează proiecte, pipeline-uri, findings și cod sursă într-un graf interogabil. Cu Orbit activat pe grupul top-level, un agent poate lista toate proiectele care conțin cod PHP, incluzând cele care compilează PHP sau folosesc imaginile php:* (pe care Container Scanning le ratează fără binary scan).

# Exemplu interogare Orbit (prin agent)
"Listează toate proiectele din grup care conțin fișiere .php sau Dockerfile-uri cu baza php"

Orbit nu parseau încă Dockerfile-urile (issue #1416) — folosește lista pentru a limita Code Search-ul următor.

3. Exact Code Search (Zoekt, paid plans / Self-Managed cu Zoekt instalat)

Caută la nivel de grup top-level cu regex mode (butonul .* în căsuța de căutare):

Baze de imagine container:

lang:Dockerfile ^FROM.*php

Găsește FROM php:8.3-apache, FROM wordpress:latest, FROM bitnami/php-fpm:8.2, FROM frankenphp, etc. Elimină fals-pozitivele inspectând rezultatul.

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

file:composer\.json$

Verificare obligatorie per rezultat: citește linia FROM php:<tag> sau rulează php -v în containerul pornit și compară cu tabelul de versiuni fixate. Lista de dependențe din grup arată pachete Composer și versiuni framework, nu versiunea runtime PHP.

4. Comparare cu inventarul runtime

Container Scanning și Code Search arată ce se construiește, nu ce rulează. PHP poate rula în afara proiectelor GitLab:

Servere web cu mod_php / php-fpm configurat manual
Gazde gestionate cu Ansible, Puppet, Chef
Containere în clustere fără pipeline activ

Pentru Kubernetes: Operational Container Scanning (agent GitLab) scanează imaginile care rulează în cluster, cu aceeași limitare package-only. Tratează orice runtime PHP care apare doar într-una din cele două viziuni ca gap de investigat.

Remediere la scară cu GitLab Duo Agent Platform

GitLab Duo poate automatiza descoperirea de mai sus prin Orbit și Code Search, apoi delega munca repetitivă agentilor, păstrând oamenii pe review și merge.

Automatizează fixul:

Folosește Agentic Chat pentru a crea un epic cu un issue per proiect afectat.
Asignează Developer Flow fiecărui issue — flow-ul deschide MR care actualizează tag-ul de bază sau pachetul la versiune fixată.
Configurează Flow Trigger pe evenimentul Assign pentru pornire automată.
Activează Code Review Flow cu automatic reviews conform Custom Review Instructions ale tale.
Review-uiește și merge-uiește fiecare MR, apoi închide issue-ul odată deployat.

Impune cu policy-uri:

Merge Request Approval Policy (din Container Scanning) blochează orice schimbare care reintroduce PHP vulnerabil fără aprobare.
Scan Execution Policy menține Container Scanning activ în toate proiectele — o regresie apare în Vulnerability Report.

Skill exemplu (read-only): Echipa Developer Advocacy a publicat un skill PHP2Shell care rulează pe GitLab Duo Agent Platform / MCP Server / glab CLI (Claude Code, Codex, Cursor). Verifică imagini container, job-uri CI, pachete OS, variabile config management, pin-uri Composer, environmente. Returnează tabel cu dovezi de deployment și gap-uri deschise. Nu face modificări — MR-urile de remediere rămân pas separat, revizuit. Adaptează skill-ul la mediul tău înainte de utilizare.

Verificare compromitere: semne de exploatare

Raportările diferă: cercetători au văzut încercări de exploatare pe 17 octombrie 2026 (înainte de divulgare publică), urmate de altele după release. Proiectul PHP nu a identificat exploit-uri funcționale la momentul release-ului. Dacă un server internet-facing a rulat PHP vulnerabil, inspectează log-urile de la 17 octombrie 2026 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
Reporniri inexplicate ale worker-ilor PHP, sau procese shell pornite de worker-i PHP
Fișiere neașteptate pe document root, conexiuni outbound de la worker-i PHP, intrări cron nedefinite

Atenție: Un exploit reușit poate returna HTTP 200 și lăsa worker-ul funcțional — absența erorilor nu exclude compromiterea. CVE-2026-109619 poate expune memorie proces chiar fără execuție de cod.

Dacă găsești semne:

Isolează serverul imediat.
Pornește investigație incident.
Captură memorie, disc, log-uri înainte de patching și restart.
Restart-ul worker-ilor PHP poate șterge dovezi.
Rotește toate credențialele, token-urile, cheile pe care procesul PHP le putea citi.

–

Pași practici de acțiune imediată

Inventariează toate gazdele, containerele, VM-urile și clusterele care rulează PHP (Ansible, Puppet, cloud inventory, Kubernetes agent).
Upgrade-ează runtime-ul PHP la versiunea fixată per tabelul de mai sus; repornește toate procesele PHP.
Reconstruiește imaginile container cu docker build --pull (floating tags) sau actualizează tag-urile pinned; redeploy-ează.
Activează Container Scanning cu CS_BINARY_SCAN: "true" + Scan Execution Policy + MR Approval Policy pe grupul top-level GitLab.
Rulează Orbit și Exact Code Search pentru a găsi proiectele ratate de scanning; validează versiunea per proiect.
Compară rezultatele statice cu inventarul runtime; investighează gap-urile.
Inspectează log-urile de la 17 oct 2026 pentru semnele de compromitere enumerate mai sus.
Automatizează remedierea la scară cu GitLab Duo Agent Platform (Agentic Chat → Developer Flow → Code Review Flow).

–

Concluzie

PHP2Shell demonstrează că vulnerabilitățile în runtime-ul de bază nu pot fi mitigate la nivel de aplicație — framework-uri, validare input, autentificare, WAF-uri sunt ineficace când exploitul ajunge înainte de bootstrap-ul aplicației. Singura apărare reală este patch management riguros la nivel de infrastructură: versiuni fixe per distribuție, reconstrucție imagini container, inventariere continuă (statică + runtime), și policy-uri care previn regresiile. GitLab oferă toolchain-ul complet — de la Container Scanning cu binary scan, Orbit și Code Search pentru descoperire, la Duo Agent Platform pentru remediere automatizată — dar responsabilitatea de a rula aceste pași acum, nu „în sprint-ul viitor”, aparține echipei de platformă. Dacă administrezi servere dedicate sau infrastructură cloud care servește PHP, verifică ofertele noastre de servere dedicate pentru hardware izolat cu control total pe patching, sau exploră soluțiile de hosting gestionat unde管理ul securității runtime este inclus.

–