Două vulnerabilități critice de remote code execution în PHP, dublate sub numele de PHP2Shell, au fost adăugate de CISA în catalogul Known Exploited Vulnerabilities doar câteva zile după divulgare, confirmând exploatarea activă. Cu un scor CVSS de 9.2, CVE-2026-109618 și CVE-2026-109619 afectează toate versiunile PHP anterioare 8.2.35, 8.3.36, 8.4.27 și 8.5.12. Dar Problema reală nu este patch-ul upstream — este faptul că PHP rulează înglobat în mii de appliance-uri NAS, gateway-uri VPN, panouri de management building, routere industriale și dispozitive OT unde administratorii nu au control direct pe runtime. Un scan VulnCheck pe 2,6 milioane de host-uri PHP internet-facing a revelat că 42% rulează versiuni end-of-life, inclusiv 27% pe PHP 3.x–7.3. Cogent Security a găsit în medie 2.266 asset-uri afectate per companie Fortune 500, din care 122 expuse direct pe internet. Acest articol explică de ce PHP2Shell va rămâne o amenințărare persistentă și ce strategii concrete pot aplica echipele de securitate și operatori de hosting până la patching-ul complet.
Ghid ServerSpan relevant: CVE-2026-12184: Ghid de Patch pentru DoS în PHP-FPM (8.3.32 / 8.4.21 / 8.5.6).
Provocările patching-ului: versiuni EOL, distribuții LTS și appliance-uri third-party
Proiectul PHP a lansat fixurile oficiale, dar majoritatea serverelor rulează distribuții Linux care livrează actualizări prin proprii package managers. Aici intervine complexitatea: Ubuntu 22.04 primește fixul ca update gratuit PHP 8.1; Ubuntu 20.04 necesită abonament Pro pentru PHP 7.4; Debian 11 blochează fixul PHP 7.4 din spatele unui contract Freexian extended-support; AlmaLinux 8 livrează backport pentru PHP 7.2, 7.3 și 8.0 retrase. Red Hat, SUSE, Alpine și Amazon Linux au fiecare propriile granițe de suport.
Numerele de versiune ale backport-urilor pot fi inconsistent cu upstream. Exemplu: AlmaLinux patch-uiește php-8.3.33-1.el10_2.alma.1, deși upstream fixul pentru ramura 8.3 este 8.3.36. Un scanner care citește banner-ul de versiune va flag-a host-ul ca vulnerabil chiar dacă distribuția a aplicat fixul. Pentru a verifica corect pe un server RHEL/CentOS/AlmaLinux:
rpm -q --changelog php | grep -i "CVE-2026-109618\|CVE-2026-109619"
# sau
dnf updateinfo list --cve CVE-2026-109618Pe Debian/Ubuntu:
apt-get changelog php8.1-fpm | grep -i "CVE-2026-109618\|CVE-2026-109619"
apt list --upgradable | grep phpPeste distribuții, există imagini container pre-built, VM-uri și firmware pentru produse enterprise care înglobează runtime-uri proprii — mult mai greu de inspectat cu scanere automate. Echipele de la dedicated-servers.ro recomandă să includeți în inventar și imaginile de bază Docker folosite în CI/CD: docker image inspect --format='{{.Config.Labels}}' <image> pentru a identifica versiunea PHP înglobată.
Reducerea expunerii în așteptarea patch-urilor: WAF, IPS, izolare rețea și dezactivare management HTTP
Până la disponibilitatea patch-urilor vendor (care pot dura săptămâni), organizațiile trebuie să aplice mitigări stratificate. WAF-urile au limite clare: nu inspectează corpul complet al request-urilor multipart/form-data cum face motorul PHP. Un atacant poate padda payload-ul cu junk data la început pentru a împinge codul malicious peste limită de inspecție a WAF-ului. Mai mult, dacă atacatorul descoperă IP-ul direct al backend-ului, ocolește WAF-ul complet.
AWS WAF, Cloudflare și Microsoft Azure au reguli dedicate PHP2Shell, dar trebuie tratate ca defense-in-depth, nu silver bullet. La nivel de rețea, IPS/IDS cu decriptare HTTPS este esențial. Reguli disponibile la momentul scrierii:
- Palo Alto: Threat ID 543004
- Check Point: IPS protection CPAI-2026-15172
- Cisco Talos: Snort rules 67359, 67360
- Suricata: rules 3000650–3000652
Pentru sisteme care nu pot fi patțate (end-of-life, vendor dispărut), trei acțiuni concrete:
- Mută interfața web management din segmente insecurizate — izolează în VLAN dedicat cu acces doar din jump host-uri administrare.
- Aplică firewall rules restrictive — permite trafic HTTP/HTTPS management doar din IP-uri administrative cunoscute.
- Dezactivează serverul HTTP embedded dacă funcționalitatea poate fi achievată prin SSH/CLI. Belden și Delta Controls recomandă explicit această abordare pentru routere industriale și controlere HVAC.
Exemplu regula iptables pentru a restricționa accesul la portul 443 al unui appliance la o singură subnetă admin:
iptables -A INPUT -p tcp --dport 443 -s 10.10.20.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROPPentru medii cloud, serverspan.ro implementează Security Groups cu deny-by-default și allow-list explicit pentru management interfaces, combinat cu VPC Flow Logs către CloudWatch pentru audit.
Cum să detectați dacă ați fost deja compromiși: analize log-uri și indicatori de compromis (IOC)
Patching-ul închide ușa, dar nu vă spune cine e deja înăuntru. Steve Povolny (Exabeam) avertizează: „PHP2Shell a trecut de la scanning noise la RCE confirmat pe honeypot în zile. Acea fereastră este unde se produce daunele reale.” Investigarea log-urilor existente este critică. Căutați următoarele pattern-uri în access/error logs (Apache/Nginx), PHP-FPM logs, WAF/reverse-proxy logs, CDN logs, EDR telemetry, DNS/egress logs, auth logs, FIM alerts, cloud audit logs:
Pentru mai multe detalii despre această parte a subiectului, vezi Cum se configurează un Web Application Firewall (WAF) puternic cu ModSecurity și NGINX pe VPS-ul tău.
Indicatori în HTTP request-uri:
- Prezența
PHP_SESSION_UPLOAD_PROGRESSîn câmpuri form-data - Cookie
PHPSESSIDcu lungime anormală sau corupție multipart/form-datatrimis către endpoint-uri care nu acceptă upload- Corpuri multipart unusuale mari, deeply nested field names
- POST-uri repetate de la același sursă
- Spike-uri în HTTP 500 errors
Indicatori la nivel de proces și sistem:
- Processe worker PHP-FPM/Apache/httpd care spawn-uiesc
sh,bash,curl,wget,base64,python,perl - Child processes neașteptate sub user-ul serviciului web (www-data, apache, nginx)
- Reverse shells sau conexiuni outbound din worker processes
- Fișiere
.phpnoi sau modificate în web root, directoare upload, plugin-uri - Fișiere de sesiune anormal mari
- Restart-uri neexplicate ale worker-ilor sau segmentation faults
Comandă pratică pentru căutare rapidă în log-uri Apache/Nginx (ultimele 48h):
# Cautare PHP_SESSION_UPLOAD_PROGRESS în access logs
grep -r "PHP_SESSION_UPLOAD_PROGRESS" /var/log/apache2/ /var/log/nginx/ --include="*.log" -i
# Request-uri multipart mari (>100KB) către endpoint-uri non-upload
awk '$10 > 102400 && $7 ~ /multipart/' /var/log/nginx/access.log
# Processe suspecte spawn-uite de PHP-FPM (necesită auditd sau sysmon configurat)
ausearch -m EXECVE -c php-fpm --start recentPe sisteme cu systemd-journald, filtrare după unitatea PHP-FPM:
journalctl -u php8.2-fpm --since "48 hours ago" -o cat | grep -E "(sh|bash|curl|wget|base64|python|perl)"Verificare integritate fișiere web root cu aide sau tripwire:
aide --check | grep -E "^\s+(added|changed|removed).*\.php"Strategii de visibilitate și inventariere: SBOM, package managers, network scanners, container images
Cea mai mare bătălie nu e vulnerabilitatea — e vizibilitatea. Organizatiile trebuie să combine multiple surse de inventariere pentru a descoperi toate instalările PHP:
- Host-based package managers — interogare directă pe fiecare server (comenzile de mai sus).
- Network vulnerability scanners — Censys a numărat 34,4 milioane servicii vulnerabile la 23 octombrie; folosiți scanere autentificate pentru a citi banner-e și versiuni reale.
- Software Bill of Materials (SBOM) — cereți SBOM la vendorii de appliance-uri și software; parseazăți pentru componente PHP (
syft packages <image> | grep php). - Container image scanning —
trivy image --severity HIGH,CRITICAL <image>saugrype <image>pe toate imaginile în registry. - Agent-based EDR/XDR — corelare evenimente de execuție anormală cu inventarul de asset-uri.
- Passive DNS și certificate transparency logs — identifică subdomenii/exponeri necunoscute care pot servi PHP.
Exemplu scanare Trivy pentru imagini locale și remote:
trivy image --vuln-type os,library --severity CRITICAL,HIGH php:8.1-fpm
trivy fs --security-checks vuln,config /var/www/htmlPentru appliance-uri fără acces shell, folosiți banner grabbing și HTTP header analysis:
curl -I -k https://appliance-ip/ | grep -i "server\|x-powered-by"
nmap -p 80,443,8080,8443 --script http-headers,http-php-version <target>Documenteazăți fiecare asset descoperit într-un registru centralizat (CMDB) cu câmpuri: hostname, IP, produs/vendor, versiune PHP, metodă patching (upstream/distro/vendor/none), status mitigare, owner, data următoarei verificări. Acest registru devine baza pentru response-ul la viitoare vulnerabilități PHP — și vor fi altele.
–
Pași practici imediată (checklist acțiune)
- Rulează inventar complet PHP pe toate serverele gestionate (package manager + container images + appliance-uri cunoscute).
- Aplică patch-uri upstream/distro unde e posibil; documentează backport-urile aplicate vs. versiuni upstream.
- Activează WAF rules PHP2Shell pe edge (Cloudflare/AWS/Azure/local WAF) și configurează IPS cu decriptare HTTPS.
- Isolează appliance-uri nepatchabile în VLAN dedicat, restricționează management la IP-uri admin, dezactivează HTTP server dacă e posibil.
- Analizează log-urile ultimele 72h pentru IOC-urile listate mai sus; escalează orice găsire suspectă la incident response.
- Cere SBOM la vendorii critici și adaugă PHP în lista de monitorizare continuă a supply chain-ului software.
- Programează re-scanăre săptămânale până la confirmarea patching-ului tuturor asset-urilor identificate.
–
PHP2Shell nu este o vulnerabilitate care dispare după un ciclu de patching. Este un simptom al unui problemă structurală: runtime-uri critice înglobate în produse opace, cu cicluri de patching controlate de terți, déployate pe infrastructură care trăiește ani de zile fără update-uri. Organizațiile care investesc astăzi în vizibilitate completă (SBOM, scanere agent-based, network telemetry) și în capacitatea de a mitiga rapid fără patch (network segmentation, WAF/IPS tuned, HTTP management disable) vor fi cele care vor dormi liniste la următoarea vulnerabilitate „Log4Shell-scale” — indiferent de numele pe care o va purta.
