CVE-2026-12184: Ghid de Patch pentru DoS în PHP-FPM (8.3.32 / 8.4.21 / 8.5.6)

Două buletine de securitate PHP publicate pe 2 iulie 2026 remediază o vulnerabilitate denial-of-service cu severitate ridicată și un bug de corupere a memoriei cu severitate moderată. CVE-2026-12184 poate prăbuși întregul pool PHP-FPM atunci când o conexiune HTTPS inițiată din aplicația ta PHP nu trece validarea TLS. Nu este nevoie de un exploit scris special pentru a declanșa problema. CVE-2026-14355 corupe heap-ul managerului de memorie Zend atunci când aplicația criptează date folosind un cifru AES-WRAP-PAD, deoarece PHP dimensionează greșit bufferul de ieșire și nu ia în calcul padding-ul definit în RFC 5649. Niciunul dintre buletine nu menționează exploatare confirmată în producție, deci vorbim despre o situație de tip „aplică patch-ul acum”, nu despre un 0-day exploatat activ. Totuși, condiția care declanșează CVE-2026-12184 este suficient de comună în trafic real încât amânarea actualizării înseamnă risc concret.

Ce se întâmplă de fapt în CVE-2026-12184

Wrapperul HTTP din PHP deschide conexiuni HTTPS de fiecare dată când codul tău apelează file_get_contents(), fopen() sau stream_context_create() către un URL https://. Același mecanism poate fi folosit și de biblioteci client HTTP construite peste stream-urile PHP. Intern, funcția php_stream_url_wrap_http_ex apelează php_stream_xport_crypto_setup și php_stream_xport_crypto_enable pentru a negocia conexiunea TLS cu serverul remote.

Când negocierea TLS eșuează, de exemplu pentru că serverul remote prezintă un certificat expirat sau un certificat emis pentru alt hostname, PHP închide stream-ul de dedesubt și îl resetează la NULL. Problema apare imediat după, în codul care curăță peer name-ul: acea rutină nu verifică dacă stream-ul mai există și încearcă să reseteze peer name-ul pe un stream deja distrus.

Pe scurt, CVE-2026-12184 poate prăbuși PHP-FPM atunci când o cerere HTTPS făcută de aplicația ta eșuează la validarea TLS. Atacatorul nu trebuie să trimită direct o cerere malițioasă către PHP ca să declanșeze comportamentul.

De ce poate fi declanșată de la distanță fără exploit personalizat

Echipa de securitate PHP notează că problema a fost demonstrată fără cod special construit, folosind doar un server remote la care handshake-ul TLS eșuează în mod normal. Orice endpoint HTTPS apelat de aplicația ta poate deveni un declanșator în momentul în care certificatul expiră, este configurat greșit sau este înlocuit cu unul care nu corespunde hostname-ului la care se conectează aplicația. Cum această cale de cod închide stream-ul, iar rutina de curățare ajunge apoi să dereferențieze acel stream, prăbușirea poate doborî workerul PHP-FPM și, conform buletinului, întregul pool, nu doar cererea individuală care a eșuat.

Vulnerabilitatea are scor CVSS v4 8.2, adică High, cu vector de atac prin rețea, fără privilegii necesare și fără interacțiune din partea utilizatorului. Impactul este strict pe disponibilitate. Buletinul nu descrie pierderi de confidențialitate sau integritate.

Celălalt bug: CVE-2026-14355 în extensia OpenSSL

CVE-2026-14355 apare într-o zonă mult mai îngustă: familia de cifruri AES key-wrap-with-padding, adică algoritmi ale căror nume se termină în -wrap-pad, cum ar fi aes-256-wrap-pad, disponibili prin openssl_encrypt(). PHP alocă bufferul de ieșire pentru această operație doar pe baza lungimii textului în clar. Însă key wrap cu padding, conform RFC 5649, rotunjește textul în clar la următorul multiplu de 8 octeți și adaugă un antet de autentificare de 8 octeți. Lungimea reală a textului criptat este roundup(len, 8) + 8, nu o funcție simplă a lungimii de intrare. Bufferul alocat de PHP este prea mic pentru datele scrise efectiv de EVP_EncryptUpdate și EVP_EncryptFinal din OpenSSL.

OpenSSL scrie întregul rezultat al operației de wrap dincolo de limita bufferului subdimensionat, corupând metadatele heap-ului Zend din vecinătate. Detaliul important pentru depanare este acesta: coruperea nu prăbușește procesul chiar în momentul în care se produce. Eroarea apare mai târziu, sub forma unui abort de tip zend_mm_heap corrupted, atunci când allocatorul verifică metadate interne deja deteriorate de o cerere anterioară. Dacă începi investigația exact din punctul indicat de log-ul de crash, există șanse mari să cauți în cererea greșită.

