In breve: la sicurezza di Symfony dopo PHP2Shell significa: aggiornare PHP, riavviare tutti i processi, compresi i worker Messenger, e poi controllare secret, cache e profiler. La vulnerabilità è in PHP, non in Symfony; un aggiornamento di Symfony da solo non la chiude.
Perché PHP2Shell riguarda ogni progetto Symfony
Symfony è la base di molte applicazioni aziendali, API e portali ed è presente inoltre in sistemi come Shopware 6 e Contao. Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso senza autenticazione. Che l'applicazione sia programmata correttamente è irrilevante al riguardo.
Il team PHP classifica il rischio come il più alto con mod_php, ma sono interessati anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. I progetti Symfony gestiti tramite Symfony Runtime con FrankenPHP o altri server sempre in esecuzione richiedono, dopo l'aggiornamento, un riavvio completo o una nuova immagine.
Sicurezza di Symfony: verificare versione di PHP e processi
php bin/console about mostra la versione di Symfony, l'ambiente, la modalità debug e la versione di PHP della riga di comando. Le richieste web passano però per PHP-FPM o un application server, e può essere una versione diversa. Controlli entrambi i percorsi o li faccia confermare dal gestore.
Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; i backport delle distribuzioni portano spesso numeri più vecchi. Quali versioni di PHP supporta la Sua versione di Symfony, lo verifichi nei requisiti di sistema nella documentazione su symfony.com.
# Mostrare ambiente, modalità debug e versione di PHP
php bin/console about
# Far terminare i worker Messenger dopo il messaggio corrente
php bin/console messenger:stop-workers
# Vulnerabilità note nelle dipendenze
composer audit
Se più istanze girano dietro un load balancer o in container, ognuna deve essere aggiornata e riavviata. Un'istanza dimenticata continua a servire una parte delle richieste con il vecchio PHP.
I worker Messenger, i comandi cron e altri processi in background caricano PHP una sola volta all'avvio. Finché non vengono riavviati, girano con il vecchio PHP in memoria. Un gestore di processi deve riavviarli dopo l'arresto.
Dove le applicazioni Symfony sono attaccabili
| Posizione | Contenuto | Punto da controllare |
|---|---|---|
.env, .env.local, .env.local.php |
Variabili d'ambiente, spesso database e chiavi API | non raggiungibili dal webroot, rinnovare i valori in caso di sospetto |
config/secrets/prod/ |
secret cifrati | la chiave privata di decifratura non va nel repository |
public/ |
Document root con index.php |
file PHP aggiuntivi |
var/cache/prod/ |
container e template generati come PHP | in caso di sospetto cancellare e rigenerare |
var/log/ |
Log | salvare |
config/packages/security.yaml |
Firewall, ruoli, regole di accesso | modifiche inattese |
La cache è un nascondiglio sottovalutato. Symfony vi genera file PHP che vengono caricati a ogni richiesta. Una modifica a questi file non si nota nel repository, perché la cache non è versionata.
In produzione devono essere impostati APP_ENV=prod e APP_DEBUG=0, e il WebProfilerBundle non deve essere attivo. Un profiler raggiungibile pubblicamente in /_profiler rivela configurazione e dati delle richieste.
Aree admin, bundle e dipendenze
I progetti Symfony hanno, a seconda dell'impostazione, aree admin proprie, spesso con bundle come EasyAdmin o Sonata. Verifichi in security.yaml quali percorsi richiedano quali ruoli e nel database chi abbia quei ruoli. I percorsi admin necessari solo internamente dovrebbero essere limitati a reti note a livello di web server.
Bundle e pacchetti Composer sono codice di terzi con vulnerabilità proprie. composer audit mostra i problemi noti; per un approfondimento si veda Verificare le vulnerabilità nelle dipendenze di Composer. I pacchetti obsoleti sono inoltre il motivo più frequente per cui un aggiornamento di PHP nei progetti Symfony dura più del previsto.
Che cosa offre un aggiornamento di Symfony e che cosa no
Un aggiornamento dei componenti Symfony chiude errori nel framework. Non applica patch a PHP, non riavvia i worker, non rinnova secret trapelati e non rimuove una cache manipolata. Se ci siano indizi di un attacco è descritto in Sono già compromesso?. Poiché non esistono indicatori di compromissione (IoC) confermati, aiuta soprattutto osservare comportamenti insoliti, ad esempio processi inattesi o connessioni in uscita.
Se il progetto viene distribuito come container, il nuovo PHP va nell'immagine di base. Ricostruisca l'immagine anche se il codice non è cambiato e la rilasci in tutti gli ambienti. Uno sguardo al Dockerfile mostra quale immagine di base sia usata; un tag vecchio fissato impedisce altrimenti che la ricostruzione riceva il PHP aggiornato. I dettagli sono in Aggiornare PHP nei container Docker.
In che modo PHP SOS aiuta concretamente?
- Accertiamo quale PHP usino web, CLI e worker del Suo progetto Symfony e accompagniamo il riavvio ordinato.
- Mettiamo al sicuro i log a partire dal 20/10/2026 e confrontiamo il codice sul server con il Suo repository.
- Controlliamo file di ambiente, secret, cache, impostazioni del profiler e ruoli admin.
- Per l'osservazione continua di processi e connessioni offriamo il monitoraggio della sicurezza.
Domande frequenti
Symfony è interessato da PHP2Shell?
Symfony stesso non ha una nuova vulnerabilità. PHP2Shell è in PHP, cioè nell'ambiente di esecuzione di ogni applicazione Symfony. La vulnerabilità si chiude con un aggiornamento di PHP o un backport confermato e il riavvio di tutti i processi PHP.
Come fermo i worker Messenger dopo un aggiornamento di PHP?
Con php bin/console messenger:stop-workers i worker in esecuzione vengono istruiti a terminare dopo il messaggio corrente. Un gestore di processi come Supervisor o systemd li riavvia poi con il nuovo PHP.
Perché il profiler di Symfony è pericoloso in produzione?
Il profiler mostra richieste, configurazione e spesso variabili d'ambiente. Se è attivo su un server pubblico, chiunque può consultare queste informazioni. Deve stare solo nell'ambiente di sviluppo.
Che cosa succede alla cache dopo un attacco?
La cache in var/cache contiene codice PHP generato. Un aggressore può depositarvi codice che viene eseguito a ogni richiesta. In caso di sospetto la cache andrebbe cancellata e rigenerata dal codice sorgente verificato.