Il sito funziona, i clienti riescono ancora ad accedere e il pannello di monitoraggio potrebbe non mostrare anomalie. Questo non dimostra che il runtime PHP sottostante sia stato corretto per le vulnerabilità PHP2Shell. Se utilizzate WordPress, Laravel, un negozio online o un portale clienti PHP, la domanda urgente è quale build PHP gestisce effettivamente le richieste web e chi la aggiornerà.
Serve aiuto adesso? ObsidianCorps offre assistenza immediata alle aziende in Lussemburgo e nella Grande Regione per applicare le patch PHP: verifica dell’esposizione, aggiornamenti di sicurezza, distribuzione e convalida. Richiedete un intervento PHP urgente oppure chiamate il +352 691 165 856. Indicate i siti o le applicazioni interessate e chi gestisce l’hosting, così potremo definire il prossimo passo.
Situazione dei nostri clienti al 21 ottobre 2026: nessuno dei nostri clienti è interessato da queste vulnerabilità.
PHP2Shell: cosa è stato pubblicato il 21 ottobre 2026?
Il 21 ottobre 2026 PHP ha pubblicato aggiornamenti di sicurezza per CVE-2026-109618 e CVE-2026-109619, spesso indicate insieme come PHP2Shell. L’annuncio ufficiale di sicurezza PHP descrive due vulnerabilità critiche che possono consentire l’esecuzione di codice da remoto senza autenticazione e invita ad aggiornare immediatamente.
CVE-2026-109618 riguarda l’esaurimento della memoria e uno stato della richiesta non valido. Se un’allocazione fallisce durante determinate operazioni, PHP può lasciare dati inizializzati solo in parte. La pulizia della richiesta può quindi utilizzare quei dati non validi. L’avviso descrive le condizioni in cui ciò può portare all’esecuzione di codice da remoto.
CVE-2026-109619 riguarda uno stato globale obsoleto. Un processo worker può conservare riferimenti alla memoria di una richiesta precedente dopo che questa è stata liberata. Una richiesta successiva gestita dallo stesso worker può accedere a quello stato prima che la normale inizializzazione lo sostituisca. La possibilità di sfruttamento dipende dalle operazioni raggiungibili e dalla configurazione.
Per un’azienda, uno sfruttamento riuscito potrebbe permettere a un attaccante di eseguire codice con i permessi del processo PHP interessato. Date priorità ai servizi che accedono a informazioni sui clienti, segreti applicativi o sistemi aziendali. Una homepage funzionante non è una verifica di sicurezza.
Quali versioni PHP contengono le correzioni?
Gli avvisi PHP indicano le seguenti prime versioni corrette per i rami supportati. Utilizzate queste versioni o una versione successiva dello stesso ramo contenente le correzioni; verificate separatamente la situazione se passate a un altro ramo.
| Ramo PHP | Prima versione ufficiale che corregge entrambe le CVE |
|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
I pacchetti delle distribuzioni e delle offerte di supporto commerciale possono includere correzioni retroportate senza adottare il numero di versione upstream riportato sopra. Richiedete l’avviso di sicurezza e la revisione esatta del pacchetto che copre entrambe le CVE. Per Ubuntu, consultate lo stato della vostra versione del sistema per CVE-2026-109618 e CVE-2026-109619: la semplice presenza di un pacchetto non dimostra che la revisione installata includa la correzione.
PHP precisa che PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti regolari dal progetto. Se dipendete ancora da un ramo precedente, ottenete una conferma esplicita della copertura del fornitore oppure pianificate un aggiornamento. L’assenza di una nuova versione upstream per il vostro ramo non dimostra che sia immune.
Chi dovrebbe controllare i sistemi adesso?
PHP identifica come a rischio le installazioni che gestiscono richieste web, tra cui PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. L’annuncio considera il rischio più elevato per mod_php, dove è stato dimostrato un attacco prima dell’esecuzione del codice applicativo. Anche chi utilizza PHP-FPM deve aggiornare.
Consigliamo di iniziare con un inventario per applicazione e responsabile. Includete siti pubblici, pannelli amministrativi, portali partner, ambienti di staging raggiungibili da Internet e vecchie applicazioni ancora usate da un solo reparto. Chiedete al responsabile di ogni servizio di registrare:
- Il nome host, la funzione aziendale e la persona autorizzata ad approvare la manutenzione.
- Il runtime PHP, la fonte del pacchetto o l’immagine container che serve realmente quel nome host.
- Il fornitore di hosting o l’amministratore interno responsabile dell’aggiornamento.
- Le prove necessarie per confermare la correzione e l’orario del prossimo controllo.
Questo evita un vuoto frequente nelle responsabilità: l’agenzia web mantiene l’applicazione, l’host mantiene PHP e ciascuno presume che l’altro abbia gestito l’avviso. Incaricate una persona di raccogliere le risposte e segnalare le installazioni il cui stato resta sconosciuto.
Una procedura pratica per applicare la patch di sicurezza PHP
1. Identificare il runtime che serve il sito
Da una shell amministrativa, questi comandi in sola lettura aiutano a identificare l’installazione da riga di comando:
php -v
php --ini
La documentazione PHP sulle opzioni della riga di comando spiega queste opzioni. Mostrano il binario CLI e la sua configurazione. Un host può avere più installazioni PHP: questo risultato da solo non basta per approvare un sito che usa un altro pool FPM, modulo Apache o container.
Chiedete all’amministratore di associare il sito al gestore PHP configurato e di controllare quel runtime dal pannello di hosting o con una diagnostica ad accesso limitato. Registrate la revisione del pacchetto oltre alla versione PHP. Non lasciate una pagina phpinfo() pubblica dopo il controllo.
2. Preparare la modifica e il percorso di ripristino
Confermate un backup utilizzabile, il responsabile applicativo e i controlli che definiscono un aggiornamento riuscito. Per un portale clienti possono includere accesso, consultazione dei documenti e reimpostazione della password. Per un negozio, includete un ordine di prova e le notifiche del fornitore di pagamento. Decidete come limitare l’accesso se la convalida fallisce: il ripristino non deve trasformarsi implicitamente nel ritorno a un runtime vulnerabile.
Quando possibile, provate prima la versione corretta in un ambiente di staging rappresentativo. Concentrate la verifica sull’applicazione reale e sulle sue estensioni, per evitare che l’intervento urgente diventi una migrazione del framework estranea alla correzione.
3. Aggiornare ogni istanza distribuita
Per i server gestiti tramite pacchetti, installate la revisione del fornitore che risolve esplicitamente entrambe le CVE per il vostro sistema operativo e ramo PHP. Controllate tutti i pool attivi e i gestori delle applicazioni. Consigliamo una procedura specifica del fornitore anziché un unico comando universale: nomi dei pacchetti, repository e servizi variano tra installazioni.
Per i container, procuratevi un’immagine di base che includa le correzioni, ricostruite l’immagine applicativa e sostituite i container in esecuzione. Docker documenta perché ricostruire le immagini e come recuperare immagini di base aggiornate. Modificare un Dockerfile o completare una build non conferma cosa sia attivo in produzione. Verificate l’identità dell’immagine in esecuzione e la build PHP in ogni replica che serve richieste.
Per hosting condiviso o gestito, chiedete al fornitore conferma scritta della build corretta per ogni abbonamento interessato. Se gestite più siti, verificate il gestore PHP assegnato a ciascuno: un’impostazione predefinita aggiornata non dimostra che tutti la utilizzino.
4. Sostituire i vecchi worker e convalidare il servizio attivo
Organizzate il riavvio o la sostituzione necessari affinché tutti i worker web utilizzino il runtime aggiornato. Coordinate la procedura con l’architettura dell’hosting, compresi eventuali nodi e repliche multipli. Ricontrollate quindi il gestore attivo ed eseguite i test applicativi concordati.
Conservate nel registro della modifica il riferimento all’avviso, la revisione del pacchetto o il digest dell’immagine, l’orario di completamento e i risultati della convalida. Consigliamo di registrare separatamente le eccezioni, con un responsabile e una decisione esplicita sull’esposizione residua. Un ticket chiuso dovrebbe significare che il servizio distribuito è stato verificato.
Cosa fare se non potete applicare subito la patch?
PHP afferma che solo un aggiornamento offre una soluzione completa. Le modifiche alla configurazione possono ridurre specifici percorsi di attacco, ma non dimostrano che un’installazione non corretta sia sicura.
Gli avvisi tecnici descrivono misure parziali, tra cui la disattivazione del monitoraggio dell’avanzamento degli upload di sessione per i percorsi confermati legati alle sessioni. Ne spiegano anche i limiti: CVE-2026-109619 ha altri meccanismi che producono e utilizzano stato obsoleto, mentre CVE-2026-109618 coinvolge errori di allocazione. Una singola raccomandazione di configurazione non giustifica una dichiarazione generale di protezione.
Per un servizio in attesa della patch, consigliamo una decisione documentata sull’esposizione: limitare l’accesso, introdurre un controllo degli accessi adeguato oppure ritirare temporaneamente il servizio, quando l’attività lo permette. Chiedete all’amministratore di valutare ogni misura provvisoria rispetto all’avviso ufficiale e all’applicazione. Mantenete un responsabile nominato e una scadenza di verifica finché l’aggiornamento effettivo non è stato convalidato.
Dopo la patch: distinguere correzione e analisi dell’incidente
L’aggiornamento corregge le vulnerabilità documentate nel runtime. Non stabilisce se si sia verificata una compromissione precedente. Se trovate file inattesi, modifiche inspiegabili agli account, traffico in uscita sospetto o altre anomalie, preservate gli elementi utili e richiedete un approfondimento. Queste osservazioni richiedono un’indagine; da sole non attribuiscono la causa a una delle due CVE.
ObsidianCorps può combinare distribuzione applicativa e supporto infrastrutturale con valutazioni di sicurezza e analisi degli incidenti. Concordate il perimetro della correzione operativa e quello dell’eventuale indagine, assegnando a entrambi un responsabile chiaro.
Domande sull’aggiornamento PHP2Shell
Aggiornare WordPress, un plugin o Laravel risolve il problema?
Il componente interessato è PHP stesso. Gli aggiornamenti applicativi restano utili, ma ottenete conferma che il runtime PHP sottostante includa queste correzioni. Verificate le responsabilità dell’applicazione e dell’hosting.
Basta un firewall o un WAF?
Non utilizzate una regola WAF come criterio di completamento. PHP precisa che le mitigazioni parziali non sostituiscono l’aggiornamento. Mantenete aperta la correzione del runtime finché la patch distribuita non è stata verificata.
Possiamo mantenere il ramo PHP supportato attuale?
La tabella elenca le versioni correttive di PHP 8.2, 8.3, 8.4 e 8.5. Non occorre passare a un altro ramo principale o secondario solo per ottenere queste correzioni se quello supportato attuale offre una versione adeguata. Verificate la compatibilità applicativa e il supporto del fornitore quando scegliete il pacchetto.
Quali informazioni servono per chiedere aiuto?
Iniziate dal dominio interessato, dal fornitore di hosting, dalla versione PHP conosciuta e dagli eventuali vincoli di manutenzione. Una descrizione generale basta per il primo contatto. Non inviate password, chiavi private o dati sensibili dei clienti nel modulo; concordate un canale sicuro per gli accessi.
Assistenza immediata per le patch PHP in Lussemburgo
ObsidianCorps offre assistenza immediata per individuare i servizi PHP esposti, applicare l’aggiornamento di sicurezza appropriato, riavviare o ridistribuire il runtime interessato e verificare il comportamento applicativo. Concordiamo con voi accessi, perimetro e tempi prima di intervenire in produzione. Il risultato è un resoconto di cosa è stato aggiornato, cosa è stato verificato e cosa richiede ancora attenzione.
Per preparare le prossime release di emergenza, leggete la nostra guida a gestione delle vulnerabilità e priorità delle patch. Per questo aggiornamento di sicurezza PHP, richiedete assistenza urgente oppure chiamate il +352 691 165 856 citando CVE-2026-109618 e CVE-2026-109619.