Această vulnerabilitate are scor CVSS v3.1 4.8, adică Moderate, cu o complexitate ridicată a atacului. Motivul este simplu: un atacator are nevoie ca aplicația ta să folosească efectiv un cifru AES-WRAP-PAD, iar majoritatea aplicațiilor PHP nu ating direct această zonă. Situația este mai probabilă în biblioteci care gestionează criptare CMS sau PKCS7, în unele implementări JWE (JSON Web Encryption) și în stack-uri XML/SAML care folosesc intern AES key wrap.

Versiuni afectate și versiuni remediate

Ramură PHP	CVE-2026-12184 afectat	CVE-2026-12184 remediat	CVE-2026-14355 afectat	CVE-2026-14355 remediat
8.2.x	Nu apare ca afectat	n/a	< 8.2.32	8.2.32
8.3.x	< 8.3.32	8.3.32	< 8.3.32	8.3.32
8.4.x	< 8.4.21	8.4.21	< 8.4.23	8.4.23
8.5.x	< 8.5.6	8.5.6	< 8.5.8	8.5.8

Observă că pentru ramura PHP 8.3.x același build, 8.3.32, închide ambele probleme. Pentru 8.4.x și 8.5.x, însă, versiunile remediate diferă de la un CVE la altul. Verifică să fii pe cea mai nouă versiune necesară pentru ramura ta, nu doar pe prima versiune care remediază una dintre vulnerabilități.

Cum verifici dacă mediul tău este expus

Începe cu versiunea instalată:

php -v

Compară rezultatul cu tabelul de mai sus, în funcție de ramura PHP pe care o folosești. Dacă versiunea instalată este sub ambele praguri de remediere, ești expus la ambele probleme. Dacă este sub un singur prag, ești expus doar la vulnerabilitatea corespunzătoare.

Dacă PHP-FPM se prăbușea deja înainte să verifici versiunea, separă acest mod de eșec de un simplu OOM kill. O prăbușire cauzată de CVE-2026-12184 ar trebui să apară în log-ul masterului PHP-FPM ca un worker terminat cu semnalul 11, adică SIGSEGV, corelat cu un apel HTTPS inițiat de aplicație. Un OOM kill apare, de regulă, ca semnal 9, adică SIGKILL, trimis de kernel, nu ca o eroare internă PHP:

journalctl -u php8.3-fpm --since "24 hours ago" | grep -i "sig\|core dump"
grep -i "signal 11\|SIGSEGV" /var/log/php8.3-fpm.log 2>/dev/null

Intrările repetate de SIGSEGV apărute în același interval cu procesări de webhook-uri, apeluri API remote sau preluări programate de feed-uri indică spre CVE-2026-12184. Un tipar de SIGKILL indică mai degrabă limite de memorie și trebuie investigat separat ca problemă de tuning.

Pentru bug-ul din OpenSSL, verifică dacă baza ta de cod folosește vreun cifru wrap-pad. Expunerea există doar dacă acest tip de algoritm este apelat efectiv:

grep -rniE "wrap-pad|WRAP_PAD" /var/www --include=*.php

Dacă nu primești rezultate, CVE-2026-14355 probabil nu este un risc practic în codul propriu al aplicației. Totuși, o bibliotecă terță sau o dependență Composer ar putea apela indirect acel cifru, deci merită verificat și directorul vendor/ dacă prima căutare nu găsește nimic.

Dacă o prăbușire PHP-FPM apare pentru vizitatori ca pagină goală sau eroare de gateway, nu ca eroare PHP clară, ghidul nostru despre depanarea unui site căzut, DNS sau hosting te ajută să urmărești problema până la stratul corect, chiar dacă nu tratează direct acest CVE.

Aplică patch-ul acum: comenzi de actualizare

Pe sisteme Debian sau Ubuntu care folosesc PPA-ul Ondřej Surý:

apt update
apt list --upgradable | grep -i php
apt install --only-upgrade php8.3-fpm php8.3-common php8.3-opcache
php-fpm8.3 -t
systemctl reload php8.3-fpm

Rulează php-fpm8.3 -t înainte de reload. Comanda validează configurația pool-ului fără să atingă workerii activi. O eroare prinsă aici se repară imediat; o eroare prinsă după reload îți poate lăsa pool-ul indisponibil. Folosește reload în loc de restart acolo unde versiunea ta suportă acest lucru: reload lasă cererile în curs să se termine pe workerii vechi și pornește workeri noi cu binarul actualizat, în timp ce restart întrerupe conexiunile imediat.

Pe sisteme din familia RHEL care folosesc repository-ul Remi:

dnf update --enablerepo=remi-php84 php php-fpm php-openssl
php-fpm84 -t
systemctl restart php84-php-fpm

