# È colpito da PHP2Shell? Facciamo chiarezza subito

> Non sa se i Suoi server sono vulnerabili a PHP2Shell? Verifichiamo da remoto versione, modalità di esecuzione e stato della patch. Ci chiami o scriva su WhatsApp.

Fonte: https://phpsos.de/it/soforthilfe/php2shell-betroffen/  
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:** se è interessato da PHP2Shell dipende da tre cose: la versione di PHP, la modalità di esecuzione e se e come è stata applicata la patch. Se non è sicuro, ci contatti subito. È stato colpito? Ci chiami. La aiutiamo. Lo chiariamo da remoto sul server stesso, non a sensazione, e chiudiamo la vulnerabilità se è aperta.

> **Agire subito:**
> **Ora non cancelli nulla e non reinstalli nulla.** Anche se vuole solo chiarire se è interessato: se il server fosse già stato attaccato, ci servono file e log invariati. [Segnali l'emergenza](https://phpsos.de/it/notfall/) e svolgeremo insieme la verifica.

## È stato colpito? Questi casi vanno nella lista di controllo

PHP2Shell sono due vulnerabilità critiche in PHP stesso (CVE-2026-109618 e CVE-2026-109619, entrambe con il punteggio massimo 9,2 secondo CVSS v4.0). Consentono di eseguire codice dannoso da remoto senza autenticazione. Possono essere interessate tutte le modalità di esecuzione: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Verifichi ciascuno di questi sistemi:

- server propri, vServer e root server con PHP
- pacchetti di hosting e server gestiti, anche se non ha accesso alla configurazione
- container e servizi di piattaforma che includono un'immagine PHP
- sistemi di test, ambienti di staging e vecchi sistemi dimenticati raggiungibili da Internet
- NAS, appliance o software di fornitori che usano PHP internamente

Il rischio sono proprio i sistemi dimenticati. Secondo Unit 42 esistono più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili, e il BSI (l'Ufficio federale tedesco per la sicurezza informatica) prevedeva uno sfruttamento rapido e su larga scala.

## Che cosa fare subito

1. **Creare un inventario.** Annoti tutti i server, i domini e i contratti di hosting su cui gira PHP e chi ne è responsabile.
2. **Accertare la versione di PHP di ogni sistema.** Sui server con `php -v`. Tenga presente che la riga di comando può usare una versione diversa da quella del web server.
3. **Chiarire la modalità di esecuzione.** PHP gira come PHP-FPM, come mod_php o tramite LiteSpeed? Con mod_php il team PHP stima il rischio più alto.
4. **Chiedere a hoster e fornitori.** Per iscritto: quale versione è in funzione, la correzione è stata applicata, tutti i processi sono stati riavviati?
5. **Conservare i log.** La stampa specializzata consiglia di conservare i log a partire dal 20/10/2026.
6. **Non aspettare a lungo.** Se un sistema è esposto e la patch non è subito possibile, il BSI raccomanda di scollegare temporaneamente il web server dalla rete.

## In concreto, come aiuta PHP SOS?

Chiariamo da remoto se è interessato, con prove a supporto.

1. **Quadro della situazione:** ci faccia descrivere il Suo inventario e ordiniamo i sistemi per raggiungibilità e rischio.
2. **Salvare e chiudere:** dove la vulnerabilità è aperta, salviamo prima lo stato e poi la chiudiamo con l'aggiornamento e il riavvio. Dove non è subito possibile, adottiamo misure provvisorie, che non sono una protezione completa.
3. **Verificare e bonificare:** controlliamo se la vulnerabilità è stata sfruttata prima della patch e, se serve, bonifichiamo. Distinguiamo con chiarezza se un server è interessato e magari già attaccato.
4. **Rafforzare e riferire:** riceve un elenco per ogni sistema: versione, modalità di esecuzione, prova della patch, punti aperti.

## Come dimostrare di essere interessati

Il solo numero di versione non basta, perché i fornitori applicano le correzioni come backport. Ubuntu 24.04, ad esempio, secondo i resoconti continua a mostrare 8.3.6 anche dopo l'aggiornamento. Tre vie sono affidabili:

| Via | Che cosa mostra | Limite |
|---|---|---|
| Confrontare la versione con i livelli di correzione | 8.5.12, 8.4.27, 8.3.36 o 8.2.35 o superiore è corretta | vale solo per le versioni originali, non per i backport |
| Test su `memory_hard_limit_percent` | `bool(false)` significa: direttiva sconosciuta, quindi interessato | da eseguire singolarmente per versione e modalità di esecuzione |
| Cercare i numeri CVE nel changelog del pacchetto | documenta i backport nelle distribuzioni | la fonte è l'archivio di sicurezza del fornitore |

Il test ha questo aspetto:

```bash
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
```

Come verificare in modo corretto versione e stato della patch è spiegato nella pagina [Verificare correttamente versione di PHP e stato della patch](https://phpsos.de/it/php2shell/php-version-pruefen/). Una panoramica dei rami è in [Quali versioni di PHP sono interessate?](https://phpsos.de/it/php2shell/betroffene-php-versionen/). Perché la visualizzazione può sembrare vecchia nonostante la patch lo spiega l'articolo [php -v mostra un numero vecchio](https://phpsos.de/it/blog/php-v-zeigt-alte-nummer/).

## Interessato e non più aggiornabile: PHP 8.1 e precedenti

Per PHP 8.1 e precedenti il progetto PHP non rilascia più aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Chi usa una di queste versioni ha di solito due strade: un fornitore con backport documentato oppure la migrazione a una versione ancora mantenuta. Esistono offerte commerciali di supporto a lungo termine; se e quando coprano PHP2Shell, il fornitore deve confermarlo per iscritto. La aiutiamo a inquadrare la situazione in [PHP 8.1 e precedenti: che cosa vale ora](https://phpsos.de/it/php2shell/php-8-1-und-aelter/) e nell'attuazione con il [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/).

## Che cosa dovrebbe inviarci

- Elenco dei Suoi server, domini e hoster
- Versione di PHP di ogni sistema, per quanto nota
- Modalità di esecuzione e web server, per quanto noti
- Indicazione se davanti c'è Cloudflare o un'altra protezione e se il server origin è raggiungibile direttamente
- Le risposte del Suo hoster, se già richieste
- Una persona di riferimento per autorizzazioni e riavvii

## Perché PHP SOS

Lavoriamo Made in Germany e da oltre 25 anni, con la nostra rete di partner di professionisti della cybersicurezza, ci specializziamo nella sicurezza informatica. Ha un unico interlocutore che passa in rassegna il Suo inventario e documenta ogni affermazione, invece di limitarsi a leggere numeri di versione. Lavoriamo da remoto, senza trasferte, e documentiamo ciò che abbiamo verificato. Un'affermazione come «sicuro» la facciamo solo nella misura in cui può essere dimostrata. Per ambienti più grandi può essere indicato il servizio [PHP2Shell: assistenza urgente](https://phpsos.de/it/leistungen/php2shell-soforthilfe/).

## È stato colpito? Ci chiami. La aiutiamo.

Se non sa se è interessato, è già un motivo sufficiente per contattarci subito. Ci chiami o ci scriva su WhatsApp. Ce ne occupiamo dal primo messaggio e lo chiariamo con Lei sul server. [Segnali subito l'emergenza](https://phpsos.de/it/notfall/).


## Domande frequenti

**Sono interessato da PHP2Shell se uso solo WordPress o uno shop?**  
Possibilmente sì. Le vulnerabilità sono in PHP, non nel CMS. Conta quale versione e quale modalità di esecuzione di PHP servono davvero le Sue pagine; un aggiornamento di WordPress non cambia nulla.

**Il numero di versione basta per sapere se sono aggiornato?**  
Non sempre. Distribuzioni e hoster applicano talvolta le correzioni come backport, e allora il numero resta lo stesso. Sono significativi il changelog del pacchetto con i numeri CVE o la conferma scritta del Suo fornitore.

**Esiste un test rapido per sapere se la mia versione di PHP contiene la correzione?**  
Secondo il manuale di PHP, una versione che non conosce la direttiva memory_hard_limit_percent è interessata. Il test va eseguito singolarmente per ogni versione di PHP e modalità di esecuzione, perché la riga di comando può usare una versione diversa da quella del web server.

**Sono interessate anche versioni di PHP più vecchie come la 7.4 o la 8.0?**  
Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4. Per la 8.1 e precedenti il progetto PHP non rilascia più aggiornamenti ufficiali, solo backport minimi del codice sorgente. Se un fornitore li abbia applicati, deve confermarlo.

**Cloudflare mi protegge se sono interessato?**  
In parte. Cloudflare ha introdotto regole di protezione, ma avverte essa stessa che non sostituiscono l'aggiornamento. Se il Suo server origin è raggiungibile direttamente, la protezione viene aggirata.

## Fonti

- [php.net: avvisi di sicurezza](https://www.php.net/)
- [Manuale di PHP: configurazione di base (ini.core)](https://www.php.net/manual/en/ini.core.php)
- [PHP: versioni supportate](https://www.php.net/supported-versions.php)
- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)