Protezione proattiva di Fastly contro PHP2Shell e le vulnerabilità critiche RCE di PHP CVE-2026-109618 e CVE-2026-109619

PHP, il runtime alla base della maggior parte dei sistemi di gestione dei contenuti, delle piattaforme di e-commerce e dell’infrastruttura di pubblicazione del web, è perseguitato dai fantasmi del passato: una scelta progettuale risalente a decenni fa che ha causato un difetto nel modo in cui il suo motore gestisce gli errori irreversibili. Le vulnerabilità divulgate oggi, denominate php2shell, hanno origine da questa scelta progettuale, di cui parleremo nel post.

La PHP Foundation ha assegnato due identificativi CVE (CVE-2026-109618, CVE-2026-109619) e le vulnerabilità sono state corrette in PHP 8.2 e versioni successive (le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35). PHP ha pubblicato anche patch per le versioni 7.4, 8.0 e 8.1, destinate all’integrazione da parte dei distributori di pacchetti. Le versioni precedenti alla 7.4 non riceveranno una patch da PHP e potranno essere corrette a discrezione dei distributori di pacchetti. Sono interessate tutte le versioni di PHP ancora supportate. Al momento, il percorso di exploit più risalente tra quelli dimostrati è presente dal 2012. 

Esistono prove di attacchi attivi in ambienti reali già prima della divulgazione; non si tratta di problemi teorici.

Raccomandiamo vivamente ai clienti di individuare nel proprio ambiente tutti i server applicazione che utilizzano mod_php o php-fpm e di applicare le patch con urgenza. Se non è possibile applicare le patch in alcun modo, consigliamo di adottare misure di mitigazione attive. 

Al momento, data la natura di questi exploit, che includono l’ esecuzione di codice da remoto prima dell’autenticazione, è opportuno presumere che una mitigazione attiva offrirà solo una protezione “partial” e che, a seconda dell’approccio adottato, potrebbe richiedere il blocco di una parte considerevole del traffico legittimo.

Siamo grati per la stretta collaborazione con OpenAI e con gli altri partner dell’ecosistema software che hanno contribuito a questo intervento urgente per proteggere il maggior numero possibile di organizzazioni. 

In questo post spiegheremo più nel dettaglio le vulnerabilità, descriveremo come questi exploit di PHP potrebbero avere un impatto sulla tua azienda e offriremo indicazioni per mitigare i tentativi di sfruttamento.

CVE-2026-109618 e CVE-2026-109619 in breve

Quando PHP raggiunge un limite di memoria, supera il tempo massimo di esecuzione o perde una connessione, non interrompe le operazioni in modo ordinato. Abbandona l’operazione in corso e passa a un punto di ripristino, lasciando lo stato interno parzialmente modificato. Lo stato residuo può contenere riferimenti a memoria già liberata o strutture di dati che non si è mai finito di costruire.

I ricercatori hanno dimostrato che un hacker può attivare queste condizioni di errore con una sola richiesta HTTP non autenticata. L’hacker può riuscirci senza effettuare l’accesso, senza un endpoint speciale e senza alcuna cooperazione da parte dell’applicazione. La vulnerabilità RCE consente all’hacker il controllo del contenuto dello stato residuo con una precisione sufficiente a indurre PHP a eseguire comandi shell arbitrari con l’identità dell’utente del sistema operativo apparentemente legittimo del server web. Il processo worker sopravvive e continua a gestire le richieste, ignaro di essere ora sotto il controllo dell’hacker.

L’unica voce nel log è un normale errore di memoria esaurita. Si prospettano tempi movimentati, per usare un eufemismo.

È difficile sopravvalutare il potenziale impatto:

• Portata: qualsiasi organizzazione con applicazioni PHP

• Gravità: l’hacker può fare ciò che vuole nell’applicazione

Poiché potresti utilizzare una configurazione PHP che include, a tua insaputa, mod_php o php-fpm, raccomandiamo vivamente ai clienti di considerare potenzialmente vulnerabile qualsiasi applicazione PHP e di esaminare di conseguenza il proprio ambiente.