Confirmă că patch-ul a ajuns pe procesul care deservește efectiv traficul, nu doar pe binarul CLI. Pe majoritatea distribuțiilor, PHP CLI și PHP-FPM sunt pachete separate:

php -v
systemctl status php8.3-fpm --no-pager

Un rezultat bun arată versiunea remediată din tabelul de mai sus și un status active (running), fără restarturi neașteptate în log în afara celui declanșat de actualizare. Dacă pachetul remediat nu a ajuns încă în repository-ul distribuției tale, aceasta este o problemă reală. Urmărește repository-ul și aplică actualizarea imediat ce devine disponibilă, nu la următorul ciclu comod de mentenanță.

Dacă administrezi versiunile PHP printr-un panou de control, nu ocoli mecanismul panoului. MultiPHP Manager din cPanel și PHP Selector din DirectAdmin controlează ce handler PHP-FPM deservește fiecare domeniu. O actualizare brută prin apt sau dnf, făcută în afara acestei mapări, poate lăsa unele domenii pe un handler nepotrivit sau neactualizat.

Este, de fapt, un 0-day?

Un 0-day înseamnă că atacatorii exploatează o vulnerabilitate înainte să existe un patch disponibil. Nu aceasta este situația aici. Echipa de securitate PHP a publicat versiuni remediate odată cu buletinele care au dezvăluit cele două bug-uri. Pentru administratorii care actualizează prompt, nu există o fereastră inevitabilă fără patch. Niciunul dintre buletine nu menționează dovezi de exploatare înainte de publicarea remedierilor.

Ceea ce face CVE-2026-12184 urgentă nu este statutul de 0-day, ci pragul foarte jos de declanșare. Orice eșec TLS pe o conexiune inițiată de aplicația ta PHP, inclusiv un simplu certificat expirat la un furnizor integrat, poate duce acum la căderea întregului pool PHP-FPM. Nu este nevoie ca atacatorul să-ți compromită infrastructura. Este suficient să poată influența un endpoint TLS pe care aplicația ta îl apelează sau, mai banal, ca acel endpoint să fie configurat prost.

Regulă de decizie: patch imediat sau mentenanță programată

Aplică patch-ul pentru CVE-2026-12184 fără amânare dacă aplicația ta face apeluri HTTPS către endpoint-uri pe care nu le controlezi complet: webhook-uri terțe, sincronizări API cu parteneri, feed-uri sau imagini preluate de la distanță, callback-uri de la procesatori de plăți. Un singur certificat expirat la un furnizor poate deveni un declanșator pentru oprirea completă a pool-ului PHP-FPM, nu doar pentru eșecul unei cereri izolate.

CVE-2026-14355 poate, în general, să aștepte următoarea fereastră de mentenanță dacă nu găsești utilizări de cifruri wrap-pad în cod. Exploatarea presupune ca stack-ul tău să aleagă activ acel algoritm, lucru pe care majoritatea aplicațiilor PHP nu îl fac niciodată. Totuși, aplică patch-ul în aceeași rundă de actualizări. Pe ramura 8.3.x aceeași versiune remediază ambele bug-uri, iar pe 8.4.x și 8.5.x trebuie doar să te asiguri că ajungi la versiunea cea mai nouă necesară pentru ramura ta.

Dacă rulezi o aplicație găzduită de tine pe un VPS și vrei o privire mai amplă asupra problemelor de tuning PHP-FPM care nu țin direct de aceste două CVE-uri, vezi ghidul nostru despre repararea PHP-FPM, blocărilor Redis și greșelilor de reverse proxy pe o instanță Nextcloud pe VPS.

Când are sens să ceri ajutor administrat

Aplicarea în siguranță a unui patch PHP-FPM înseamnă să testezi configurația înainte de reload, să urmărești logurile în timpul actualizării și să confirmi că versiunea remediată rulează chiar pe procesul care servește traficul. Dacă preferi ca aceste lucruri să fie monitorizate și aplicate de o echipă de hosting, nu făcute pe fugă când ceva deja pică, serviciul de administrare Linux ServerSpan acoperă actualizări de versiuni PHP, configurarea pool-urilor PHP-FPM și revizuirea logurilor ca parte a administrării continue a serverului. Serverele livrate prin hostingul VPS ServerSpan vin cu acces root complet, deci poți aplica singur comenzile de mai sus imediat ce pachetul remediat ajunge în repository-ul distribuției tale.

Nu este primul caz din acest an în care un serviciu activat implicit sau o problemă de runtime se transformă într-un avertisment de patch chiar în ziua publicării. Vezi și analiza noastră despre lanțul CUPS RCE până la root, un alt exemplu în care o setare implicită trecută cu vederea pe un VPS Linux a devenit o cale completă de compromitere.