# CVE-2026-109618: RCE per condizione out-of-memory

> CVE-2026-109618 spiegata: come la condizione out-of-memory in PHP può portare all'esecuzione di codice, quali versioni sono corrette e che cosa fare subito.

Fonte: https://phpsos.de/it/php2shell/cve-2026-109618/  
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:** CVE-2026-109618 è una delle due vulnerabilità dietro PHP2Shell. Una condizione out-of-memory può interrompere PHP mentre i dati della richiesta sono inizializzati solo in parte; durante la pulizia, dati non validi possono allora essere considerati validi. Ciò consente l'esecuzione di codice senza autenticazione. L'errore è corretto in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

## Che cos'è CVE-2026-109618?

CVE-2026-109618 (identificativo GitHub GHSA-w8hw-w9fx-j79w) è una vulnerabilità di errore di memoria nel nucleo di PHP. Ha un punteggio CVSS v4.0 di 9,2. Insieme a [CVE-2026-109619](https://phpsos.de/it/php2shell/cve-2026-109619/) costituisce ciò che i media chiamano [PHP2Shell](https://phpsos.de/it/php2shell/was-ist-php2shell/).

L'effetto è una cosiddetta unauthenticated Remote Code Execution: un aggressore può eseguire codice sul web server da remoto e senza account utente. Con ciò la vulnerabilità appartiene alla classe più pericolosa di debolezze che un web server possa avere.

## Come nasce la vulnerabilità, in linea di principio

Quando PHP elabora una richiesta web, crea internamente delle strutture dati per quella richiesta, ad esempio per i dati di un modulo inviato. Se nel farlo PHP raggiunge il proprio limite di memoria, si interrompe con una condizione out-of-memory. Secondo php.net, ciò può accadere mentre i dati della richiesta sono inizializzati solo in parte.

Al termine di ogni richiesta PHP fa pulizia e libera la memoria. È proprio qui che sta l'errore: la pulizia può trattare come validi dati non validi, creati solo a metà. Da questo comportamento errato si può ricavare, a certe condizioni, l'esecuzione di codice.

Perché un errore simile è così grave? Un errore di memoria nel linguaggio di programmazione riguarda tutte le applicazioni che vi girano sopra, indipendentemente da quanto siano programmate con cura. Un'installazione WordPress curata, con plugin aggiornati, è interessata quanto un vecchio sviluppo proprio. Per questo qui non serve un aggiornamento dell'applicazione, ma solo un aggiornamento di PHP.

Ulteriori dettagli tecnici sullo sfruttamento non li pubblichiamo di proposito. Per la difesa non servono: è decisivo se il Suo server usa una versione corretta e se i nuovi processi girano davvero.

## Versioni e modalità di esecuzione interessate

| Ramo PHP | Ultimo stato prima della correzione | Corretta da |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 e precedenti | nessun aggiornamento ufficiale | solo backport minimi del codice sorgente per 7.4, 8.0, 8.1 |

Sono interessate le modalità di esecuzione PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il team PHP classifica il rischio come il più alto con mod_php. Distribuzioni e hoster applicano in parte dei backport, per cui viene mostrato un numero di versione più vecchio anche se l'errore è corretto. Sono determinanti lo stato dei pacchetti e la conferma del fornitore.

Sull'ordine di grandezza: Palo Alto Networks (Unit 42) ha contato più di 22,6 milioni di istanze esposte e potenzialmente vulnerabili. Il BSI ha dichiarato il livello di allerta 3 (arancione) e si aspettava uno sfruttamento rapido e su larga scala.

## Correggere CVE-2026-109618: aggiornamento e riavvio

L'unico rimedio completo è l'aggiornamento. Verifichi prima versione e stato dei pacchetti. I nomi dei pacchetti variano a seconda della distribuzione; gli esempi presuppongono PHP 8.3:

```bash
php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
```

Se il changelog del pacchetto cita il numero CVE, il backport è stato applicato. Se manca, ciò non significa automaticamente che il pacchetto sia vulnerabile; in tal caso aiutano il confronto con la tabella delle versioni o la richiesta al fornitore.

Dopo l'aggiornamento tutti i processi PHP vanno riavviati, ad esempio con `systemctl restart php8.3-fpm` oppure, con mod_php, con un riavvio di Apache. Come assicurarsi che non giri più nessun vecchio worker è spiegato alla pagina [Riavviare PHP-FPM e tutti i worker](https://phpsos.de/it/php2shell/php-fpm-neustart/).

## Misure provvisorie, se l'aggiornamento non è ancora possibile

php.net ha pubblicato misure provvisorie per PHP2Shell. Valgono per entrambe le vulnerabilità insieme e sono esplicitamente una protezione non completa. Il fatto che diverse di esse riguardino i limiti di memoria è coerente con la causa scatenante out-of-memory di CVE-2026-109618; non esiste però un'assegnazione ufficiale di singole misure a singole CVE.

```ini
; Esempio di pool FPM, ad es. /etc/php/8.3/fpm/pool.d/www.conf (il percorso varia a seconda della distribuzione)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M se servono upload di file
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
```

I valori devono essere impostati in modo che le applicazioni non possano sovrascriverli, quindi `php_admin_value`. Con `memory_limit=-1` il servizio ha bisogno di un limite di memoria dall'esterno, tramite container o cgroup, non tramite `RLIMIT_AS` o `RLIMIT_DATA`. Con PHP 8.5 si aggiunge `fatal_error_backtraces=0`. Tutti i dettagli sono alla pagina [Misure immediate se non può ancora applicare la patch](https://phpsos.de/it/php2shell/sofortmassnahmen-ohne-patch/).

> **Importante:**
> Se né l'aggiornamento né le misure provvisorie sono possibili subito, il BSI raccomanda di scollegare temporaneamente dalla rete i web server interessati.

## Come aiuta concretamente PHP SOS?

Con il nostro [servizio di patch PHP](https://phpsos.de/it/leistungen/php-patch-service/) chiudiamo CVE-2026-109618 in modo strutturato:

- **Rilevare lo stato attuale:** ramo PHP, modalità di esecuzione, fonte dei pacchetti e stato dei backport per ogni server.
- **Installare l'aggiornamento** dalla fonte di pacchetti adatta oppure, dove non è possibile, impostare correttamente le misure provvisorie nella configurazione del pool o del server.
- **Verificare il riavvio:** controlliamo che non giri più alcun vecchio processo PHP.
- **Conferma:** riceve una documentazione con versioni e stati dei pacchetti prima e dopo l'intervento, ad esempio per la direzione, l'assicuratore o la protezione dei dati.


## Domande frequenti

**Quanto è critica CVE-2026-109618?**  
La vulnerabilità ha un punteggio CVSS v4.0 di 9,2 ed è quindi critica. Consente l'esecuzione di codice dannoso da remoto senza autenticazione. Per PHP2Shell il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha dichiarato il livello di allerta 3 (arancione).

**Basta aumentare memory_limit?**  
No. php.net indica memory_limit=-1, impostato in modo fisso nella configurazione del server, come una delle diverse misure provvisorie. Non è esplicitamente una protezione completa e richiede un limite di memoria tramite container o cgroup. La soluzione resta l'aggiornamento.

**Quale identificativo GHSA corrisponde a CVE-2026-109618?**  
Nella GitHub Security Advisory la vulnerabilità è riportata con GHSA-w8hw-w9fx-j79w. La seconda vulnerabilità PHP2Shell, CVE-2026-109619, ha l'identificativo GHSA-6wmf-4rv5-p3rp.

## Fonti

- [php.net: bollettini di sicurezza](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Ufficio federale tedesco per la sicurezza informatica](https://www.bsi.bund.de/)