Un aspetto rassicurante: affinché un attacco porti all’esecuzione di codice su x86_64, i POC esistenti richiedono di conoscere lo specifico binario PHP in esecuzione e la disposizione dello spazio degli indirizzi sul server. La maggior parte delle distribuzioni potrebbe quindi essere “al sicuro” dalla RCE. Non dare per scontato che questo valga anche nel tuo caso. Se gestisci un’applicazione PHP a 32 bit, è probabilmente opportuno presumere che sia stata compromessa. 

Approfondimento: il problema di progettazione a livello del motore

Il motore PHP gestisce gli errori irreversibili in modo insolito. Se qualcosa va molto storto, le funzioni che stavano eseguendo un’operazione non ricevono alcuna notifica né hanno la possibilità di ripristinare lo stato precedente. Il lavoro rimasto a metà resta esattamente nello stato in cui è stato lasciato. Più precisamente, il motore utilizza un meccanismo chiamato longjmp(), che trasferisce direttamente l’esecuzione a un punto di gestione dell’errore, per così dire prendendo l’applicazione per il bavero, anziché effettuare il logging di un errore e terminare immediatamente l’esecuzione.

Il motore di PHP richiama questo meccanismo, chiamato zend_bailout, da ogni percorso di codice che impone un limite alle risorse o gestisce una condizione fatale (e i percorsi di questo tipo sono molti). Quando l’applicazione esaurisce la memoria o si verificano timeout di esecuzione, interruzioni delle connessioni client o errori fatali non intercettati, tutti questi casi vengono gestiti tramite zend_bailout.

Questo approccio creativo sarebbe gestibile se si verificasse di rado o in circostanze controllate. Come sa bene chiunque abbia abbastanza esperienza da aver provato le gioie dello sviluppo in PHP, questi errori irreversibili si verificano regolarmente nelle distribuzioni PHP in produzione e, cosa ancora più importante, queste condizioni attirano gli hacker che vorrebbero avere il pieno controllo del World Wide Web (ovvero di tutti i server applicazione che oggi eseguono PHP).

Cosa porta allo sfruttamento?

Quando viene attivato zend_bailout, qualsiasi operazione interna di PHP impegnata a modificare una struttura di dati la lascia in uno stato incoerente, che non soddisfa le condizioni previste dall’operazione. Il codice di pulizia di PHP, eseguito dopo ogni richiesta per eliminare lo stato della richiesta stessa, incontra quindi quei dati incoerenti e li tratta come se fossero validi.

I POC pubblicati vanno considerati esempi illustrativi: sono ben lontani dal rappresentare l’intera varietà dei percorsi di interruzione e uscita anticipata che potrebbero innescare condizioni simili che gli hacker possono exploit. Per chiarire perché questo rappresenti un problema per Internet: il codice sorgente di PHP richiama il meccanismo zend_bailout in molti punti; ognuno può interrompere un insieme diverso di operazioni in corso e ha le proprie invarianti al momento dell’interruzione.

Le combinazioni possibili sono, per usare un eufemismo, enormi. Applicare patch ai percorsi specifici mostrati dai ricercatori non rende sicuro il meccanismo. Considerato il ritorno sull’investimento offerto da questa vulnerabilità, gli hacker saranno fortemente motivati a trovare il prossimo percorso ancora sconosciuto per proseguire la loro serie di exploit.

È lecito aspettarsi che sia le organizzazioni criminali informatiche sia gli Stati sfruttino questa opportunità: questa primitiva è potente se combinata con una fuga di informazioni, che non deve nemmeno essere particolarmente sofisticata... Il bug che causa la fuga di informazioni può mandare in crash il processo ed essere comunque considerato valido grazie all’architettura prefork di mod_php. «Come gestire un errore irreversibile in sicurezza» è un argomento per un’altra volta.

Perché l’impatto è così elevato?

Ecco cosa potrebbe ottenere un hacker riuscendo a eseguire codice da remoto su un server PHP:

• Rendere indisponibili siti web e applicazioni basati su PHP con una sola richiesta non autenticata; su larga scala, questo si traduce in un’interruzione prolungata del servizio (purché i contenuti non siano nella cache)

