schermo del laptop che visualizza codice colorato

Patch PHP CVE 2026 109618 per Forge Ubuntu (PHP2Shell)


Avvertenza: l'utilizzo è a proprio rischio. Questo articolo descrive la configurazione che ha funzionato sui nostri server Ubuntu gestiti con Laravel Forge. La tua configurazione potrebbe essere diversa. Ogni comando riportato di seguito modifica i pacchetti su un server di produzione, quindi esegui prima uno snapshot o un backup, prova su un server di staging se possibile e leggi attentamente ogni comando prima di eseguirlo. Non forniamo alcuna garanzia e non ci assumiamo alcuna responsabilità per eventuali danni, tempi di inattività o perdita di dati.

Ultimo aggiornamento: 22 ottobre 2026.

Quello che è successo

Il 21 ottobre 2026 il progetto PHP ha rilasciato PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Queste versioni correggono due vulnerabilità critiche che possono consentire esecuzione di codice remoto senza autenticazione. Il team di sicurezza di PHP ha assegnato a entrambe le versioni un punteggio di 9.2 sulla scala CVSS v4.0. I dettagli erano trapelati un giorno prima del rilascio, quindi installate la patch il prima possibile.

  • CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), RCE tramite corruzione OOM: la gestione della memoria insufficiente può interrompere PHP mentre i dati della richiesta sono solo parzialmente inizializzati.
  • CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), RCE tramite stato globale obsoleto: lo stato di una richiesta può persistere dopo che la memoria ad esso associata è stata liberata e una richiesta successiva sullo stesso worker può utilizzarlo.

Ogni installazione di PHP che gestisce richieste web è a rischio: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP considera mod_php il più rischioso. PHP 8.1 e versioni precedenti non hanno ricevuto alcuna correzione ufficiale dal progetto PHP.

🤓😎 Sempre più persone stanno ricevendo i nostri consigli su Geek, Privacy, Sviluppo e Stile di Vita

Vuoi ricevere gli ultimi blog su Geek, Privacy, Sviluppo e Lifestyle? Iscriviti alla nostra newsletter.

Innanzitutto: le linee “Ign” non sono un tuo problema

Sui server Forge, aggiornamento apt potrebbe stampare righe come queste:

Ign:18 https://ppa.launchpadcontent.net/laravelphp/forge/ubuntu noble InRelease Hit:19 https://ppa.launchpadcontent.net/ondrej/php/ubuntu noble InRelease

Ignizione significa che apt non è riuscito a recuperare l'indice del PPA di Laravel Forge e lo ha saltato. Questo è un avviso, non un errore, e di solito scompare quando Launchpad è meno occupato. Ancora più importante, PHP stesso non proviene da quel PPA. Il PPA di Forge contiene solo alcune estensioni (php-imagick, php-memcached, php-msgpack). PHP proviene dal repository di Ondřej Surý (ondrej/php), quindi è quello da esaminare.

Passaggio 1: Scopri cosa corri

lsb_release -cs # jammy = Ubuntu 22.04, noble = Ubuntu 24.04 ls /etc/php # quali versioni di PHP sono installate sudo apt update apt-cache policy php8.3-fpm php8.4-fpm | grep -E '^php|Installed|Candidate''

Aggiungi ogni versione di PHP che hai all'ultimo comando. Sei aggiornato quando la versione installata è 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o più recente). Se Installato E Candidato Entrambi mostrano una versione precedente, il tuo repository non offre ancora la correzione. In tal caso, leggi il passaggio 2, quindi il passaggio 3B.

Passaggio 2: Aggiungi le soluzioni temporanee mentre aspetti

Queste impostazioni riducono l'esposizione a specifici percorsi di attacco. non rendi sicuro un server; solo l'aggiornamento lo fa. Mettili in un file di inserimento invece di modificarli php.ini, perché Forge potrebbe riscrivere php.ini:

for v in 8.3 8.4; do printf 'session.upload_progress.enabled = 0\nsession.use_strict_mode = 1\n' \ | sudo tee /etc/php/$v/fpm/conf.d/99-php2shell-mitigation.ini sudo systemctl restart php$v-fpm done # Check (should show 0 and 1): php-fpm8.3 -i | grep -E 'upload_progress.enabled|use_strict_mode''

Modifica 8.3 8.4 alle versioni presenti sul tuo server. Puoi conservare questo file dopo l'applicazione della patch: PHP raccomanda la modalità di sessione rigorosa per ogni sito e poche app utilizzano la funzionalità di caricamento progressivo.

Passaggio 3A: Aggiornare dal PPA di ondrej (se contiene la correzione)

Il giorno del rilascio, il PPA Launchpad di Ondřej era in ritardo. Ora ha pubblicato le build corrette per Ubuntu 22.04 e 24.04. Se policy apt-cache mostra la versione corretta come candidata, aggiorna solo i pacchetti PHP:

sudo apt-get install -s --only-upgrade 'php*' | grep -E '^Inst' # prima esegui una prova sudo apt-get install --only-upgrade 'php*''

Mantieni le citazioni intorno ''php*'', quindi la shell non espande l'asterisco. Poi passa al passaggio 4.

Passaggio 3B: Passa a packages.sury.org (se il PPA è ancora in ritardo)

