In breve: FrankenPHP è un application server basato su Caddy che incorpora PHP nel proprio programma. Per la sicurezza di FrankenPHP dopo PHP2Shell significa: non contano i pacchetti PHP della distribuzione, ma la versione di PHP nel binario di FrankenPHP o nell'immagine del container. Compili o scarichi una versione con PHP corretto e riavvii tutti i worker.
Perché FrankenPHP si aggiorna in modo diverso
Nelle configurazioni classiche la distribuzione fornisce PHP come pacchetto e un aggiornamento sostituisce i file. FrankenPHP invece contiene PHP come libreria incorporata. Chi usa il binario ufficiale o un'immagine container basata su di esso riceve PHP già incluso. Un apt upgrade sull'host non cambia nulla in proposito.
PHP2Shell comprende CVE-2026-109618 e CVE-2026-109619, entrambe con CVSS v4.0 9.2. Il progetto PHP elenca espressamente FrankenPHP tra le modalità di esecuzione interessate. Sono corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Decisivo è quindi con quale versione di PHP è stato compilato il Suo FrankenPHP.
Modalità worker e PHP2Shell
FrankenPHP può far girare le applicazioni in modalità worker. L'applicazione viene caricata una sola volta e poi elabora molte richieste di seguito nello stesso processo. Questo porta velocità, ma allunga la vita di ogni processo.
CVE-2026-109619 descrive uno stato interno di una richiesta che può persistere dopo il rilascio della memoria; una richiesta successiva nello stesso worker può usarlo prima che venga reimpostato. Nella modalità worker l'interazione di molte richieste in un solo processo è la norma. Non è un motivo per rinunciare alla modalità worker, ma è un chiaro motivo per eseguire aggiornamenti e riavvii con particolare cura. I dettagli tecnici si trovano alla pagina CVE-2026-109619.
Sicurezza FrankenPHP: verificare la versione
Verifichi la versione di PHP incorporata direttamente nel sistema in esecuzione. I comandi seguenti leggono soltanto; i nomi di servizi e container sono esempi.
# Binario installato
frankenphp version
# Nel container in esecuzione (nome del container a titolo di esempio)
docker exec app frankenphp version
docker exec app php -v
# Quale immagine gira davvero? (il digest mostra lo stato esatto)
docker inspect --format '{{.Image}} {{.Config.Image}}' app
Annoti la versione di PHP dall'output. Se è precedente agli stati corretti, il sistema è vulnerabile. Controlli sempre il container in esecuzione, non solo l'immagine costruita per ultima, perché una nuova immagine ha effetto solo dopo la sostituzione dei container.
Installare l'aggiornamento e riavviare tutti i worker
Come si presenta l'aggiornamento dipende dalla Sua installazione:
- Binario sull'host: installare la nuova release di FrankenPHP con la versione di PHP corretta, riavviare il servizio.
- Container: ottenere l'immagine di base con la versione di PHP corretta, ricostruire la propria immagine senza cache per il livello di base, sostituire i container.
- Compilato in proprio: ricompilare con la versione di PHP corretta, rigenerare tutte le estensioni con la stessa versione.
# Esempio di installazione sull'host come servizio systemd
systemctl restart frankenphp
# Esempio Docker Compose: ricostruire senza cache e sostituire i container
docker compose build --pull --no-cache
docker compose up -d --force-recreate
Poi verifichi di nuovo la versione di PHP nel container in esecuzione e l'orario di avvio dei processi. Nella modalità worker ogni worker deve essere stato riavviato. Con Kubernetes valgono passaggi aggiuntivi, descritti alla pagina Aggiornare PHP in Kubernetes, per i container in generale alla pagina Aggiornare PHP nei container Docker.
Un tag come latest o una versione principale nel nome dell'immagine non garantisce di avere lo stato più recente. Scarichi attivamente di nuovo l'immagine di base e verifichi poi la versione di PHP nel container in esecuzione.
Misure transitorie e hardening
Se l'aggiornamento non può avvenire subito, php.net raccomanda misure transitorie che non offrono una protezione completa. Con FrankenPHP imposti i valori nel php.ini che FrankenPHP carica, oppure tramite le impostazioni PHP nella configurazione di Caddy, non tramite ini_set() nell'applicazione.
; php.ini nel container o sull'host
session.upload_progress.enabled = 0
post_max_size = 8M
upload_max_filesize = 6M
Con la funzione di upload, php.net indica post_max_size = 32M. Su PHP 8.5 si aggiunge fatal_error_backtraces=0. Il limite di memoria va impostato a livello di container, ad esempio con il limite di memoria del container, non tramite RLIMIT_AS o RLIMIT_DATA. Dopo ogni modifica riavvii tutti i worker.
Per l'esercizio continuativo vale la pena fare riferimento a immagini con digest fisso, ricostruirle regolarmente in modo automatizzato e inserire uno scanner di immagini nella catena di build. Una patch inoltre non rimuove il malware introdotto in precedenza. Conservi i log a partire dal 20/10/2026; per i container significa salvarli prima della sostituzione.
Chi usa FrankenPHP come binario compilato in modo statico dovrebbe sapere che lì, oltre a PHP, sono integrate stabilmente anche tutte le estensioni. Un aggiornamento significa quindi sempre sostituire l'intero binario. Dopo la sostituzione verifichi la versione e l'elenco delle estensioni caricate, per controllare che tutto sia disponibile come prima, e testi l'applicazione prima di scartare lo stato precedente. Negli ambienti container si raccomanda di contrassegnare ogni immagine con la data della build. Così può ricostruire in qualsiasi momento quale stato girava e quando e, in caso di dubbio, tornare indietro in modo mirato, senza ricadere di nuovo su uno stato vulnerabile. Annoti nella Sua documentazione l'associazione di immagine, versione di PHP e momento.
Come aiuta concretamente PHP SOS?
- Verifichiamo quale versione di PHP si trovi effettivamente nei Suoi binari FrankenPHP e nei container in esecuzione.
- Tramite il servizio di patch PHP ricostruiamo le immagini, sostituiamo i container e riavviamo tutti i worker, con prova.
- Salviamo i log prima della sostituzione e verifichiamo l'applicazione alla ricerca di tracce.
- Per l'esercizio continuativo predisponiamo ricostruzioni automatizzate e controlli delle immagini nell'ambito dell'hardening dei server.
Domande frequenti
Un aggiornamento apt o dnf aiuta con FrankenPHP?
Solo se FrankenPHP stesso proviene da queste fonti di pacchetti ed è compilato con il PHP corretto. Spesso PHP è integrato stabilmente nel binario di FrankenPHP o nell'immagine del container. In tal caso deve aggiornare il binario o l'immagine.
Perché la modalità worker è particolarmente importante con PHP2Shell?
Nella modalità worker l'applicazione resta in memoria ed elabora molte richieste una dopo l'altra nello stesso processo. CVE-2026-109619 riguarda proprio lo stato interno che può persistere tra le richieste nello stesso worker. Dopo l'aggiornamento il riavvio di tutti i worker è quindi obbligatorio.
Come verifico quale versione di PHP c'è in FrankenPHP?
Il binario di FrankenPHP, richiamato con la versione, restituisce la versione di PHP incorporata. Nel container può eseguire il comando tramite docker exec. Faccia attenzione a controllare la versione nel container effettivamente in esecuzione, non nell'immagine appena ricostruita.
Esistono misure transitorie specifiche per FrankenPHP?
Valgono le indicazioni generali di php.net. Imposti i valori nel php.ini che FrankenPHP carica, oppure nella configurazione PHP del file Caddy, non tramite ini_set() nell'applicazione. Poi riavvii tutti i worker.