Pe scurt: Securitatea Symfony după PHP2Shell înseamnă: aplicați patchul PHP, reporniți toate procesele, inclusiv workerii Messenger, și verificați apoi secretele, cache-ul și profilerul. Vulnerabilitatea se află în PHP, nu în Symfony; o actualizare Symfony singură nu o închide.
De ce PHP2Shell afectează fiecare proiect Symfony
Symfony este baza multor aplicații de companie, API-uri și portaluri și se găsește, în plus, în sisteme precum Shopware 6 și Contao. Potrivit echipei PHP, vulnerabilitățile PHP CVE-2026-109618 și CVE-2026-109619 permit execuția de cod malițios fără autentificare. Dacă aplicația este programată curat nu joacă niciun rol în acest caz.
Echipa PHP încadrează riscul cel mai ridicat la mod_php, dar sunt afectate și PHP-FPM, php-cgi, FrankenPHP și LiteSpeed. Proiectele Symfony operate prin Symfony Runtime cu FrankenPHP sau cu alte servere care rulează permanent au nevoie, după actualizare, de o repornire completă sau de o imagine nouă.
Securitatea Symfony: verificarea versiunii PHP și a proceselor
php bin/console about arată versiunea Symfony, mediul, modul de depanare și versiunea PHP din linia de comandă. Cererile web rulează însă prin PHP-FPM sau printr-un server de aplicații, iar acestea pot fi o altă versiune. Verificați ambele căi sau cereți operatorului să le confirme.
Versiunile upstream remediate sunt 8.5.12, 8.4.27, 8.3.36 și 8.2.35; backporturile distribuțiilor poartă adesea numere mai vechi. Ce versiuni PHP sunt acceptate de versiunea dumneavoastră de Symfony verificați conform cerințelor de sistem din documentația de pe symfony.com.
# Afișarea mediului, a modului de depanare și a versiunii PHP
php bin/console about
# Încheierea workerilor Messenger după mesajul curent
php bin/console messenger:stop-workers
# Vulnerabilități cunoscute în dependențe
composer audit
Dacă rulează mai multe instanțe în spatele unui load balancer sau în containere, fiecare instanță în parte trebuie să aibă patchul aplicat și să fie repornită. O instanță uitată servește mai departe o parte din cereri cu PHP vechi.
Workerii Messenger, comenzile cron și alte procese de fundal încarcă PHP o singură dată, la pornire. Până când sunt repornite, ele rulează cu PHP-ul vechi din memorie. Un manager de procese trebuie să îi repornească după oprire.
Unde sunt vulnerabile aplicațiile Symfony
| Loc | Conținut | Punct de verificare |
|---|---|---|
.env, .env.local, .env.local.php |
Variabile de mediu, adesea baza de date și chei API | Nu este accesibil în webroot, reînnoiți valorile în caz de suspiciune |
config/secrets/prod/ |
Secrete criptate | Cheia privată de decriptare nu aparține repository-ului |
public/ |
Rădăcina documentelor cu index.php |
Fișiere PHP suplimentare |
var/cache/prod/ |
Container generat și șabloane ca PHP | Ștergeți și regenerați în caz de suspiciune |
var/log/ |
Jurnale | Salvați |
config/packages/security.yaml |
Firewall-uri, roluri, reguli de acces | Modificări neașteptate |
Cache-ul este o ascunzătoare subestimată. Symfony generează acolo fișiere PHP care sunt încărcate la fiecare cerere. O modificare a acestor fișiere nu se observă în repository, deoarece cache-ul nu este versionat.
În producție trebuie să fie setate APP_ENV=prod și APP_DEBUG=0, iar WebProfilerBundle nu are voie să fie activ acolo. Un profiler accesibil public la /_profiler dezvăluie configurația și datele cererilor.
Zone de administrare, bundle-uri și dependențe
Proiectele Symfony au, în funcție de structură, zone de administrare proprii, adesea cu bundle-uri precum EasyAdmin sau Sonata. Verificați în security.yaml ce căi cer ce roluri, iar în baza de date cine are aceste roluri. Căile de administrare necesare doar intern ar trebui restricționate la nivelul serverului web la rețele cunoscute.
Bundle-urile și pachetele Composer sunt cod străin, cu vulnerabilități proprii. composer audit arată probleme cunoscute; mai detaliat la Verificarea vulnerabilităților din dependențele Composer. Pachetele depășite sunt, în plus, cel mai frecvent motiv pentru care un upgrade PHP durează mai mult decât s-a planificat în proiectele Symfony.
Ce poate și ce nu poate o actualizare Symfony
O actualizare a componentelor Symfony închide erori din framework. Ea nu aplică patchul PHP, nu repornește workeri, nu reînnoiește secrete scurse și nu elimină un cache manipulat. Dacă există indicii ale unui atac descrie Am fost deja compromis?. Deoarece nu există indicatori de compromitere (IoC) confirmați, ajută mai ales observarea comportamentului neobișnuit, de exemplu procese neașteptate sau conexiuni de ieșire.
Dacă proiectul este livrat ca container, noul PHP aparține imaginii de bază. Reconstruiți imaginea chiar dacă în cod nu s-a schimbat nimic și livrați-o în toate mediile. O privire în Dockerfile arată ce imagine de bază este folosită; un tag vechi fixat împiedică altfel reconstrucția să primească vreodată PHP-ul cu patch. Detalii găsiți la Aplicarea patchului PHP în containerele Docker.
Cum ajută PHP SOS concret?
- Stabilim ce PHP folosesc web-ul, CLI și workerii proiectului dumneavoastră Symfony și însoțim repornirea ordonată.
- Salvăm jurnalele începând cu 20.10.2026 și comparăm codul de pe server cu repository-ul dumneavoastră.
- Verificăm fișierele de mediu, secretele, cache-ul, setările profilerului și rolurile de administrare.
- Pentru observarea continuă a proceselor și a conexiunilor oferim monitorizare de securitate.
Întrebări frecvente
Este Symfony afectat de PHP2Shell?
Symfony însuși nu are o vulnerabilitate nouă. PHP2Shell se află în PHP, deci în mediul de execuție al fiecărei aplicații Symfony. Vulnerabilitatea este închisă printr-o actualizare PHP sau un backport confirmat și prin repornirea tuturor proceselor PHP.
Cum opresc workerii Messenger după o actualizare PHP?
Cu php bin/console messenger:stop-workers, workerii care rulează sunt instruiți să se încheie după mesajul curent. Un manager de procese, precum Supervisor sau systemd, îi repornește apoi cu noul PHP.
De ce este profilerul Symfony periculos în producție?
Profilerul arată cereri, configurație și adesea variabile de mediu. Dacă este activ pe un server public, oricine poate accesa aceste informații. El aparține doar mediului de dezvoltare.
Ce se întâmplă cu cache-ul după un atac?
Cache-ul din var/cache conține cod PHP generat. Un atacator poate depune acolo cod care rulează la fiecare cerere. În caz de suspiciune, cache-ul ar trebui șters și regenerat din codul sursă verificat.