Vai al contenuto
Tutti gli articoli

· di NetProtector Security Team

PHP2Shell: vulnerabilità critiche di PHP attivamente sfruttate

Due vulnerabilità critiche nel core di PHP, denominate complessivamente „PHP2Shell“, consentono agli attaccanti di eseguire codice sui server web senza autenticazione. Dal 20 ottobre 2026 sono disponibili le patch, ma si registrano già attacchi in the wild. Chi gestisce applicazioni PHP dovrebbe intervenire subito.

Di cosa si tratta

Sono interessate le vulnerabilità CVE-2026-109618 e CVE-2026-109619, entrambe con un punteggio CVSS 4.0 di 9.2. Si tratta di errori di memoria nel core di PHP, non in una singola applicazione o in un framework:

  • CVE-2026-109618: se PHP interrompe una richiesta per mancanza di memoria, i dati della richiesta restano inizializzati solo in parte. Durante la pulizia della richiesta vengono comunque trattati come validi: un attaccante può così introdurre memoria non valida.
  • CVE-2026-109619: lo stato globale di una richiesta sopravvive al rilascio della relativa memoria. Una richiesta successiva sullo stesso worker lo legge prima che venga reimpostato (use-after-free). In questo modo è possibile anche leggere la memoria del worker, comprese password, token o chiavi API che vi si trovano in quel momento.

Sono a rischio tutte le installazioni che gestiscono richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. La facilità con cui le vulnerabilità possono essere sfruttate dipende dalla configurazione e dall'applicazione; un vettore di attacco confermato passa attraverso la funzione Session Upload Progress.

Perché è urgente

Le vulnerabilità sono diventate note prima del previsto: indicazioni circolavano nei forum prima della data di rilascio delle patch e un video con un proof of concept era stato pubblicato per errore in anticipo. Nel frattempo sono disponibili pubblicamente script di exploit e diverse aziende di sicurezza osservano uno sfruttamento attivo. PHP è in esecuzione su gran parte dei server web: di conseguenza, gli attaccanti effettuano scansioni su larga scala.

Cosa dovrebbe fare ora

  1. Aggiornare. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le distribuzioni spesso effettuano il backport delle correzioni mantenendo il vecchio numero di versione: fa fede il security advisory del Suo fornitore. PHP 8.1 e versioni precedenti non ricevono più aggiornamenti regolari; in questo caso l'unica soluzione è un upgrade.
  2. Verificare cosa è effettivamente in esecuzione. php -v dalla riga di comando non mostra necessariamente la versione utilizzata dal server web. Dopo l'aggiornamento riavvii PHP-FPM o Apache e controlli la versione dei worker in esecuzione.
  3. Adottare misure di protezione temporanee, se un aggiornamento non è immediatamente possibile (il progetto PHP sottolinea che solo l'aggiornamento chiude completamente le vulnerabilità):
    • Impostare session.upload_progress.enabled = 0 nel file php.ini o nella configurazione del pool FPM e riavviare i worker: tramite ini_set() o .user.ini non è sufficiente.
    • Con PHP 8.5, impostare inoltre fatal_error_backtraces = 0.
    • Impostare limiti restrittivi per dimensioni e upload (post_max_size, upload_max_filesize, max_file_uploads) e bloccare le richieste multipart sul reverse proxy dove non sono necessarie.
    • Ove possibile, scollegare il servizio da Internet o filtrarlo a monte.
  4. Cercare tracce di compromissione. Controlli i log del server web alla ricerca di richieste multipart e di upload sospette, nonché di crash dei worker PHP a partire da metà ottobre. Gli attacchi riusciti si manifestano spesso con nuovi file nella directory web o con connessioni in uscita insolite del server web.

La nostra valutazione

PHP2Shell è un esempio emblematico di quanto rapidamente si chiuda la finestra temporale tra la divulgazione e lo sfruttamento. Una gestione aggiornata delle patch rimane la misura più importante. A livello di rete, l'intrusion prevention aiuta a bloccare schemi di attacco noti sul perimetro, mentre l'anomaly detection rileva quando un server web stabilisce improvvisamente connessioni mai stabilite prima: un segnale tipico di una compromissione riuscita.

Fonti