Cosa è successo
Il 21 ottobre il progetto PHP ha rilasciato le correzioni per due vulnerabilità, CVE-2026-109618 e CVE-2026-109619. Entrambe hanno un punteggio CVSS di 9.2 e, secondo l'analisi di Arctic Wolf, possono permettere a un attaccante non autenticato di eseguire codice su un server che gestisce richieste web con PHP.
I bug si trovano nel ciclo di gestione delle richieste di PHP stesso, non in un framework o in un plugin:
- CVE-2026-109618 è una corruzione della memoria che si verifica quando una condizione di memoria esaurita interrompe PHP mentre i dati della richiesta sono stati preparati solo in parte.
- CVE-2026-109619 è un use-after-free: lo stato di una richiesta può sopravvivere ed essere letto da una richiesta successiva sullo stesso worker, il che può anche far trapelare contenuti della memoria.
Vale la pena soffermarsi sul secondo punto. Qualys osserva che la memoria trapelata dai worker può contenere password, token e API key. Quindi anche se nessuno ottiene una shell sul tuo server, i segreti possono uscire dalla porta.
Dopo la patch le cose si sono mosse in fretta, e la scala è enorme: The Hacker News cita stime di Censys secondo cui oltre 32 milioni di servizi PHP eseguono ancora una versione vulnerabile.
- Il team di threat intelligence di Amazon ha dichiarato che gli attacchi mirati sono iniziati quattro giorni prima della pubblicazione delle correzioni, come riporta BleepingComputer.
- Il 24 ottobre un ricercatore di Perplexity ha confermato l'esecuzione di codice riuscita contro degli honeypot (The Hacker News).
- Il 26 ottobre la CISA ha aggiunto entrambe le CVE al suo catalogo Known Exploited Vulnerabilities e ha dato alle agenzie federali statunitensi tempo fino al 29 ottobre per correggerle.
Perché riguarda anche le app piccole
Qui gli attaccanti non scelgono i bersagli in base alle dimensioni dell'azienda. Scansionano internet alla ricerca di qualsiasi cosa risponda come PHP e provano l'exploit. Un progetto secondario dimenticato su una VPS è raggiungibile quanto un grande e-commerce.
Alcuni dettagli rendono questo caso particolarmente urgente:
- Non dipende dal tuo codice. Arctic Wolf sottolinea che, poiché le falle sono nell'elaborazione delle richieste di PHP, l'esposizione non dipende dall'applicazione che esegui. Un'app Laravel scritta perfettamente su una vecchia build di PHP è comunque esposta.
- Molte configurazioni server sono coinvolte. Apache con mod_php è considerato il rischio più alto, ma anche PHP-FPM, php-cgi, FrankenPHP e LiteSpeed sono indicati come vulnerabili, così come i prodotti e le appliance che includono PHP.
- Le versioni vecchie di PHP sono diffuse. Qualys riporta che circa il 71% delle installazioni PHP di cui ha potuto rilevare la versione era già a fine vita. Se usi la 8.1 o precedenti, per te non esiste una correzione upstream regolare.
Come verificare la tua app
Cerchi una risposta per ogni server: c'è qualcosa che serve richieste web con PHP, e in quale versione esatta?
1. Elenca tutto ciò che ospiti. Non solo l'app principale. Includi siti marketing, blog, documentazione, ambienti di staging, strumenti admin e qualsiasi cosa su un sottodominio. Quelli dimenticati sono i più pericolosi.
2. Guarda gli header di risposta. Molte configurazioni PHP si annunciano in un header X-Powered-By o Server. L'assenza dell'header non significa assenza di PHP (si può disattivare con expose_php = Off), ma un header è un sì immediato. Anche le pagine di errore dettagliate tradiscono lo stack: uno stack trace PHP in produzione dice a un attaccante esattamente cosa esegui.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Controlla la versione che serve il traffico web, non solo la CLI. php -v sul server può riportare una build diversa da quella effettivamente usata da Apache o PHP-FPM; Qualys lo segnala espressamente. Controlla il binario di FPM o il modulo PHP del web server, oppure chiedi al tuo hosting.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Confronta con le versioni corrette. Se installi PHP dalla tua distribuzione Linux, la correzione potrebbe essere stata riportata (backport) in un pacchetto con un numero di versione apparentemente più vecchio, quindi controlla l'advisory della tua distro invece della sola stringa di versione. Altrimenti ti serve almeno:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. Hosting gestito? Se usi un hosting WordPress gestito o una PaaS, controlla la loro pagina di stato o il changelog per un avviso su PHP2Shell. La maggior parte applicherà la patch per te, ma "la maggior parte" non è "tutti", e una VPS autogestita è interamente sulle tue spalle.
Come risolvere
Applica la patch, poi riavvia. Aggiornare PHP è l'unica correzione completa.
Il riavvio conta: i worker in esecuzione mantengono in memoria il vecchio codice finché non vengono sostituiti. Con Docker, ricostruisci su un'immagine base aggiornata (ad esempio un tag php:8.3-fpm attuale) e rifai il deploy. Non limitarti a riavviare il vecchio container.
Su Debian o Ubuntu con PHP-FPM, di solito si fa più o meno così:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpSe oggi non puoi applicare la patch, Qualys riassume le mitigazioni temporanee di PHP. Riducono il rischio ma non rendono sicuro un server non aggiornato. Impostale in php.ini o nella configurazione del pool FPM (non in .user.ini né con ini_set), poi riavvia tutti i worker.
Se un servizio non è aggiornato e non deve essere pubblico, mettilo dietro una VPN o una allowlist di IP, oppure mettilo offline finché non puoi aggiornarlo.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeSu PHP 8.1 o precedenti, pianifica l'aggiornamento adesso. Esistono backport limitati per alcuni rami vecchi, ma ti stai affidando alla fortuna ogni volta che arriva qualcosa del genere.
Cerca segni di compromissione. Controlla processi inattesi, nuovi file nelle web root, cron job sconosciuti e connessioni in uscita dal web server. Arctic Wolf nota anche che molte richieste "PHP2Shell" nei log riutilizzano tecniche più vecchie, quindi una riga di log dall'aspetto minaccioso non significa automaticamente un'intrusione riuscita.
Ruota i segreti se eri esposto. Poiché CVE-2026-109619 può far trapelare la memoria dei worker, considera potenzialmente visti i segreti passati per un processo PHP non aggiornato ed esposto su internet: password del database, API key, chiavi di firma delle sessioni e chiavi dei provider di pagamento. Laravel e framework simili li tengono in .env, quindi verifica anche che quel file non sia mai stato accessibile dal web.
Checklist rapida
Ripercorrila per ogni dominio che possiedi:
- Ogni dominio e sottodominio che possiedi è in elenco, compresi i vecchi siti marketing e di staging.
- Sai quali usano PHP e la versione esatta che serve il traffico web.
- Ognuno è su 8.5.12, 8.4.27, 8.3.36, 8.2.35 o su una build corretta dal fornitore.
- Worker PHP e web server sono stati riavviati dopo l'aggiornamento.
- Tutto ciò che non è aggiornato è limitato o offline, con le mitigazioni applicate.
- I segreti sugli host esposti sono stati ruotati.
- La produzione non pubblicizza più la versione di PHP né mostra stack trace.
La lezione più ampia
PHP2Shell verrà corretto e dimenticato in poche settimane. Lo schema no. Il tempo tra "correzione pubblicata" e "sfruttata attivamente" ora si misura in giorni, a volte è negativo. I piccoli team non possono batterlo sul tempo con l'eroismo. Quello che funziona è sapere cosa esegui e accorgersi in fretta quando qualcosa cambia.
È lo stesso ragionamento alla base della nostra checklist di lancio per le app create con l'AI: la maggior parte degli incidenti reali nasce da cose facili da controllare, se le controlli davvero.
AppSafe scansiona il tuo sito live dall'esterno, come lo vedrebbe un attaccante. Cerca problemi come header di sicurezza mancanti, un header X-Powered-By che rivela il tuo stack, file esposti ed errori dettagliati, e ti dà correzioni in linguaggio semplice. Dopo aver applicato la patch, esegui una scansione gratuita su ciascuno dei tuoi domini per cogliere anche le altre vittorie facili.