# File phpinfo(): perché devono sparire

> Un file phpinfo dimenticato rivela percorsi, moduli e a volte credenziali. Come trovare questi file, rimuoverli e verificare PHP in modo più sicuro.

Fonte: https://phpsos.de/it/blog/phpinfo-dateien-entfernen/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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](https://phpsos.de/it/blog/env-dateien-schuetzen/).

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](https://phpsos.de/it/php2shell/php-version-pruefen/).

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](https://phpsos.de/it/php/php-ini-erklaert/). 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.

1. **Cercare i file con una chiamata a phpinfo** (adattare il percorso):

```bash
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
```

2. **Verificare i nomi di file tipici**, anche senza riscontri nel contenuto:

```bash
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
```

3. **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.

4. **Controllare gli accessi nel log** prima di cancellare:

```bash
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
```

5. **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.

> **Consiglio:**
> 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](https://phpsos.de/it/ratgeber/webshell-erkennen/).

## 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](https://phpsos.de/it/ratgeber/disable-functions/).

```ini
; 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_php` e altri hardening nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/).

**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.

## Fonti

- [Manuale PHP: phpinfo()](https://www.php.net/manual/de/function.phpinfo.php)
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
- [php.net: avvisi di sicurezza](https://www.php.net/)