# Sicurezza Symfony dopo PHP2Shell: proteggere progetti e worker > Proteggere i progetti Symfony dopo PHP2Shell: verificare PHP con bin/console about, riavviare i worker Messenger, controllare secret, cache e profiler. Fonte: https://phpsos.de/it/plattformen/symfony/ Stato: 25/10/2026 Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6 **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. ```bash # 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. > **Importante:** > 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](https://phpsos.de/it/ratgeber/composer-abhaengigkeiten-pruefen/). 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?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/). 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](https://phpsos.de/it/php2shell/docker-container-patchen/). ## 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](https://phpsos.de/it/leistungen/security-monitoring/). ## 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. ## Fonti - [php.net: bollettini di sicurezza](https://www.php.net/) - [Symfony](https://symfony.com/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/) - [Versioni di PHP supportate](https://www.php.net/supported-versions.php)