php2shell (CVE-2026-109618 / 109619) non si valuta con php -v: dove i numeri di versione divergono tra FPM, Docker e distribuzioni

Se il PHP che gestisce le richieste web (PHP-FPM, mod_php di Apache, php-cgi, FrankenPHP, LiteSpeed) è precedente a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, è interessato da CVE-2026-109618 e CVE-2026-109619, noti come php2shell. La soluzione è passare a una di queste versioni (o, per i pacchetti delle distribuzioni, al pacchetto corretto) e riavviare i processi. Ciò che va verificato non è il php -v locale, ma «il PHP che serve effettivamente il web» e «la versione del pacchetto installato».

Questo articolo si concentra su quattro punti in cui giudicare solo dal numero di versione porta a conclusioni sbagliate. Tutti i dati e lo stato delle informazioni sono al 2026-10-22; le fonti di ciascuna voce sono elencate in fondo.

Cosa si sa al 2026-10-22

L'avviso di PHP afferma che «l'unica correzione completa è aggiornare». Le mitigazioni per il periodo precedente all'aggiornamento sono trattate più avanti in questo articolo.

Trappola 1: php -v e il PHP esposto sul web possono essere diversi

php -v digitato via SSH riporta la versione del PHP CLI. Le richieste web sono gestite da processi PHP-FPM o da mod_php caricato in Apache, che sono binari e pacchetti distinti. Se hai installato un PHP più recente solo per la CLI, esegui più versioni affiancate, o hai un pool FPM che punta a un'altra versione, il lato web può restare vecchio anche quando php -v mostra una versione corretta.

Ci sono diversi modi per vedere la versione reale lato web.

# FPM su Debian / Ubuntu (nome specifico per versione)
php-fpm8.3 -v

# FPM sui sistemi della famiglia RHEL
php-fpm -v

# Verifica se mod_php è caricato in Apache
apachectl -M | grep -i php

Il metodo più affidabile è far dichiarare la versione al PHP che viene effettivamente eseguito via web. Metti un file temporaneo con un nome difficile da indovinare ed eliminalo subito dopo il controllo.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Se PHP_SAPI è fpm-fcgi, PHP gira sotto FPM; apache2handler indica mod_php; cgi-fcgi indica CGI. Evita di lasciare esposto phpinfo(), perché di per sé rivela informazioni.

Il riavvio è un altro passaggio facile da dimenticare. Anche dopo la sostituzione del pacchetto, i processi php-fpm o Apache già in esecuzione possono continuare a eseguire il vecchio codice. Alcune configurazioni riavviano automaticamente all'aggiornamento dei pacchetti, altre no. Dopo l'aggiornamento, riavvia FPM / Apache e controlla di nuovo la versione lato web con i metodi sopra.

Trappola 2: con Docker non si può giudicare dal nome del tag

L'immagine ufficiale php ha «tag mobili» come 8.3 e 8.3-fpm, il cui contenuto viene sostituito, e tag fissati come 8.3.30, che bloccano la versione.

• Anche dopo che un tag mobile è stato aggiornato a una versione corretta su Docker Hub, la tua copia locale resta la vecchia immagine finché non esegui di nuovo il pull. Anche i container in esecuzione continuano a usare la vecchia immagine finché non vengono ricreati. Un Dockerfile con FROM php:8.3-fpm verrà comunque costruito sulla vecchia base se questa è rimasta nella cache di build.
• Un tag fissato resta vecchio per sempre finché non aggiorni tu il numero.

Puoi verificare se i tag delle versioni corrette sono stati pubblicati usando l'API di Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Ecco i risultati dell'interrogazione di quattro linee di rilascio il 2026-10-22 (orari in UTC).

Da questa verifica sono emersi tre punti in cui giudicare dai numeri può trarre in inganno.

1. «Aggiornato di recente» non significa «corretto». Il tag fissato 8.3.35 è stato ricostruito durante il 2026-10-21, ma la PHP_VERSION al suo interno era ancora 8.3.35. Guarda la versione interna, non la data di aggiornamento.
2. Digest diversi possono avere lo stesso contenuto. 8.3 e 8.3.36 avevano digest di tag diversi (il valore dell'indice multi-architettura), ma l'immagine amd64 era identica ed entrambe avevano PHP_VERSION=8.3.36. Allo stesso modo, per 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm e 8.2-fpm, la PHP_VERSION dell'immagine amd64 era una versione corretta.
3. Non esistono immagini ufficiali corrette per 8.1 e precedenti. 8.1-fpm è stata aggiornata l'ultima volta il 2025-12-31.

Per controllare le immagini locali e i container in esecuzione:

# Versione di PHP di un'immagine scaricata in locale
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Esegui di nuovo il pull e ricrea i container
docker compose pull
docker compose up -d

# Se costruisci una tua immagine, rifai il pull della base e poi esegui la build
docker compose build --pull

# Versione dentro un container in esecuzione
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Sostituisci app nell'ultimo comando con il nome del tuo servizio. Ogni immagine ufficiale è costruita con una singola PHP_VERSION, quindi la versione CLI dentro un container coincide con la versione FPM / Apache di quel container (la Trappola 1 vale quando PHP è installato direttamente sull'host).

FrankenPHP incorpora PHP, quindi la versione di FrankenPHP e quella del PHP incorporato sono numeri diversi. Le note di rilascio di FrankenPHP 1.13.2, rilasciato il 2026-10-21, indicano che le immagini Docker sono state costruite con PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 e i binari statici con PHP 8.5.12.

Trappola 3: i pacchetti delle distribuzioni sono «corretti con numeri vecchi»