Ondřej pubblica anche i suoi pacchetti su packages.sury.org, e quel repository conteneva prima le build corrette. Il PPA di Launchpad verrà comunque unito ad esso, quindi il passaggio ora non è una deviazione. non Abilitali entrambi contemporaneamente: due fonti per gli stessi pacchetti generano candidati di aggiornamento fuorvianti.

1. Sposta il PPA ondrej fuori dalla portata (spostandolo invece di eliminandolo puoi tornare indietro). Lascia il laravelphp/forge Solo PPA.

grep -rl 'ondrej/php' /etc/apt/sources.list.d/ # Sposta i file elencati, ad esempio: sudo mv /etc/apt/sources.list.d/ondrej-ubuntu-php-noble.sources /root/

2. Aggiungi packages.sury.org. Il $(lsb_release -cs) questa parte si inserisce nella tua versione di Ubuntu. Non digitare nobile O marmellata a mano; vedi l'errore qui sotto.

sudo curl -fsSLo /usr/share/keyrings/deb.sury.org-php.gpg https://packages.sury.org/php/apt.gpg printf 'Types: deb\nURIs: https://packages.sury.org/php/\nSuites: %s\nComponents: main\nSigned-By: /usr/share/keyrings/deb.sury.org-php.gpg\n' "$(lsb_release -cs)" \ | sudo tee /etc/apt/sources.list.d/php.sources sudo apt update apt-cache policy php8.3-fpm php8.4-fpm | grep -E '^php|Installed|Candidate''

Il candidato dovrebbe ora essere una versione fissa come 8.3.36-1+0~20261021… proveniente da packages.sury.org/php. Se è così, esegui la simulazione e procedi con l'aggiornamento a partire dal passaggio 3A.

Errore "dipendenze non soddisfatte" (libc6, libssl3t64, libicu74)

Se l'aggiornamento fallisce con un messaggio simile a questo:

php8.3-cli : Dipende da: libc6 (>= 2.38) ma deve essere installato 2.35-0ubuntu3.15 Dipende da: libssl3t64 (>= 3.0.0) ma non è installabile E: Impossibile correggere i problemi, sono presenti pacchetti danneggiati bloccati.

quindi il repository punta alla versione errata di Ubuntu. libc6 2.35 Significa che il server esegue Ubuntu 22.04 (jammy), ma apt offre build per la versione 24.04 (noble). Non è stato installato nulla; apt si è interrotto prima di apportare modifiche. Correggi la suite e riprova:

sudo sed -i "s/^Suites: .*/Suites: $(lsb_release -cs)/" /etc/apt/sources.list.d/php.sources sudo apt update

Passaggio 4: riavvia tutto e verifica

Un processo in esecuzione mantiene la vecchia versione di PHP in memoria fino al suo riavvio. Aggiornare solo il pacchetto non è sufficiente.

sudo systemctl restart php8.3-fpm php8.4-fpm php artisan queue:restart # in ogni sito Laravel; riavvia anche i daemon Horizon / Octane / Supervisor # Apache con mod_php necessita di un riavvio completo (un ricaricamento non è sufficiente): # sudo systemctl restart apache2 # Controlla le versioni installate: dpkg -l 'php8.[34]-fpm' | awk '/^ii/{print $2, $3}' # Elenca i processi che eseguono ancora il vecchio PHP (output vuoto = tutto a posto): sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps

Il repository packages.sury.org è sicuro?

È affidabile quanto il PPA di Launchpad, perché ha lo stesso manutentore e gli stessi pacchetti. Ondřej Surý è uno sviluppatore Debian e mantiene PHP in Debian. Se il tuo server utilizza già ppa:ondrej/php (ogni server Forge lo fa), ti fidi già di lui. I pacchetti sono firmati e il Firmato da La linea limita la sua chiave a questo singolo repository.

Le avvertenze: si tratta di un repository di terze parti, gestito da volontari, non supportato da Canonical. E la chiave viene scaricata dallo stesso dominio dei pacchetti. Se vuoi controllarla, confronta l'output di gpg --show-keys /usr/share/keyrings/deb.sury.org-php.gpg con l'impronta digitale pubblicata da Ondřej. Per un server non aggiornato con una vulnerabilità RCE trapelata, rimanere sul posto rappresenta un rischio di gran lunga maggiore.

Note per gli utenti di Laravel Forge

  • Se installi una nuova versione di PHP tramite il pannello Forge in seguito, Forge potrebbe aggiungere ppa:ondrej/php di nuovo. Controlla con grep -rl ondrej /etc/apt/sources.list.d/ e spostalo se sei passato a packages.sury.org.
  • I server Forge spesso eseguono più di una versione di PHP. Applica le patch e riavviale tutte, non solo quella predefinita della CLI.
  • Utilizzare i file drop-in in conf.d per le tue impostazioni, in modo che sopravvivano alla riscrittura di Forge php.ini.

Fonti

Ripetiamo: l'utilizzo è a vostro rischio e pericolo. Questo è un resoconto di ciò che ha funzionato per noi, non una consulenza professionale. Consultate gli avvisi ufficiali di PHP e le vostre fonti di pacchetti, eseguite prima un backup e testate tutto prima di cambiare server di produzione.

Ultimo aggiornamento: 22 ottobre 2026

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

it_ITItaliano
Scorri verso l'alto