• Eseguire qualsiasi comando sul server senza causare interruzioni visibili; il server accetta senza problemi l’input degli hacker

• Rubare tutte le credenziali utilizzate dall’applicazione: password dei database, chiavi API, chiavi del provider cloud e chiavi di crittografia

• Accedere ai database, ai sistemi di cache, alle code di messaggi e ai sistemi interni protetti da quelle credenziali: dati dei cliente, transazioni, informazioni di identificazione personale e qualsiasi altro sistema con cui l’applicazione comunica; ciò può far scattare obblighi di notifica delle breach dei dati e altri obblighi normativi

• Penetrare più a fondo nella rete: spostarsi attraverso l’infrastruttura cloud, i token degli account di servizio Kubernetes, Envoy, le chiavi SSH presenti sul disco e i servizi interni, dato che il server web si trova già all’interno dell’ambiente attendibile

• Ottenere un accesso persistente che sopravviva ai riavvii e alle nuove distribuzioni del server (l’equivalente di una comoda sedia a sdraio per l’hacker, sotto forma di backdoor nei file PHP o cron job nascosti)

• Nessun indizio evidente: l’unica voce nel log è un comune errore di memoria che i team delle operazioni vedono regolarmente e su cui raramente indagano (salvo SRE eccezionalmente curiosi)

La catena di conseguenze può essere grave in diversi casi d’uso. Consideriamo un tipico storefront: una richiesta HTTP → compromissione del server → installazione di uno skimmer persistente → furto continuativo e su larga scala dei dati delle carte dell’intera clienti → breach del Payment Card Industry Data Security Standard → potenziale perdita della possibilità stessa di elaborare pagamenti con carta.

Come determinare l’esposizione

Invitiamo i clienti a considerare potenzialmente vulnerabile qualsiasi applicazione PHP e a verificare di conseguenza il proprio ambiente di produzione. Non è il momento di prendere scorciatoie nell’analisi delle vulnerabilità; inizia subito a fare l’inventario. Per determinare l’esposizione in modo più specifico, verifica i seguenti criteri:

• PHP dietro Apache mod_php in modalità prefork

• Un rapporto tra memory_limit e post_max_size che consente a un hacker di provocare un errore OOM tramite il corpo di una richiesta POST

• Le varianti di Denial of Service (Denial of Service), che causano arresti anomali senza esecuzione di codice, interessano una gamma più ampia di configurazioni, tra cui php-fpm

Tra i settori che riteniamo possano essere particolarmente vulnerabili a questi attacchi figurano:

• E-commerce (piattaforme di commercio online) | post_max_size è spesso impostato su un valore superiore a quello predefinito per consentire il caricamento di file

• Media & editoria (sistemi di gestione dei contenuti) | enorme superficie di attacco costituita da istanze standard di Apache mod_php con configurazioni predefinite (o quasi)

• Istruzione (piattaforme di apprendimento, portali personalizzati per gli studenti, strumenti per il personale docente) | la presenza di PHP nell’istruzione superiore è notevole e spesso è gestita da team con risorse limitate

• Ospitalità e viaggi (sistemi di prenotazione, piattaforme di fidelizzazione, sistemi di gestione delle strutture ricettive) | le applicazioni PHP personalizzate su stack LAMP spesso prevedono limiti elevati per il caricamento di foto e documenti

• Servizi finanziari (integrazioni di pagamento, portali per le richieste di prestito, richieste di risarcimento assicurativo) | valore di post_max_size elevato a causa di flussi di lavoro con molti documenti; PHP è il COBOL delle applicazioni rivolte ai clienti

• SaaS (strumenti di amministrazione interni, dashboard per l’assistenza clienti, framework web) | spesso meno monitorati e gestiti da piccoli team di PMI

• Provider di hosting gestito e condiviso (pannelli di controllo per l’hosting web, ambienti Apache multi-tenant) | impatto amplificato se una configurazione PHP vulnerabile è presente su un server condiviso