Ubuntu e RHEL portano sulle versioni più vecchie solo le correzioni (backporting). Il numero mostrato da php -v resta vecchio, quindi un controllo numerico come «inferiore a 8.3.36, quindi vulnerabile» segnala come vulnerabile un sistema già corretto. Al contrario, nemmeno per stare tranquilli ci si può affidare al numero. Decidi in base alla versione del pacchetto e al security tracker di ciascuna distribuzione.

Pacchetti corretti elencati in ciascun tracker al 2026-10-22 (gli stessi per entrambe le CVE):

Questa tabella mostra direttamente perché i soli numeri non bastano. Il PHP corretto di Ubuntu 24.04 è una versione che inizia con 8.3.6, molto più bassa della 8.3.36 di upstream. Il PHP predefinito di RHEL 9 è corretto pur restando alla 8.0.30, anche se upstream non rilascia più correzioni per la 8.0. Debian è passata agli stessi numeri di upstream (8.2.35 / 8.4.27).

Alcuni pacchetti non sono ancora corretti (al 2026-10-22).

• Il modulo php 8.4 di RHEL 9 è indicato come «affected, no fix» (interessato, nessuna correzione).
• Debian forky (testing) ha php8.4 8.4.26-1, contrassegnato come «vulnerable». Il php8.4 di sid (unstable) è 8.4.27-1 e corretto.

Esempi di comandi per verificare il tuo server:

# Debian / Ubuntu: versione installata e versione disponibile
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: se questa CVE è corretta su questo server
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Famiglia RHEL: se esiste un aggiornamento che corregge questa CVE, e la versione installata
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Adatta il nome del pacchetto (php8.3-fpm, ecc.) al tuo ambiente. Confronta la versione mostrata con la «versione corretta» della tabella sopra o del tracker: se è uguale o superiore, la correzione è presente. Poi completa il riavvio e il controllo lato web descritti nella Trappola 1.

Se installi PHP da un repository di terze parti anziché dai pacchetti della distribuzione, devi seguire gli aggiornamenti di quel repository. L'avviso di PHP osserva che rpms.remirepo.net, gestito da volontari, non avrebbe avuto aggiornamenti il giorno della divulgazione, e raccomanda di passare ai pacchetti della distribuzione o a build proprie.

Trappola 4: su hosting condiviso e ambienti gestiti non puoi aggiornare PHP da solo

Su hosting condiviso e ambienti PHP gestiti, è il fornitore a sostituire il runtime PHP. Anche qui il solo numero non basta: se il fornitore compila PHP in proprio o fa il backport delle correzioni, il numero di versione può restare vecchio.

Ci sono tre cose che puoi fare da solo.

1. Verifica la versione lato web. Usa il file temporaneo della Trappola 1 per stampare PHP_VERSION e PHP_SAPI, poi eliminalo subito. Se il pannello di controllo ha un selettore della versione di PHP, annota anche quale versione hai selezionato.
2. Leggi l'avviso del fornitore e, se non c'è, chiedi. Chiedi: «Per quali versioni di PHP del mio piano verranno applicate le correzioni per CVE-2026-109618 e CVE-2026-109619, e quando (o sono già state applicate)?» Chiedere per numero di CVE anziché per numero di versione ti porta una risposta che comprende anche i backport.
3. Se hai selezionato una versione non più supportata, aggiorna. Il progetto PHP non rilascia correzioni per 8.1 e precedenti, e il supporto per 8.2 termina il 2026-12-31. A meno che il fornitore non abbia fatto il backport delle correzioni, cambiare versione è la strada sicura.

Stato per fornitore di hosting (al 2026-10-22)

Sugli hosting condivisi, di norma è il fornitore ad aggiornare il runtime PHP, e gli avvisi di molti fornitori dicono che «non è richiesta alcuna azione da parte degli utenti». Gli utenti hanno due cose da fare: controllare l'avviso ufficiale del proprio fornitore e, se nel pannello di controllo hanno selezionato una vecchia versione di PHP, valutare se passare alla versione raccomandata dall'avviso (una con una release corretta).

La tabella seguente riassume solo ciò che è scritto nelle pagine ufficiali di ciascun fornitore (annunci e informazioni di manutenzione), parafrasando il testo degli avvisi. Gli avvisi vengono aggiornati man mano che le cose procedono, quindi verifica sempre lo stato reale sulla pagina ufficiale citata.

Dove non sono riuscito a trovare o ad aprire un avviso ufficiale, la tabella dice «non è stato possibile confermare» o «non trovato». L'assenza di informazioni non significa che il fornitore non abbia agito. Verifica direttamente negli annunci e nel supporto del tuo fornitore.

Mitigazioni finché non puoi aggiornare subito

L'avviso di PHP elenca impostazioni che riducono la superficie d'attacco fino al momento dell'aggiornamento. Tuttavia l'avviso stesso afferma esplicitamente che «non rendono sicuri». Le principali sono:

• Per CVE-2026-109619: imposta session.upload_progress.enabled=0 in php.ini, nel pool FPM o nella configurazione del server, e riavvia tutti i worker (ini_set() e il .user.ini di FPM non funzionano per questo scopo). Su PHP 8.5, imposta anche fatal_error_backtraces=0.
• Per CVE-2026-109618: imposta memory_limit=-1 in modo che l'applicazione non possa sovrascriverlo, e riduci post_max_size (8M se non ci sono upload, 32M se ci sono). Non usare RLIMIT_AS / RLIMIT_DATA come sostituto.

L'NCSC britannico raccomanda di valutare la messa offline di qualsiasi sistema che non possa essere aggiornato o mitigato subito, e di cercare segni di compromissione prima di aggiornare o applicare le mitigazioni.

Fonti (verificate il 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: annunci di rilascio di PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: immagine ufficiale php
• Note di rilascio di FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (versioni dei pacchetti corretti dai dati VEX di Red Hat)
• NCSC: Critical security issue affecting PHP