In breve: un file che richiama soltanto phpinfo() mostra a ogni visitatore versione, moduli, percorsi e impostazioni di PHP, spesso anche variabili d'ambiente con credenziali. Per la sicurezza di phpinfo vale quindi: non lasciare mai tali file in modo duraturo nel webroot, cancellarli dopo l'uso e verificare lo stato di PHP preferibilmente tramite gestione dei pacchetti e configurazione. Lo stato delle patch contro PHP2Shell, comunque, un output di phpinfo non lo dimostra.
Il file di test che resta
Dal 21/10/2026 migliaia di admin verificano quale versione di PHP forniscono i loro siti. La via più rapida è nota: creare un file info.php con una sola riga, richiamarlo nel browser, leggere il risultato. Funziona. Il problema inizia dopo, quando il file viene dimenticato.
Tali file sopravvivono sorprendentemente a lungo. Passano con i traslochi, finiscono nei backup e dopo anni compaiono in directory che nessuno conosce più. Gli scanner automatizzati interrogano di continuo i nomi di file tipici. Ciò che per l'admin era uno strumento di aiuto, per un aggressore è un manuale di costruzione del server.
Sono particolarmente interessati agenzie e hoster con molti siti di clienti. Chi in una settimana frenetica controlla decine di siti crea in fretta decine di file di test. Basta una sola cartella dimenticata perché il file sia ancora richiamabile mesi dopo.
Che cosa rivela phpinfo() e perché conta per la sicurezza
Secondo il manuale PHP, phpinfo() emette lo stato attuale di PHP. Tramite costanti si può controllare quali parti compaiano; senza indicazioni compare tutto.
| Ambito (costante) | Contenuto secondo il manuale | Perché è delicato |
|---|---|---|
INFO_GENERAL |
Build, posizione del php.ini, server web, sistema | Rivela sistema operativo e percorsi |
INFO_CONFIGURATION |
Valori locali e master di tutte le direttive | Mostra se disable_functions o open_basedir sono attivi |
INFO_MODULES |
Estensioni caricate con impostazioni | Gli aggressori vedono quali funzioni sono disponibili |
INFO_ENVIRONMENT |
Variabili d'ambiente | Qui compaiono spesso credenziali del database o delle API |
INFO_VARIABLES |
Variabili predefinite (Environment, GET, POST, Cookie, Server) | Contiene header e cookie della richiesta corrente |
Le ultime due righe sono le più pericolose. Le applicazioni moderne caricano volentieri le credenziali da variabili d'ambiente, ad esempio da un file .env o dalla configurazione del container. Questi valori compaiono allora in chiaro nell'output. Come proteggere in generale tali segreti lo descrive l'articolo Proteggere correttamente credenziali e file .env.
A ciò si aggiunge: l'output mostra i valori della richiesta in corso, quindi anche cookie e header. Se un aggressore riesce a indirizzare un visitatore alla pagina e a leggerne la risposta, ad esempio tramite una vulnerabilità di cross-site scripting altrove, diventano visibili persino i cookie contrassegnati come HttpOnly.
Perché phpinfo non è una prova contro PHP2Shell
Molti hanno creato il file proprio per verificare lo stato delle patch. A questo scopo serve solo in parte. Distribuzioni e hoster installano spesso le correzioni come backport; secondo le segnalazioni, ad esempio Ubuntu 24.04 dopo l'aggiornamento mostra ancora 8.3.6. Il numero visualizzato dice quindi poco. Viceversa, un numero aggiornato non dimostra che tutti i worker siano stati riavviati.
Attendibile è lo stato dei pacchetti con i numeri CVE nel changelog, integrato dal riavvio di tutti i processi PHP. Come si fa lo spiega l'articolo Verificare correttamente versione di PHP e stato delle patch.
Un output momentaneo nel contesto web ha comunque il suo posto: mostra quali php.ini e quali valori valgano effettivamente per il sito, perché la riga di comando legge spesso una configurazione diversa. Le basi su livelli e precedenza le spiega Il php.ini spiegato. Se le serve, allora con protezione dell'accesso, con nome di file casuale e solo per pochi minuti.
Per la maggior parte delle domande esistono comunque vie migliori. La versione di PHP di un pool FPM si trova nella sua configurazione e nell'elenco dei processi. Singoli valori si possono richiedere con ini_get() in uno script fuori dal webroot, senza rivelare tutto. E nei pannelli di hosting l'interfaccia mostra la versione assegnata per ogni sito, anche se senza indicazioni sui backport.
Trovare i file dimenticati: passi di verifica concreti
Così si individuano le eredità del passato su un server Linux. I comandi leggono soltanto e non modificano nulla.
- Cercare i file con una chiamata a phpinfo (adattare il percorso):
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Verificare i nomi di file tipici, anche senza riscontri nel contenuto:
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Valutare i risultati: non ogni ritrovamento è un file di test. Strumenti di amministrazione, pannelli o framework possono usare
phpinfo()dietro un login. Decisivo è se il file sia raggiungibile da Internet senza autenticazione. -
Controllare gli accessi nel log prima di cancellare:
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Cancellare e cambiare i segreti: se nell'output c'era una password o una chiave e il file era pubblico, il valore si considera noto. Lo cambi.
Un ritrovamento con data di creazione ignota e contenuto anomalo accanto alla chiamata a phpinfo può essere anche una backdoor. In tal caso non si limiti a cancellare, ma metta al sicuro e faccia verificare, vedi Riconoscere e rimuovere le web shell.
Prevenire in modo duraturo invece di fare pulizia
Tre misure fanno sì che il tema non si ripresenti. Primo: inserire phpinfo nell'elenco disable_functions del php.ini per il contesto web. Verifichi prima se il suo pannello usa la funzione per una pagina di stato. Come agisca l'impostazione e dove siano i suoi limiti lo trova in Usare bene disable_functions.
; php.ini per FPM o Apache, poi riavviare tutti i processi PHP
disable_functions = phpinfo
expose_php = Off
Secondo: messa a disposizione solo tramite una procedura fissa, ad esempio con Git o pipeline di build, in modo che nessun file singolo arrivi a mano nel webroot. Terzo: le informazioni di stato appartengono al monitoraggio o all'inventario, non a una pagina pubblica.
expose_php = Off rimuove inoltre l'header con cui PHP comunica la propria versione in ogni risposta. Non sostituisce un aggiornamento, ma toglie agli scanner automatizzati un'informazione comoda. Chi ha più persone con accesso al server dovrebbe inoltre concordare una regola semplice: i file di test vengono cancellati nello stesso passaggio in cui sono creati, non «più tardi».
Come aiuta concretamente PHP SOS?
- Cerchiamo nei suoi webroot file phpinfo, script di test e altre eredità del passato e valutiamo ogni ritrovamento.
- Analizziamo gli accessi ai file trovati e Le diciamo quali segreti dovrebbe sostituire.
- Dimostriamo lo stato delle patch contro PHP2Shell tramite changelog dei pacchetti e avvio dei processi, anziché tramite una visualizzazione della versione.
- Attuiamo in modo duraturo
disable_functions,expose_phpe altri hardening nell'ambito dell'hardening del server.
Conclusione: un file phpinfo si crea in pochi secondi e si dimentica altrettanto in fretta. Chi lo cerca e lo rimuove ora chiude una fuga di dati inutile e per lo stato delle patch si affida a prove attendibili.
Domande frequenti
Un file phpinfo è di per sé una vulnerabilità?
Non apre alcun accesso, ma fornisce agli aggressori una descrizione dettagliata del server: versione, moduli, percorsi, impostazioni e, a seconda dell'ambiente, anche variabili d'ambiente. Ciò facilita attacchi mirati e può rivelare credenziali.
Il numero di versione in phpinfo dimostra che PHP2Shell è stato corretto?
No. Distribuzioni e hoster installano spesso le correzioni come backport e il numero visualizzato resta allora lo stesso. Lo stato delle patch lo dimostrano il changelog del pacchetto e la conferma del fornitore, oltre al riavvio di tutti i processi PHP.
Che cosa fare se un file phpinfo è stato pubblico a lungo?
Cancellare il file, controllare nel log di accesso chi lo ha richiamato e sostituire tutti i segreti presenti nell'output, ad esempio password del database o chiavi API prese da variabili d'ambiente.
Posso disattivare completamente phpinfo()?
Sì, tramite disable_functions nel php.ini del contesto web. Verifichi prima se un pannello o un'applicazione usa la funzione per pagine di stato e poi riavvii i processi PHP.