In breve: la vulnerabilità di Laravel che molti sviluppatori cercano in questi giorni è PHP2Shell e si trova in PHP stesso. Un aggiornamento di Laravel non la chiude. Contano un PHP aggiornato, il riavvio di tutti i processi, compresi queue worker e Octane, e un controllo di .env, storage e public.
Che cosa significa PHP2Shell per le applicazioni Laravel
Laravel è il fondamento di molti sviluppi su misura: portali clienti, strumenti interni, sistemi di prenotazione, API per app. Le vulnerabilità PHP CVE-2026-109618 e CVE-2026-109619 consentono, secondo il team PHP, di eseguire codice dannoso da remoto senza autenticazione. Quanto sia pulito il codice di Laravel è irrilevante al riguardo.
Sono interessate le modalità di esecuzione PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Laravel Octane può usare FrankenPHP come server; in tal caso PHP si trova nel programma FrankenPHP o nell'immagine del container e viene aggiornato insieme a esso. Come funzioni con FrankenPHP è descritto in Mettere in sicurezza FrankenPHP.
Vulnerabilità Laravel: verificare versione di PHP e processi
Da riga di comando, php artisan about mostra la versione di PHP, la versione di Laravel e impostazioni importanti come ambiente e modalità debug. È però la versione del PHP CLI. Le richieste web le elabora PHP-FPM oppure Octane, e può essere una versione diversa. In caso di dubbio si faccia confermare dal gestore quale stato dei pacchetti giri su tutti i percorsi.
Le versioni upstream corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35; i backport possono riportare numeri più vecchi. Quali versioni di PHP supporta la Sua versione di Laravel, lo verifichi nei requisiti di sistema nella documentazione su laravel.com.
Dopo l'aggiornamento arriva la parte che in Laravel si dimentica più spesso: i processi di lunga durata.
# Mostrare versioni e configurazione
php artisan about
# Indicare ai queue worker di terminare dopo il job in corso
php artisan queue:restart
# Terminare Horizon, in modo che il gestore di processi lo riavvii
php artisan horizon:terminate
I worker si riavviano poi solo se un gestore di processi come Supervisor o systemd li sorveglia. I server Octane e i container devono essere riavviati completamente o rilasciati con una nuova immagine. Per le configurazioni con container vale Aggiornare PHP nei container Docker.
Dove le applicazioni Laravel sono vulnerabili
| Posizione | Contenuto | Punto da controllare |
|---|---|---|
.env |
APP_KEY, database, posta, chiavi API |
non deve mai essere raggiungibile dal web |
bootstrap/cache/config.php |
configurazione in cache con segreti | Diritti, data di modifica |
public/ |
Document root con index.php |
file PHP aggiuntivi |
storage/app/public |
Upload, raggiungibili tramite public/storage |
nessun file PHP |
storage/logs/ |
laravel.log, spesso con dati delle richieste |
salvare, non pubblico |
vendor/ |
Pacchetti Composer | composer audit, confronto con composer.lock |
La cartella storage/app/public è raggiungibile tramite un collegamento simbolico in public/storage. Un file PHP depositato lì può, a seconda della configurazione del server, essere eseguito direttamente. Lo blocchi a livello di web server.
APP_DEBUG in produzione deve essere false. Una pagina di errore con output di debug può mostrare variabili d'ambiente, percorsi e parti del codice e facilita il lavoro a qualsiasi aggressore.
Interfacce admin e pacchetti come rischio
Le applicazioni Laravel non hanno un'interfaccia admin uniforme. Spesso sono aree proprie o pacchetti come Filament o Nova. Verifichi chi ha diritti di amministratore, se l'accesso preveda un secondo fattore e se le route admin debbano essere raggiungibili dall'esterno. Anche i token API, ad esempio di Sanctum o Passport, dovrebbero essere revocati e riemessi in caso di sospetto.
Verifichi inoltre se strumenti di sviluppo siano raggiungibili in produzione, come barre di debug, Telescope o route di prova. Mostrano spesso richieste, query e configurazione e vanno messi dietro un'autenticazione o rimossi del tutto dall'ambiente di produzione.
I pacchetti Composer sono il secondo grande blocco. Ogni dipendenza porta con sé codice proprio, e i pacchetti senza manutenzione bloccano poi gli aggiornamenti di PHP. composer audit mostra le vulnerabilità note, ma non sostituisce un controllo del codice proprio.
Che cosa può fare un aggiornamento di Laravel e che cosa no
Un aggiornamento di Laravel o di singoli pacchetti chiude errori noti in quel codice. Non applica patch a PHP, non riavvia i worker, non rinnova un APP_KEY trapelato e non rimuove file da storage o public. Se prima della patch sia successo qualcosa, lo si chiarisce solo controllando log, file e database.
Per i team con una pipeline di deployment vale: l'aggiornamento di PHP va fatto anche nell'ambiente di build e nelle immagini di base, altrimenti il prossimo deployment riporta una versione vecchia. Verifichi inoltre se gli ambienti di staging o di review siano raggiungibili pubblicamente. Girano spesso con APP_DEBUG=true e dati reali e con gli aggiornamenti di sicurezza vengono facilmente trascurati.
In che modo PHP SOS aiuta concretamente?
- Verifichiamo PHP web, CLI e worker della Sua applicazione Laravel e accompagniamo il riavvio ordinato di tutti i processi.
- Mettiamo al sicuro i log a partire dal 20/10/2026, il database e lo stato del codice e lo confrontiamo con il Suo repository.
- Controlliamo
.env, cache della configurazione,storage,public, account admin e token API. - Per un controllo più approfondito del codice proprio mettiamo in contatto, tramite partner specializzati, per un audit di sicurezza o un penetration test.
Domande frequenti
Devo aggiornare Laravel a causa di PHP2Shell?
Un aggiornamento di Laravel non chiude PHP2Shell, perché la vulnerabilità è nell'interprete PHP. Tenga comunque Laravel aggiornato. Per PHP2Shell servono un PHP aggiornato e il riavvio di tutti i processi PHP, anche dei worker.
Perché in Laravel il riavvio di PHP-FPM spesso non basta?
Queue worker, Horizon, Octane e lo scheduler girano come processi PHP propri da riga di comando. Caricano PHP una sola volta all'avvio e poi continuano a lavorare con la vecchia versione in memoria finché non vengono riavviati.
Che fare se il file .env potrebbe essere trapelato?
In tal caso dovrebbe rinnovare APP_KEY, la password del database e tutte le chiavi dei servizi esterni. Tenga presente che un nuovo APP_KEY termina le sessioni esistenti e rende illeggibili i dati cifrati con la vecchia chiave; lo pianifichi con i Suoi sviluppatori.