Domande frequenti
Quali versioni di PHP sono interessate?
Tutte le versioni precedenti a 8.5.12, 8.4.27, 8.3.36 e 8.2.35 nei rami supportati. PHP 8.1 e precedenti sono a fine vita e non ricevono rilasci dal progetto PHP; li consideri interessati, a meno che il Suo fornitore non confermi una correzione tramite backport.
Il mio sito non mostra la versione di PHP. Sono al sicuro?
Non necessariamente. Nascondere la versione (expose_php = Off) è una buona pratica, ma non corregge nulla. Verifichi sul server con php -v o chieda al Suo provider.
Lo strumento mostra una versione vecchia, ma il mio hosting dice che è aggiornata. Chi ha ragione?
Forse entrambi. Distribuzioni Linux come Debian, Ubuntu e RHEL applicano spesso backport delle correzioni di sicurezza senza modificare il numero di versione. Chieda al Suo hosting quale build del pacchetto è installata e se il suo changelog menziona CVE-2026-109618 e CVE-2026-109619.
WordPress, Laravel o il mio CMS sono interessati?
Le falle sono nello stesso PHP, quindi qualsiasi applicazione eseguita su un PHP interessato è esposta. I ricercatori hanno dimostrato attacchi senza autenticazione contro WordPress, Drupal e Joomla, ma erano solo esempi: basta anche una semplice pagina «Hello World». Aggiornare WordPress o i plugin non risolve: è PHP che va aggiornato.
Possono trapelare dati anche se non è stato eseguito codice?
Sì. CVE-2026-109619 può divulgare la memoria del processo PHP — password, token di sessione, chiavi API e certificati di altre richieste — senza che l’attaccante esegua codice. Queste fughe non lasciano file e sono difficili da rilevare, quindi cambi i segreti di ogni sito che ha eseguito una versione interessata su Internet.
Disattivare session.upload_progress risolve il problema?
No. php.net indica session.upload_progress.enabled=0 come mitigazione parziale per alcuni percorsi confermati di CVE-2026-109619. Non copre tutte le varianti e non ha alcun effetto su CVE-2026-109618.
Un web application firewall è sufficiente?
Un WAF o i limiti sulle richieste possono ridurre l’esposizione durante l’aggiornamento, ma i problemi riguardano il modo in cui PHP gestisce richieste e memoria. L’aggiornamento resta necessario.
Devo riavviare qualcosa dopo l’aggiornamento?
Sì. PHP-FPM, Apache, LiteSpeed e i worker di lunga durata continuano a eseguire il codice vecchio finché non vengono riavviati. I container devono essere ricreati dalla nuova immagine.
Che cosa fa esattamente questo strumento?
Invia una richiesta HEAD (o GET se HEAD non è consentita) all’indirizzo inserito, segue fino a tre reindirizzamenti e legge intestazioni di risposta come X-Powered-By e Server. Non invia mai payload di exploit, richieste di grandi dimensioni o upload, e non analizza altri percorsi.
È legale verificare qualsiasi sito web?
Verifichi solo siti di Sua proprietà o che è autorizzato a valutare. La richiesta è identica a una normale visita, ma l’uso responsabile è a Suo carico. Limitiamo le verifiche per rete e per sito.
PHP 8.5.12 è stato corretto completamente?
Il 22 ottobre 2026 sono circolate segnalazioni di un crash in 8.5.12, ma non sono state confermate come vulnerabilità remota. Seguiamo php.net; se uscirà un nuovo rilascio, questo sito verrà aggiornato e la data di «ultima verifica» cambierà.
Dove posso leggere i dettagli ufficiali?
Su php.net e nei bollettini GitHub del progetto PHP GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp. Il team di ricerca (Wiz Research, OpenAI Codex Security e Calif) ha pubblicato i risultati su php2shell.com.
Chi ha scoperto le vulnerabilità?
Ricercatori di Wiz Research, OpenAI Codex Security e Calif, tramite una divulgazione coordinata con il team di sicurezza di PHP, che ha preparato le correzioni. Veda il post di The PHP Foundation sul rilascio.