In breve: tra i fatti accertati su PHP2Shell rientrano i due numeri CVE, la valutazione CVSS v4.0 9,2, le versioni PHP corrette e le misure transitorie di php.net. È accertata anche l'allerta di livello arancione del BSI (Bundesamt für Sicherheit in der Informationstechnik, l'Ufficio federale tedesco per la sicurezza informatica). Non sono accertati una valutazione CVSS 10, attacchi riusciti su larga scala confermati e un elenco di indicatori di compromissione. Chi tiene separati questi tre livelli decide meglio.
Perché serve un fact check su PHP2Shell
Poche vulnerabilità degli ultimi anni hanno generato tanti titoli in così poco tempo. Già prima che il team PHP pubblicasse gli aggiornamenti, il 21 ottobre 2026, circolavano secondo i rapporti post sui forum, screenshot e presunti dettagli. Sono seguiti avvisi delle autorità, blog dei produttori, conteggi dei server esposti e un'ondata di consigli.
Per i gestori questo significa che non ogni numero e non ogni consiglio ha la stessa qualità. Una parte proviene da fonti primarie, una parte da un'informazione seria, una parte da speculazioni. Questo articolo ordina ciò che può usare come dato certo per le Sue decisioni. Le basi della vulnerabilità sono spiegate nella pagina Che cos'è PHP2Shell?.
Che peso hanno le diverse fonti
Una semplice gerarchia aiuta a leggere ogni segnalazione:
- php.net: il progetto PHP è la fonte primaria per numeri CVE, valutazioni, modalità di esecuzione interessate, versioni corrette e misure transitorie. Come il progetto tratta in generale le segnalazioni di sicurezza è descritto nel nostro articolo sul processo di sicurezza di PHP.
- Autorità: il BSI fornisce la valutazione della situazione in Germania e raccomandazioni operative; CERT-EU e CERT-Bund (il CERT del governo tedesco) li integrano.
- Distribuzioni e fornitori: Debian, Ubuntu, Red Hat, hoster e servizi di piattaforma si pronunciano in modo vincolante solo sui propri pacchetti e servizi.
- Società di sicurezza: Cloudflare, Unit 42, CybelAngel e altre riferiscono sulla base di misurazioni proprie. Sono preziose, ma ciascuna con un proprio metodo.
- Media e social network: utili per la rapidità, deboli sui dettagli. Le affermazioni che provengono da lì richiedono una conferma da una fonte più in alto.
Accertato, riportato, non accertato: il quadro d'insieme
La tabella seguente classifica le affermazioni più frequenti. «Accertato» significa: fonte primaria o autorità. «Riportato» significa: da media o da dichiarazioni dei produttori, non confermato in modo indipendente.
| Affermazione | Classificazione | Base |
|---|---|---|
| Due vulnerabilità, CVE-2026-109618 e CVE-2026-109619 | accertato | php.net |
| Valutazione CVSS v4.0 9,2, critica | accertato | php.net |
| Valutazione CVSS 10 | non sostenibile | secondo i rapporti, da un post su un forum prima della segnalazione |
| Corrette in 8.5.12, 8.4.27, 8.3.36, 8.2.35 | accertato | php.net |
| mod_php con il rischio più alto, exploit dimostrato prima del codice dell'applicazione | accertato | php.net |
| Interessate quasi tutte le versioni fino a PHP 5.4 | riportato | stampa specializzata |
| Primo tentativo di attacco il 17/10 | riportato | rapporti dei media che citano Amazon |
| Oltre 22,6 milioni di istanze esposte | riportato | Unit 42, secondo TechTarget |
| Attacchi riusciti su larga scala | non accertato | secondo il BSI inizialmente non noti |
| Indicators of Compromise confermati | non esistono | nessuna pubblicazione |
| Le misure transitorie proteggono completamente | falso | php.net le definisce espressamente incomplete |
Colpisce quanto presto i numeri prendano vita propria. La valutazione 10.0 del post sul forum è comparsa ancora giorni dopo in vari articoli, benché il team PHP avesse da tempo pubblicato 9,2.
Dove si trova davvero l'incertezza
La principale questione aperta non è tecnica, ma temporale: che cosa è successo, sui singoli server, tra il primo tentativo di attacco riportato e la patch? Non esiste una risposta generale. Cloudflare e Patchstack hanno riferito di tentativi di attacco, watchTowr ha riprodotto CVE-2026-109618 secondo le proprie dichiarazioni. Huntress, dal canto suo, al momento della sua segnalazione non vedeva attacchi negli ambienti dei partner.
Queste affermazioni non si contraddicono. Descrivono ambiti diversi: un grande servizio proxy, una società di sicurezza per plugin, un team di ricerca e un'azienda con una propria base clienti. Da qui non emerge un quadro complessivo.
Lo stesso vale per la domanda su quali versioni siano interessate. Per le 8.2-8.5 la situazione è chiara. Per i rami più vecchi esistono backport minimi del codice sorgente per 7.4, 8.0 e 8.1, ma nessun rilascio ufficiale. Ciò che sta prima è, secondo la stampa specializzata, interessato quasi senza eccezioni. Per la Sua pianificazione cambia poco: un server con PHP 8.1 o precedente, senza backport confermato, va trattato come a rischio.
L'assenza di prove di attacchi non è una prova di sicurezza. Poiché non esistono indicatori di compromissione confermati, un attacco a un singolo server si può valutare solo attraverso una verifica del comportamento, non con un elenco.
Che cosa ne ricava per i Suoi server
Dai fatti accertati derivano pochi passaggi chiari. Da quelli non accertati deriva soprattutto cautela.
- Verificare lo stato della patch: versione corretta oppure backport confermato dal fornitore. Il solo numero di versione visualizzato non basta.
- Riavviare tutti i processi PHP: i nuovi file hanno effetto solo quando non girano più processi vecchi.
- Conservare i log dal 20/10: la stampa specializzata lo consiglia, perché una verifica successiva resti possibile.
- Cercare tracce: nuovi file PHP nelle cartelle di upload, cronjob sconosciuti, processi del server web con shell. La pagina Sono già compromesso? guida attraverso la verifica.
- Controllare i consigli: applicare i suggerimenti di forum e social network solo se sono riconducibili a php.net o a un'autorità. Quali raccomandazioni facciano danni al momento lo raccoglie l'articolo Falsi consigli pericolosi su PHP2Shell.
Per la comunicazione interna vale la stessa separazione. Chi presenta alla direzione «accertato», «riportato» e «aperto» in modo distinto evita sia l'allarmismo sia un falso cessato allarme.
Come aiuta concretamente PHP SOS?
- Quadro per i Suoi sistemi: applichiamo i fatti accertati ai Suoi server e distinguiamo, nella documentazione, ciò che è misurato, ciò che è riportato e ciò che resta aperto.
- Patch e prova: verifichiamo lo stato dei pacchetti e il riavvio di ogni servizio PHP e lo mettiamo per iscritto.
- Verifica delle tracce: conserviamo i log dal 20 ottobre e cerchiamo anomalie di comportamento, finché l'incidente non è concluso e documentato.
- Valutazione continua: classifichiamo per Lei le nuove segnalazioni prima che se ne ricavino misure.
Lo svolgimento è descritto nel pronto intervento PHP2Shell.
Conclusione
PHP2Shell è una cosa seria, ed è ben documentato. Proprio per questo vale la pena uno sguardo sobrio: le fonti primarie bastano per tutte le decisioni importanti. Ciò che circola oltre è spesso più rapido che preciso. Applicare la patch, riavviare, conservare i log e cercare tracce resta la risposta, a prescindere da quale numero stia girando in quel momento.
Domande frequenti
PHP2Shell ha una valutazione CVSS 10?
No. Secondo i rapporti, il valore 10 proviene da un post su un forum che circolava prima della segnalazione ufficiale. Il team PHP valuta entrambe le vulnerabilità con CVSS v4.0 9,2. Resta comunque la categoria critica.
Esiste un elenco di indicatori per riconoscere gli attacchi PHP2Shell?
Finora no. Non sono stati pubblicati Indicators of Compromise confermati. Chi vuole verificare se un server è stato colpito deve badare ad anomalie di comportamento, ad esempio processi del server web che avviano una shell o nuovi file PHP nelle cartelle di upload.
Qual è la fonte più affidabile su PHP2Shell?
Per i fatti tecnici, le segnalazioni su php.net; per la valutazione della situazione in Germania, il BSI. Articoli dei media e blog dei produttori completano il quadro, ma vanno indicati come rapporti e letti confrontandoli con la fonte primaria.
Sono davvero interessate tutte le versioni di PHP a partire da PHP 5?
La situazione è documentata per i rami da 8.2 a 8.5, per i quali esistono aggiornamenti. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4; secondo i rapporti, CERT-EU riteneva possibili versioni a partire da PHP 5. Per le versioni più vecchie non esistono aggiornamenti ufficiali, perciò in ogni caso le consideri a rischio.