Pe scurt: După PHP2Shell, versiunea PHP afișată dovedește puțin de una singură, deoarece furnizorii de hosting aplică adesea corecturile ca backport. Cereți de aceea o confirmare scrisă de la furnizorul de hosting: starea pachetului pentru fiecare ramură PHP, momentul instalării și repornirea tuturor proceselor PHP. Un model de copiat găsiți mai jos.
De ce contează acum o confirmare scrisă
La 21.10.2026 proiectul PHP a publicat patchurile pentru două vulnerabilități critice, cunoscute sub numele PHP2Shell. Ambele permit executarea de cod malițios de la distanță, fără autentificare. BSI (Oficiul Federal German pentru Securitatea Informațiilor) a emis nivelul de avertizare 3 / portocaliu și recomandă actualizarea imediată.
Cine își găzduiește site-ul la un furnizor de hosting nu poate adesea aplica singur actualizarea. În același timp, ca operator, dumneavoastră purtați responsabilitatea pentru datele clienților dumneavoastră. O confirmare scrisă și concretă din partea furnizorului este de aceea mai mult decât o formalitate. Este un element al documentării dumneavoastră, de exemplu față de responsabilii cu protecția datelor, asigurători sau conducere.
La aceasta se adaugă: un patch nu elimină software-ul malițios introdus înainte. Potrivit rapoartelor din presă, a existat o primă tentativă de atac observată deja la 17.10. Momentul exact în care serverul dumneavoastră a fost protejat este de aceea important pentru întrebarea dacă trebuie să verificați mai departe.
De ce versiunea PHP afișată nu este suficientă
Sunt corectate PHP 8.5.12, 8.4.27, 8.3.36 și 8.2.35. Multe distribuții și furnizori de hosting preiau însă corectura ca backport în propriul pachet. Atunci o interfață precum Plesk afișează în continuare 8.2.34, deși serverul este patchuit.
Invers, un număr de versiune corect poate induce în eroare. Fișierele noi nu protejează cât timp rulează procese PHP vechi în memorie. Abia după repornirea tuturor workerilor este activă starea nouă. Mai multe în articolul Cum verificați corect versiunea PHP și starea patchului.
| Afirmația furnizorului | Ce dovedește | Ce lipsește încă |
|---|---|---|
| „Toate sistemele sunt actualizate.” | puțin | versiunea sau starea pachetului, data, repornirea |
| „PHP 8.3.36 este instalat.” | versiunea | data, repornirea, serverele afectate |
| „Backport în pachetul xy, repornire la …” | patchul și activarea | eventual date despre PHP 8.1 și mai vechi |
Ce date vă trebuie de la furnizorul de hosting
Cereți răspunsuri la aceste puncte, dacă este posibil pentru fiecare site sau contract:
- Ce ramuri și versiuni PHP sunt active pentru site-urile dumneavoastră, inclusiv cele mai vechi, care rulează doar pentru anumite directoare?
- Sunt incluse corecturile pentru CVE-2026-109618 și CVE-2026-109619, ca versiune oficială sau ca backport?
- Când a fost instalată actualizarea și când au fost repornite toate procesele PHP (pool-uri FPM, Apache, LiteSpeed)?
- Este
session.upload_progress.enableddezactivat din cauza CVE-2026-115560? - Ce mod de operare folosește tariful dumneavoastră, de exemplu PHP-FPM sau Apache cu mod_php? La mod_php, echipa PHP vede cel mai mare risc.
- Ce loguri de acces și de erori începând cu 20.10.2026 sunt păstrate și cum le puteți obține?
Dacă un site rulează încă pe PHP 8.1 sau mai vechi, întrebați separat. Pentru aceste ramuri nu mai există actualizări oficiale, ci doar backporturi minime la nivel de sursă pentru 7.4, 8.0 și 8.1.
Model: solicitarea confirmării actualizării PHP de la furnizorul de hosting
Copiați textul într-un tichet de suport sau într-un e-mail către furnizorul dumneavoastră de hosting. Completați datele din paranteze drepte.
Subiect: Solicitare de confirmare privind starea patchurilor PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Bună ziua,
găzduim la dumneavoastră următoarele site-uri / contracte:
[număr de client, contract, domenii]
În legătură cu vulnerabilitățile de securitate PHP CVE-2026-109618 și
CVE-2026-109619 (PHP2Shell, patchuri din 21.10.2026) precum și cu
indicația privind CVE-2026-115560 din 23.10.2026, vă rugăm să ne
confirmați în scris următoarele puncte:
1. Ce versiuni PHP, respectiv ce stări ale pachetelor, sunt active pentru site-urile noastre?
2. Conțin acestea corecturile (versiune oficială sau backport)?
3. Data și ora instalării.
4. Data și ora repornirii tuturor proceselor PHP (FPM, Apache,
LiteSpeed etc.).
5. Este session.upload_progress.enabled dezactivat la nivel de server?
6. Ce mod de operare PHP este utilizat (de ex. PHP-FPM, mod_php)?
7. Sunt păstrate logurile de acces și de erori începând cu 20.10.2026 și
cum le putem obține?
8. Dacă un site folosește încă PHP 8.1 sau o versiune mai veche: ce
protecție există acolo și ce migrare recomandați?
Avem nevoie de aceste informații pentru documentația noastră internă.
Vă mulțumim și vă transmitem cele mai bune urări
[Nume, firmă, funcție]
Cum evaluați corect răspunsul și îl verificați singur
Un răspuns bun indică stări, date și ore concrete. Formulări generale precum „am reacționat” nu sunt suficiente pentru dosarul dumneavoastră. În acest caz, cereți politicos punctele lipsă.
Dacă tariful dumneavoastră permite, verificați suplimentar singur. Cu acces SSH, de regulă sunt suficiente aceste comenzi:
# Versiunea din linia de comandă (poate diferi de versiunea web)
php -v
# Starea pachetelor pe Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Starea pachetelor pe RHEL, Alma, Rocky
rpm -qa | grep -i php
# De când rulează procesele PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Dacă momentul de pornire al proceselor PHP este anterior datei de instalare confirmate, repornirea nu a fost completă.
Dacă furnizorul de hosting nu răspunde sau răspunde evaziv
Dacă răspunsul lipsește sau lipsesc datele decisive, nu ar trebui să considerați situația clarificată. BSI recomandă scoaterea temporară a serverelor web din rețea dacă o actualizare nu este posibilă imediat. Dacă acest lucru este proporțional pentru site-ul dumneavoastră decide conducerea, ideal în scris și cu dată.
În paralel, merită să căutați eventuale urme ale unui atac, deoarece momentul patchului rămâne deschis. Indicii oferă articolul Am fost deja compromis?. Fără acces SSH, confirmarea scrisă rămâne cea mai importantă dovadă a dumneavoastră. Ce obligații revin furnizorului de hosting și care dumneavoastră explică pagina Shared hosting: ce face furnizorul; pentru serverele administrate ajută Server administrat: clarificarea responsabilității.
Păstrați solicitarea, răspunsul și propriile rezultate ale verificărilor, cu dată, într-un singur dosar. Acest dosar ajută ulterior la întrebările asigurătorilor sau ale responsabililor cu protecția datelor.
Cum ajută PHP SOS concret?
- Formulăm împreună cu dumneavoastră solicitarea către furnizorul de hosting și evaluăm tehnic răspunsul.
- Acolo unde există acces, verificăm noi înșine starea pachetelor, modul de operare activ și repornirea proceselor PHP.
- Dacă rămân lacune, aplicăm măsuri provizorii sau planificăm trecerea la o versiune acceptată.
- Consemnăm rezultatul și momentele într-o dovadă pe care o puteți transmite intern.
Cum decurge actualizarea cu repornire și dovadă descrie Serviciul de patch PHP.
Întrebări frecvente
Este suficient dacă furnizorul de hosting scrie că totul este actualizat?
Pentru documentarea dumneavoastră, mai degrabă nu. Cereți date concrete: starea pachetului sau versiunea pentru fiecare ramură PHP, data instalării și data repornirii tuturor proceselor PHP. Abia cu acestea puteți delimita fereastra de vulnerabilitate.
De ce interfața mea de hosting afișează în continuare PHP 8.2.34?
Distribuțiile și furnizorii de hosting aplică uneori corecturile de securitate ca backport, fără să schimbe numărul de versiune. Plesk poate afișa atunci în continuare 8.2.34, deși serverul este patchuit. Claritatea o aduce doar confirmarea furnizorului privind starea pachetului.
Ce fac dacă furnizorul de hosting nu răspunde?
Documentați solicitarea cu data și reveniți după un interval rezonabil. Verificați în paralel dacă puteți aplica singur măsuri provizorii și stabiliți cu conducerea dacă site-ul este scos din rețea până la clarificare, așa cum recomandă BSI pentru serverele nepatchuite.
O actualizare WordPress sau a magazinului închide și ea vulnerabilitatea?
Nu. PHP2Shell se află în PHP însuși. O actualizare a CMS-ului sau a software-ului magazinului nu schimbă nimic la interpretorul PHP care rulează pe server.