Pe scurt: După PHP2Shell sunt probabile alte anunțuri despre PHP, deoarece deja la două zile după patch a venit o a treia indicație, un advisory complet este încă în așteptare, iar distribuțiile își livrează pachetele eșalonat. Cine stabilește acum un proces fix pentru observare, evaluare, actualizare și repornire reacționează la următoarea vulnerabilitate PHP nouă în ore, nu în zile.
Patchul nu a fost sfârșitul poveștii
Pe 21 octombrie 2026, proiectul PHP a închis cele două vulnerabilități critice CVE-2026-109618 și CVE-2026-109619 cu versiunile 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Mulți responsabili au bifat apoi subiectul. Două zile mai târziu, pe 23 octombrie, a urmat însă o altă indicație de la php.net despre CVE-2026-115560.
Această a treia indicație privește doar o configurație neobișnuită a sesiunilor. Ea arată însă un tipar cunoscut din cazurile mari de securitate: când o componentă ajunge brusc în lumina reflectoarelor, mulți specialiști privesc simultan mai atent. Dacă din aceasta apar alte vulnerabilități, nimeni nu știe astăzi. Probabil este însă că fluxul de știri nu se oprește.
Pentru dumneavoastră, ca operator, înseamnă: planificați anunțurile ulterioare, în loc să fiți surprins de fiecare. Desfășurarea de până acum a evenimentelor o rezumă cronologia noastră PHP2Shell.
De ce sunt probabile alte anunțuri
Evaluarea următoare se bazează pe fapte cunoscute public. Nu este o prognoză a unor vulnerabilități concrete.
- Un advisory este încă în așteptare. php.net tratează CVE-2026-115560 în ciclul obișnuit de lansări și a anunțat că va publica advisory-ul complet odată cu următoarea versiune. Până atunci,
session.upload_progress.enabled=0este considerat remediu. - Detaliile au fost publice devreme. Potrivit mai multor relatări, detaliile au devenit cunoscute înainte de expirarea embargoului. Potrivit relatărilor, watchTowr a reprodus CVE-2026-109618, după propriile declarații. Astfel de lucrări duc adesea la întrebări ulterioare despre porțiuni de cod învecinate.
- Distribuțiile livrează eșalonat. Ubuntu a aprovizionat pe 21 octombrie, cu USN-8948-1, versiunile actuale și a livrat ulterior, cu USN-8948-2, corecții pentru 14.04 până la 20.04 prin Ubuntu Pro. Red Hat a scris în buletinul său că unele actualizări sunt disponibile, iar altele sunt în lucru.
- Versiunea de dezvoltare este afectată. Potrivit php.net, și PHP 8.6.0 RC4 conține corecțiile. Cine testează versiuni preliminare trebuie să actualizeze și aceste medii.
- Versiunile vechi rămân deschise. Pentru PHP 8.1 și mai vechi există doar backporturi minime de cod sursă. Fiecare furnizor care livrează astfel de versiuni își raportează starea independent și la momente proprii.
Cum ajunge la dumneavoastră o nouă vulnerabilitate PHP
Anunțurile vin pe căi diferite și cu fiabilitate diferită. Ordinea este aproape întotdeauna aceeași: mai întâi proiectul PHP, apoi distribuțiile și furnizorii de hosting, după aceea autoritățile și presa.
| Sursă | Ce aflați acolo | Cât de fiabilă |
|---|---|---|
| php.net | Ramuri afectate, versiuni corectate, măsuri provizorii | Sursă primară |
| Ubuntu, Debian, Red Hat | Nivelul pachetelor pentru fiecare versiune, momentul livrării | Sursă primară pentru sistemul dumneavoastră |
| Furnizori de hosting și de panouri | Starea propriilor build-uri PHP | Obligatoriu doar dacă este în scris |
| BSI, CERT-Bund | Evaluarea situației, nivel de alertă, recomandări | Încadrare oficială |
| Presa de specialitate și firmele de securitate | Observații despre atacuri, cifre, contexte | Utilă, de marcat ca relatare |
Important este diferența dintre „există un patch” și „sistemul meu are patchul”. Prima afirmație se află pe php.net. A doua trebuie să o dovediți dumneavoastră pentru fiecare server.
Abonați-vă la anunțurile de la php.net și de la distribuția dumneavoastră prin RSS sau listă de e-mail și redirecționați-le către o căsuță comună sau un canal pe care îl citește mai mult de o persoană. Concediul și boala sunt cele mai frecvente motive pentru actualizări întârziate.
Ce ar trebui să pregătiți înainte de următorul anunț
Experiența din PHP2Shell arată unde se pierde timp: la căutarea serverelor, la clarificarea responsabilităților și la repornirea uitată. Toate acestea pot fi rezolvate dinainte.
- Inventar: O listă a tuturor serverelor și site-urilor cu ramura PHP, modul de operare (PHP-FPM, mod_php, LiteSpeed) și sursa pachetelor. Fără această listă, fiecare anunț începe cu căutarea. Cum reușiți descrie articolul Inventarul tuturor site-urilor și serverelor.
- Responsabilitate: Pentru fiecare sistem este stabilit cine actualizează, cine repornește și cine aprobă. La furnizorii de hosting și agenții, aceasta aparține contractului.
- Grilă de evaluare: Trei întrebări sunt suficiente pentru prima încadrare. Este ramura noastră afectată? Folosim funcția sau modul de operare afectat? Există un patch sau doar măsuri provizorii?
- Cale de testare: Un mediu de staging în care o actualizare PHP poate fi verificată în scurt timp.
- Dovadă: Un format fix în care sunt consemnate nivelul pachetelor, potrivirile din changelog și ora repornirii.
Cum funcționează un astfel de proces ca rutină, nu ca intervenție de pompieri, se află la Gestionarea patchurilor ca proces. Contextul privind modul în care proiectul PHP tratează vulnerabilitățile îl oferă pagina Cum tratează proiectul PHP vulnerabilitățile de securitate.
Propria configurație ca sistem de avertizare timpurie
O parte dintre anunțurile ulterioare privește doar anumite setări. CVE-2026-115560 este un exemplu: php.net menționează ca precondiție ca o aplicație să schimbe serializatorul de sesiuni în timpul execuției, cât timp upload progress este activ. Aplicațiile care nu fac niciodată acest lucru nu sunt afectate, potrivit php.net.
Cine își cunoaște configurația efectivă poate încadra mai repede astfel de anunțuri. Consemnați de aceea, pentru fiecare ramură, ce valori sunt setate la nivel de server și ce aplicații au voie să le suprascrie. Ajută deja o comparare simplă a setărilor active:
# Valorile efective ale liniei de comandă (configurația web poate diferi)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Valori setate în pool-urile FPM (calea diferă în funcție de distribuție)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Linia de comandă nu arată neapărat ce se aplică în contextul web. Claritate aduc configurația pool-ului sau a VirtualHost-ului și, pe scurt și protejat, o pagină phpinfo.
Un alt avantaj: cine știe ce valori provizorii mai sunt setate din săptămâna PHP2Shell le poate verifica în mod conștient după următoarea versiune obișnuită. Unele setări, de exemplu upload progress dezactivat, pot rămâne utile pe termen lung. Altele, cum ar fi limitele foarte strânse pentru upload, ar trebui readaptate la nevoia reală, după consultarea departamentelor de specialitate.
Cum ajută PHP SOS concret?
- Urmărim anunțurile de la php.net, distribuții și BSI și evaluăm indicațiile noi pentru sistemele dumneavoastră concrete.
- Întocmim împreună cu dumneavoastră inventarul tuturor instalărilor PHP și stabilim responsabilitățile pentru fiecare server.
- În cadrul unui contract de mentenanță de securitate, instalăm actualizări, repornim toate procesele și documentăm starea.
- La anunțuri fără patch, setăm măsuri provizorii care nu pot fi suprascrise și le verificăm ulterior.
Întrebări frecvente
Există după PHP2Shell deja o nouă vulnerabilitate PHP?
Pe 23 octombrie 2026, php.net a publicat o indicație despre CVE-2026-115560. Execuția de cod este, potrivit ei, posibilă doar la o configurație neobișnuită a sesiunilor. Un advisory complet urmează să apară odată cu următoarea versiune obișnuită.
Trebuie să acționez imediat după fiecare anunț nou?
Nu orice anunț cere aceeași urgență. Decisive sunt gravitatea, dacă configurația dumneavoastră este afectată și dacă un patch este disponibil. Un proces stabilit ajută să evaluați acest lucru în minute, nu în zile.
Unde aflu primul despre noi vulnerabilități PHP?
Surse primare sunt anunțurile de pe php.net și indicațiile de securitate ale distribuției dumneavoastră, de exemplu Ubuntu Security Notices, Debian Security Tracker sau Red Hat. BSI informează prin avertismente. Relatările din presă sunt utile, dar adesea mai târzii și mai puțin exacte.
De ce raportează distribuțiile uneori cu zile mai târziu decât php.net?
Distribuțiile trebuie să preia corecția în propriile pachete, să le construiască și să le testeze. Pentru versiunile mai vechi, aceasta poate dura mai mult sau poate avea loc doar prin oferte suplimentare. De aceea merită să urmăriți separat ambele surse.