• Sanità (portali per i pazienti, sistemi di prenotazione, integrazioni di dati sanitari) | il caricamento di documenti sensibili, come risultati di analisi, moduli di richiesta di visite specialistiche e tessere assicurative, richiede un valore più elevato per post_max_size

Come ottenere una protezione attiva ora

Per mitigare il rischio per le applicazioni protette da NGWAF, i clienti Fastly possono abilitare il segnale che copre sia CVE-2026-109618 sia CVE-2026-109619. Il contenuto di rilevamento di questa Regola Template specifica per CVE cerca le caratteristiche strutturali di questi tentativi di sfruttamento, ovvero corpi e parametri delle richieste strutturati in modo diverso da quelli del traffico legittimo, che potrebbero indicare potenziali tentativi di sfruttamento delle CVE php2shell.

Il team di ricerca sulla sicurezza di Fastly ha sviluppato e testato questi contenuti in stretta collaborazione con OpenAI e con i partner della comunità; siamo grati per questa collaborazione. Il nostro team di ricerca sulla sicurezza aggiornerà la patch virtuale secondo necessità; chiunque abbia aderito riceverà automaticamente gli aggiornamenti successivi. 

Fastly continuerà a studiare ulteriori livelli di difesa da offrire ai nostri clienti per rilevare e bloccare il traffico di attacco legato a php2shell. Continueremo a sviluppare e perfezionare i contenuti NGWAF pertinenti man mano che rileviamo tentativi di sfruttamento.

Segnali e indizi da esaminare

Per mitigare il bug più semplice relativo all’avanzamento dei caricamenti, assicurati che nel file php.ini sia impostato session.upload_progress.enabled = Off. 

Per la vulnerabilità più grave legata a zend_bailout, i principali schemi emersi finora dall’exploit e dal traffico della Proof of Concept includono:

Ridurre la superficie di attacco tramite la configurazione di PHP

• post_max_size = 8M: mantiene i corpi delle richieste POST al di sotto della soglia necessaria per provocare l’esaurimento della memoria con una singola richiesta. Esegui test su ogni flusso di lavoro che accetta il caricamento di file o l’invio di moduli di grandi dimensioni; 8M è il valore predefinito di PHP, ma in molte distribuzioni in produzione è stato aumentato.

• max_input_nesting_level = 4: limita i nomi delle variabili con molti livelli di annidamento, utilizzati nel payload dell’exploit della tabella hash. Porta il valore a 6 se l’applicazione usa strutture di moduli annidate complesse. Verifica l’invio di moduli che usano nomi di campo in formato array.

• session.upload_progress.enabled = 0: disabilita la funzionalità di monitoraggio dell’avanzamento dei caricamenti che attiva i percorsi di exploit legati alle sessioni. Influisce solo sulle applicazioni che mostrano barre di avanzamento dei caricamenti in tempo reale tramite il meccanismo di sessione integrato di PHP. La maggior parte delle applicazioni che mostrano l’avanzamento dei caricamenti usa invece soluzioni basate su JavaScript.

Nel traffico HTTP (tramite web application firewall, proxy o ispezione della rete)

• Invio di moduli di dimensioni eccessive. Corpi delle richieste POST in formato application/x-www-form-urlencoded di dimensioni superiori a 1–2 MB. I moduli inviati legittimamente hanno quasi sempre dimensioni inferiori a 100 KB. I moduli con codifica URL di diversi megabyte sono abbastanza rari da giustificare un’indagine su qualsiasi endpoint che esegue PHP.

