PHP2Shell (CVE-2026-109618/109619): Ghid complet de detectare, patching și verificare compromitere pentru servere PHP

Pe 21 octombrie 2026, proiectul PHP a publicat patch-uri pentru două vulnerabilități critique de remote code execution, denumite colectiv PHP2Shell (CVE-2026-109618 și CVE-2026-109619), ambele cu scor CVSS v4.0 de 9.2. Flawelor le-am găsit în motorul PHP, nu într-un framework sau librărie, ceea ce înseamnă că nicio actualizare de aplicație, validare de input sau autentificare nu poate mitiga riscul — request-ul este procesat de PHP înainte ca orice cod de aplicație să ruleze. Primele încercări de exploatare au fost înregistrate de honeypot-urile Amazon deja pe 17 octombrie, în timp ce vulnerabilitățile erau încă sub embargo. Pentru echipele care administrează servere dedicate, VPS-uri sau clustere Kubernetes care servesc aplicații PHP (WordPress, Drupal, Magento, Laravel etc.), acest articol acoperă versiunile patchate per distribuție, metodele de inventariere a proiectelor afectate, strategii de remediere automatizată și indicatori concreți 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 PHP vulnerabile și pachetele patchate per distribuție

Fixul upstream a acoperit patru ramuri active: PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35 (acesta ultimul ajungând la end-of-life pe 31 decembrie 2026). Pentru PHP 8.6, fixul a intrat în RC4 — imaginea oficială php:8.6-rc rămânea pe RC3 la data de 21 octombrie. Ramurile 8.1 și mai vechi nu primesc release-uri oficiale; PHP a publicat doar backport-uri minime de sursă pentru 7.4, 8.0 și 8.1, lăsând distribuțiile să gestioneze patch-urile.

Dacă PHP provine din pachetele distribuției, upgrade-ul pachetului este obligatoriu — compararea versiunilor din php -v nu este fiabilă, deoarece Ubuntu și RHEL mențin numărul de versiune upstream și backport-ău fixul. Iată pachetele patchate conform tracker-urilor de securitate la 22 octombrie 2026:

Comenzi practice de verificare și upgrade:

# Ubuntu/Debian - verifică versiunea pachetului instalat
dpkg -l | grep ^ii | grep php

# Upgrade pachete Ubuntu
apt update && apt upgrade php8.3 php8.3-fpm php8.3-cli -y

# Upgrade pachete Debian
apt update && apt upgrade php8.2 php8.2-fpm php8.2-cli -y

# RHEL/AlmaLinux/Rocky - verifică advisories RHSA
dnf updateinfo list sec php
dnf update php php-fpm php-cli -y

# Alpine
apk update && apk upgrade php83 php84 php85

# Restart obligatoriu după upgrade
systemctl restart php8.3-fpm   # sau php8.2-fpm, php-fpm etc.
nginx -t && systemctl reload nginx

Pentru servere gazduite la dedicated-servers.ro, recomandăm să programați o fereastră de maintenance imediată și să testați compatibilitatea aplicațiilor într-un mediu de staging înainte de rollout-ul în producție.

Detectarea proiectelor PHP afectate: container scanning, Orbit și code search

Într-un mediu enterprise cu zeci sau sute de repository-uri, găsirea tuturor proiectelor care rulează PHP necesită o abordare stratificată. GitLab oferă trei instrumente complementare pentru vizualizarea statică, pe care trebuie să le corelați ulterior cu inventarul runtime.

1. Container Scanning — detectează PHP instalat ca pachet OS (apt, apk, dnf). Activează-l per proiect sau la nivel de grup prin scan execution policy:

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

Rezultatele apar în Vulnerability Report pe branch-ul default. Limita: nu detectează PHP compilat din sursă sau din imagini oficiale php:* (fără pachet OS).

