Pe scurt: Vulnerabilitățile din PHP sunt raportate confidențial, de preferință prin formularul privat Advisory din depozitul GitHub php/php-src, alternativ la security@php.net. Dezvoltatorii PHP încadrează constatarea ca ridicată, medie sau scăzută; erorile grave sunt corectate într-un depozit de securitate separat și publicate abia odată cu lansarea, împreună cu un GitHub Security Advisory și, de regulă, un număr CVE. La PHP2Shell, acest proces s-a desfășurat în ritm accelerat: anunț prealabil la 20.10.2026, patch-uri la 21.10.2026, notă suplimentară la 23.10.2026.
Cine se ocupă de securitate la PHP?
PHP este un proiect open source. Politica de securitate din wiki îl descrie ca un proiect de voluntari, fără buget pentru recompense. Pentru fiecare versiune există release manageri, care răspund de publicări. La acestea se adaugă PHP Foundation, care, potrivit propriei prezentări, finanțează o echipă de dezvoltatori cu normă parțială și întreagă, care lucrează la întreținerea, securitatea și noile funcții ale PHP.
Pentru companii, aceasta înseamnă: nu există un producător cu contract, linie de asistență sau timpi de reacție garantați. Cine are nevoie de angajamente obligatorii le primește de la distribuția sa Linux, de la furnizorul de hosting sau de la un furnizor de suport pe termen lung, nu de la proiectul PHP însuși. Ar trebui să cunoașteți acest lanț de aprovizionare.
Cum este raportată o vulnerabilitate
Calea este descrisă în politica de securitate de pe GitHub:
- Raportarea: prin formularul privat pentru Security Advisories din depozitul
php/php-src. Cine nu îl poate folosi sau vrea să discute un subiect care nu este un raport de eroare scrie la security@php.net. - Descrierea pe scurt: se dorește un exemplu scurt care arată eroarea, nu un raport lung despre posibile efecte. Astfel echipa poate analiza mai repede.
- Confidențialitatea: raportul rămâne privat până la publicare.
- Menționarea: cei care raportează sunt menționați ca și contributori, după sistemul de credit al MITRE.
Pagina wiki mai veche menționează în plus trackerul clasic de erori, cu tipul „Security”. Astăzi este decisivă calea prin GitHub.
Ce încadrează proiectul PHP drept vulnerabilitate de securitate
Nu orice cădere este o vulnerabilitate de securitate. Wiki-ul menționează patru criterii: o eroare permite acțiuni neautorizate, depășește granițe de securitate, deschide accesul la date străine sau afectează grav disponibilitatea ori performanța. Încadrarea se face pe trei niveluri:
| Nivel | Semnificație potrivit politicii | Număr CVE |
|---|---|---|
| Ridicat | terții pot compromite majoritatea instalărilor, pot executa cod sau pot citi fișiere | de regulă da |
| Mediu | efect similar, dar doar în condiții mai rare, de exemplu o extensie sau o configurație rară | de obicei da |
| Scăzut | teoretic posibil, practic foarte greu de exploatat | de obicei nu |
La fel de instructivă este lista a ceea ce nu este în mod explicit o vulnerabilitate de securitate: codul rău intenționat executat în mod deliberat, ocolirile open_basedir și disable_functions, datele rău intenționate transmise lui unserialize(), folosirea FFI și o oprire obișnuită din cauza memoriei, în care memory_limit intervine și se încheie doar cererea curentă. Pentru operatori, aceasta înseamnă: disable_functions este o întărire rezonabilă, dar nu un zid de protecție.
De la remediere la publicare
Corecturile pentru vulnerabilitățile ridicate și medii sunt integrate, potrivit wiki-ului, într-un depozit de securitate separat, înainte de crearea lansării. Erorile încadrate ca scăzute urmează calea remedierilor obișnuite. Vulnerabilitatea este publicată după principiul dezvăluirii responsabile: mai întâi corecția, apoi detaliile. Lansările apar, potrivit wiki-ului, de obicei joia, adesea în cadrul publicărilor lunare regulate.
Odată cu lansarea apare un GitHub Security Advisory, cu identificator propriu (GHSA) și grad de severitate. În depozit au apărut, de exemplu, la 24.09.2026 mai multe advisory-uri despre stream wrappers, FastCGI și filtre, cu grade de severitate de la scăzut la ridicat. Pachetele sursă de pe php.net sunt oferite cu sume de control SHA-256 și semnături GPG ale release managerilor; tag-urile Git sunt semnate. Ce ramuri de versiuni primesc încă remedieri de securitate arată pagina despre versiunile PHP și ciclul de lansare.
PHP2Shell, un exemplu pentru situația de urgență
PHP2Shell arată cum decurge procesul sub presiune:
- 20.10.2026: php.net anunță o lansare critică de securitate pentru 21.10.2026, ora 14:00 UTC, și își rezervă dreptul să publice mai devreme dacă detaliile devin publice sau apar atacuri. Potrivit mai multor rapoarte, detaliile deveniseră într-adevăr cunoscute înainte de expirarea termenului de blocare; contextul îl luminează De ce a devenit cunoscută vulnerabilitatea PHP înainte de patch.
- 21.10.2026: apar PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35, împreună cu advisory-urile GHSA-w8hw-w9fx-j79w (CVE-2026-109618) și GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), ambele încadrate ca critice. Potrivit php.net, distribuțiile Linux și furnizorii de suport pe termen lung primiseră remedierile în prealabil. Pentru 7.4, 8.0 și 8.1 există backport-uri minimale.
- 23.10.2026: o notă informativă despre CVE-2026-115560 recomandă
session.upload_progress.enabled=0; advisory-ul complet urmează odată cu următoarea lansare.
Ce deduc operatorii din aceasta
- Abonarea la surse: php.net, advisory-urile GitHub ale
php/php-srcși anunțurile de securitate ale distribuției dumneavoastră. - Cunoașterea lanțului de aprovizionare: cine vă livrează pachetul PHP și cât de repede ajung acolo backport-urile?
- Planificarea ferestrei de timp: lansările critice pot veni în afara ritmului obișnuit; o fereastră de patch trebuie să fie posibilă pe termen scurt.
- Planificarea repornirii: o actualizare are efect abia când toate procesele PHP au fost repornite.
- Asigurarea dovezii: documentați versiunea, starea pachetului și momentul.
Cum ajută PHP SOS concret?
Prin serviciul PHP-Patch preluăm partea care vă revine:
- Urmărirea anunțurilor: Urmărim php.net, advisory-urile și anunțurile distribuțiilor și evaluăm dacă sistemele dumneavoastră sunt afectate.
- Aplicarea patch-ului: Actualizare din sursa potrivită, repornirea tuturor proceselor, controlul versiunii care rulează.
- Securizarea tranziției: Acolo unde actualizarea întârzie, aplicăm măsurile oficiale de tranziție.
- Documentarea: Primiți o dovadă cu versiuni, stări ale pachetelor și momente.
Întrebări frecvente
Cum se raportează o vulnerabilitate în PHP?
De preferință prin formularul privat pentru Security Advisories din depozitul GitHub php/php-src. Cine nu îl poate folosi scrie la security@php.net. Raportul rămâne confidențial până la publicare.
Plătește proiectul PHP o recompensă pentru vulnerabilitățile găsite?
Nu. Potrivit politicii de securitate, PHP este un proiect de voluntari, fără bani pentru bug bounty. Cei care raportează sunt însă menționați ca și contributori.
Este ocolirea disable_functions o vulnerabilitate de securitate?
Potrivit politicii proiectului PHP, nu. Ocolirile open_basedir și disable_functions nu sunt considerate o problemă de securitate a PHP. Setările reprezintă o întărire, dar nu o graniță de securitate sigură.
Unde aflu despre noile vulnerabilități PHP?
Pe pagina principală php.net, cu anunțurile de lansare, și în Security Advisories din depozitul GitHub php/php-src. Cine primește PHP din distribuție urmărește suplimentar anunțurile de securitate ale acesteia.
De ce a fost publicat PHP2Shell într-o zi de miercuri?
Potrivit wiki-ului, lansările apar de obicei joia. Pentru PHP2Shell, php.net a anunțat la 20.10.2026 o lansare de securitate pentru miercuri, 21.10.2026, ora 14:00 UTC, și și-a rezervat dreptul să publice mai devreme dacă detaliile deveneau publice.