• Nomi di campo vuoti con annidamento profondo. Corpi di richieste POST che iniziano con = (un campo senza nome), seguito da un nome di campo contenente caratteri [ ripetuti. Questa è la struttura specifica del payload dell’exploit della tabella hash.

• Nomi dei campi per l’avanzamento dei caricamenti. Caricamenti di file multipart contenenti un campo denominato PHP_SESSION_UPLOAD_PROGRESS. Si tratta di una funzionalità legittima di PHP, ma è anche l’elemento che attiva i percorsi di exploit legati alle sessioni. Segnalalo per una verifica negli endpoint che non usano il monitoraggio dell’avanzamento dei caricamenti.

Nei log degli errori dell’applicazione e del server web

• Errori OOM nei componenti interni di PHP, non nel codice dell’applicazione. Cerca Allowed memory size ... exhausted con Unknown come posizione e line 0 come numero di riga. Il file Unknown e la riga 0 indicano che l’errore si è verificato mentre PHP analizzava la richiesta, prima che venisse eseguito qualsiasi script dell’applicazione. Un errore OOM nel codice dell’applicazione indicherebbe invece un file e un numero di riga effettivi.

• Raffiche di errori di segmentazione. Cluster di voci Apache AH00052 ... exit signal Segmentation fault (11) concentrate in un breve intervallo di tempo. Qualche errore di segmentazione isolato non è insolito; decine di errori nell’arco di pochi minuti, seguiti da una singola risposta HTTP 200 lenta, corrispondono alla fase dell’exploit in cui l’indirizzo viene individuato mediante forza bruta.

Monitoraggio dei processi (a livello di host)

• Processi worker Apache/PHP che avviano processi shell. Qualsiasi processo worker mod_php che esegue /bin/sh -c ... come processo figlio. In condizioni di operazione normali, i processi worker mod_php non avviano mai processi figli, a meno che l’applicazione PHP non richiami esplicitamente una funzione di esecuzione dei comandi (exec, system, shell_exec, ecc.). Se non è stato eseguito codice dell’applicazione (con gli exploit attualmente noti non ne viene eseguito), considera l’avvio di una shell da parte di un processo worker PHP come l’attivazione del payload di esecuzione del codice.

Per le distribuzioni PHP-FPM

• pm.max_requests = 50: impone il riavvio dei processi worker dopo 50 richieste, ponendo un limite al periodo durante il quale è possibile sfruttare la corruzione tra richieste (i bug relativi alla sessione e alla conversione dei dati). Non impedisce il bug della tabella hash, che exploit il danneggiamento dei dati all’interno di una singola richiesta. Un valore pari a 1 impedirebbe del tutto gli attacchi tra richieste diverse, ma con un grave impatto sulle prestazioni.

Cosa succederà ora?

Sappiamo che i nostri clienti ci affidano la resilienza dei loro servizi critici per il business e che un elemento centrale della missione della nostra azienda è supportarti quando emergono imprevisti come CVE-2026-109618 e CVE-2026-109619. I nostri team sono a disposizione per supportarti nella mitigazione continua di php2shell, che tu sia un cliente di lunga data della piattaforma Fastly o un nuovo cliente che necessita di protezione immediata. Facci sapere come possiamo aiutarti.

Ricapitolando:

• Il meccanismo sfruttato per gli attacchi, ovvero zend_bailout che richiama longjmp() per abbandonare le operazioni in corso, è presente in tutta la codebase e può essere attivato tramite normale traffico HTTP. 

• Applica rapidamente le patch e tieni presente che riguardano solo i bug individuati e sfruttati fino a oggi. 

• Aspettati la comparsa di attacchi reali e nuove varianti almeno questa settimana e la prossima. 

• La condizione architetturale che le ha rese possibili è una caratteristica fondamentale del modo in cui il motore è progettato per gestire gli errori, non un «difetto» circoscritto nel codice, e rimarrà anche dopo il rilascio di queste patch.

Siamo grati di poter contribuire a questo impegno collettivo per proteggere Internet nel suo complesso. Ci impegniamo a continuare a collaborare man mano che gli attacchi evolvono: vogliamo che i nostri clienti e l’intero ecosistema software possano agire rapidamente e rimanere al sicuro. 

Per contribuire a mantenere la resilienza di Internet nel suo complesso e la collaborazione nell’ecosistema, Fastly monitorerà in modo proattivo la propria rete globale alla ricerca di tentativi di sfruttamento di php2shell e fornirà aggiornamenti successivi sulle attività osservate, analogamente agli approfondimenti pubblicati durante gli incidenti React2Shell e Log4Shell. Se hai bisogno di assistenza, non esitare a contattarci. Rimani sintonizzato.