2. GitLab Orbit (beta, Premium/Ultimate) — indexează proiecte, pipeline-uri, findings și cod sursă într-un graf interrogabil. Cu Orbit activat pe grupul top-level, un agent poate lista toate proiectele care conțin cod PHP, inclusiv cele care compilează PHP sau folosesc imagini php:* oficiale. Orbit nu parsează încă Dockerfile-uri (issue #1416), deci folosește lista sa ca scope pentru code search.

3. Exact Code Search (necesită Zoekt pe Self-Managed, activ default pe GitLab.com paid) — căutări regex la nivel de grup:

# Imagini de bază PHP în Dockerfile (incluzând derivate: wordpress, frankenphp, bitnami/php-fpm)
lang:Dockerfile ^FROM.*php

# Proiecte Composer (chiar fără Dockerfile sau cu FROM $BASE_IMAGE)
file:composer\.json$

Pentru fiecare rezultat, confirmă versiunea: inspectează linia FROM php:<tag> sau rulează php -v în containerul pornit. Lista de dependențe din grup arată pachete Composer și versiuni de framework, nu versiunea runtime PHP.

4. Corelare cu inventarul runtime — scanning-ul static arată ce declară și construiește proiectul, nu ce rulează de fapt. PHP poate rula pe servere cu mod_php sau PHP-FPM configurate manual, pe host-uri gestionate de Ansible/Puppet/Chef, sau în containere deployate fără pipeline activ. Pentru Kubernetes, operational container scanning GitLab scanează imaginile care rulează în cluster (doar detecție de pachete OS). Tratează fiecare runtime PHP care apare într-o singură vizualizare ca un gap de investigat.

Remediere la scară largă: rebuild container images, upgrade pachete, policies

Remedierea nu se oprește la identificare. Pentru medii mari, automatizarea reduce fereastra de expunere și elimină erorile umane.

Rebuild imagini container — obligatoriu pentru orice imagine care folosește tag-uri flotante (php:8, php:8.3, php:8.3-apache, php:latest):

# Pull imagine de bază actualizată și rebuild
docker build --pull -t registry.example.com/myapp:v1.2.3 .
docker push registry.example.com/myapp:v1.2.3

# Pentru imagini cu tag pinned (ex: php:8.3.35-apache), actualizează Dockerfile-ul:
# FROM php:8.3.36-apache

Imaginile derivate (wordpress, drupal, bitnami/php-fpm) primesc fixul doar după ce maintainer-ii publică update-uri — verifică upstream înainte de rebuild.

Automatizare cu GitLab Duo Agent Platform — Agentic Chat poate crea un epic cu un issue per proiect afectat și atribui Developer Flow fiecăruia. Flow-ul deschide MR care actualizează tag-ul imaginii de bază sau pachetul la versiunea patchată. Un flow trigger pe evenimentul Assign pornește remedierea automat. Activează Code Review Flow cu custom review instructions pentru o primă review automatizată conform standardelor echipei.

Enforcare prin policies — Merge Request Approval policy din Container Scanning blochează orice modificare care reintroduce o versiune PHP vulnerabilă fără aprobare. Scan execution policy menține container scanning activ în toate proiectele, astfel încât o regresie apare imediat în Vulnerability Report.

Exemplu skill agent read-only (GitLab Developer Advocacy) — 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, medii. Returnează tabel de findings cu dovezi de deployment și gap-uri deschise. Nu face modificări — MR-urile de remediere rămân un pas separat, revizuit. Adaptează skill-ul la mediul tău înainte de utilizare.

Pentru infrastructuri gazduite pe serverspan.ro, integrarea cu GitLab CI/CD și politikile de securitate la nivel de grup permite rollout-uri coordonate pe sute de noduri cu audit trail complet.

Verificare compromitere: indicatori de atac și proceduri de investigație

Rapoartele de exploatare diverge. Cercetătorii de securitate au raportat încercări de exploit de pe 17 octombrie (înainte de divulgare publică), urmate de trafic de atac după release. Proiectul PHP nu a identificat exploit-uri funcționale la momentul release-ului. Dacă un server internet-facing a rulat o versiune PHP vulnerabilă, analizează log-urile de la 17 octombrie 2026 încoace pentru:

Request-uri multipart urmate de erori memory_limit sau răspunsuri HTTP 500 repetitive
Cookie-uri PHPSESSID de răspuns anormal de mari sau malformate
Restart-uri neexplicate ale worker-ilor PHP, sau procese shell pornițe de worker-i PHP
Fișiere neașteptate pe web server-ul PHP, conexiuni outbound din worker-i PHP, sau intrări cron neașteptate

Important: Un exploit reușit poate returna HTTP 200 și lăsa worker-ul rulând — absența erorilor nu exclude compromiterea. CVE-2026-109619 poate expune memoria procesului chiar și fără code execution.

Procedură dacă găsești semne de compromitere:

Isolează serverul din rețea (firewall, security group, cable pull)
Pornește investigație incident conform runbook-ului organizației
Captură dovezi înainte de patching/restart: dd disk image, gcore/procfs memory dump, log-uri complete (access, error, auditd, journalctl)
Restart-ul worker-ilor PHP poate șterge dovezi din memorie — capturează primul
Rotește toate credențialele, token-urile, cheile pe care procesul PHP putea citi (DB passwords, API keys, JWT secrets, SSH keys, AWS/GCP/Azure credentials)

# Exemple comenzi forensice rapide (rulează CA ROOT pe serverul suspect)
# 1. Procese suspecte
ps auxf | grep -E 'php|sh|bash|python|perl|nc|wget|curl'

# 2. Conexiuni de rețea din worker-i PHP
ss -tunap | grep php

# 3. Fișiere create/modificate recent în document root
find /var/www -type f -mtime -7 -ls 2>/dev/null | head -50

# 4. Verifică cron jobs
crontab -l -u www-data 2>/dev/null
ls -la /etc/cron* /var/spool/cron/

# 5. Dump memorie pentru un PID PHP suspect
gcore -o /tmp/php_core_<PID> <PID>

# 6. Imagistică disc (dacă ai spațiu pe alt disc/partiție)
dd if=/dev/sda of=/mnt/forensics/sda_$(date +%F).img bs=4M status=progress

Notă: Scanerele pot flag-ui imaginea gemnasium:6 (deprecated din GitLab 17.9) pentru PHP-ul său bundled. Este folosită doar ca tool CLI și nu gestionează request-uri HTTP, deci nu este exploatabilă. O versiune patchată a fost publicată sub același tag.

Pași practici imediată

Inventariează toate host-urile, containerele și imaginile care rulează PHP (inclusiv dashboards interne, site-uri marketing, job-uri CI)
Upgradează pachetele OS la versiunile patchate de mai sus și restartează toate procesele PHP-FPM/mod_php
Rebuild-uiește toate imaginile container cu --pull și tag-uri pinate la versiunile fixe (8.5.12, 8.4.27, 8.3.36, 8.2.35)
Activează Container Scanning + scan execution policy pe toate grupurile GitLab
Rulează code search regex pentru Dockerfile-uri și composer.json la nivel de top-group
Corelază rezultatele statice cu inventarul runtime (Ansible, CMDB, cloud inventory, k8s operational scanning)
Analizează log-urile de la 17 oct 2026 pentru indicatori de compromitere; daca găsești dovezi, izolează și capturează forensics înainte de orice restart

–

Concluzie: PHP2Shell demonstrează cât de critică este separarea între codul aplicației și runtime-ul care îl execută. Fără patch la nivel de motor PHP, niciun WAF, validare input sau update de framework nu protejează serverul. Prioritatea absolută: upgrade runtime la versiunea patchată astăzi, urmat de inventariere completă, automatizare remediere și audit compromitere. Echipele care integrează scanning-ul continuu în pipeline (Container Scanning, Orbit, policies) reduc fereastra de expunere de la zile la minute. Pentru infrastructuri critice gazduite în România, parteneriatele cu provideri care oferă servere dedicate cu management securitate inclusiv — precum cele de la dedicated-servers.ro — permit aplicarea rapidă a patch-urilor și monitorizarea continuă a surface-ului de atac.

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

Versiunile PHP vulnerabile și pachetele patchate per distribuție

Detectarea proiectelor PHP afectate: container scanning, Orbit și code search

Remediere la scară largă: rebuild container images, upgrade pachete, policies

Verificare compromitere: indicatori de atac și proceduri de investigație

Pași practici imediată

Articole ServerSpan relevante

Lasă un răspuns Anulează răspunsul