Allerta PHP e WordPress: cosa fare e quali verifiche chiedere

Il tuo sito WordPress può continuare a ricevere visite e ordini mentre sul server è presente una vulnerabilità. La home che si apre è un controllo di disponibilità; per valutare un’allerta di sicurezza servono anche versione effettiva di PHP, correzioni del fornitore e configurazione dell’ambiente.

L’allerta PHP di ottobre 2026 riguarda anche chi usa WordPress per presentare un’attività, raccogliere richieste o vendere online. Qui spieghiamo cosa è stato corretto, quale verifica aggiuntiva è emersa il 23 ottobre e come organizziamo un intervento sul sito.

Verifica delle fonti: 23 ottobre 2026. Le versioni riportate documentano questo episodio: per un intervento successivo va controllata la release supportata e aggiornata disponibile in quel momento.

Cosa è successo: due vulnerabilità critiche e un nuovo avviso

Il 21 ottobre il progetto PHP ha pubblicato aggiornamenti per due vulnerabilità che possono consentire l’esecuzione di codice da remoto senza autenticazione. La prima, CVE-2026-109618, riguarda la gestione di condizioni di memoria esaurita e di dati interni non completamente inizializzati. La seconda, CVE-2026-109619, riguarda stato interno che può sopravvivere alla memoria a cui si riferisce. Entrambi gli avvisi riportano gravità critica e CVSS 4.0 pari a 9,2.

Il 23 ottobre è arrivato un ulteriore avviso PHP, relativo a CVE-2026-115560. Riguarda una combinazione insolita: un’applicazione configura un determinato gestore di serializzazione delle sessioni, lo cambia durante l’esecuzione e mantiene attivo il progresso degli upload in sessione. PHP suggerisce di disabilitare session.upload_progress.enabled in attesa della successiva release ordinaria; le applicazioni che non cambiano quel gestore durante l’esecuzione non ricadono nella condizione descritta.

Il controllo va quindi oltre il numero della release: chi amministra il server deve verificare anche l’applicabilità dell’avviso aggiuntivo, l’effettiva configurazione e il riavvio dei processi interessati, come indicato dal CERT-EU. Inserire una direttiva in un plugin WordPress non dimostra che sia attiva nel momento in cui PHP interpreta la richiesta.

Quali versioni PHP correggono le prime due falle

Per CVE-2026-109618 e CVE-2026-109619, gli avvisi ufficiali del progetto PHP indicano queste release corrette:

Questa tabella si riferisce alle due falle del 21 ottobre. Non certifica l’intera sicurezza del sito e non esaurisce la verifica dell’avviso del 23 ottobre.

Su hosting e pacchetti di distribuzione possono esserci correzioni riportate su una build precedente, chiamate backport. In quel caso chiediamo al fornitore un riscontro specifico. Il bollettino CERT-EU raccomanda l’aggiornamento immediato dei sistemi interessati e distingue la correzione completa dalle mitigazioni parziali. Se non è possibile correggere subito, va valutato con il responsabile tecnico l’isolamento temporaneo delle applicazioni esposte.

WordPress aggiornato significa anche PHP aggiornato?

WordPress, plugin, tema e PHP appartengono a livelli diversi. Aggiornare WordPress dal pannello non conferma che il runtime PHP dell’hosting abbia ricevuto la patch. Allo stesso modo, cambiare PHP non aggiorna automaticamente un plugin obsoleto o una personalizzazione del sito.

Per questo partiamo da un inventario: versione completa di PHP usata dalle richieste web, WordPress, componenti installati, codice personalizzato e collegamenti esterni. Il perimetro del server si verifica con il fornitore hosting; quello applicativo si controlla sul sito. La documentazione WordPress sulla sicurezza richiama proprio la necessità di conoscere responsabilità e protezioni dell’ambiente.

Anche firewall e CDN vanno considerati nel loro contesto. In questo episodio, l’avviso PHP descrive percorsi che possono essere attivati prima del codice applicativo. Un plugin che interviene dentro WordPress non offre quindi, da solo, la conferma che il problema del runtime sia risolto. La verifica decisiva rimane la correzione del componente interessato.

Il sito è stato violato? Cosa possiamo capire davvero

Una vulnerabilità descrive una possibilità di attacco. Per stabilire se un sito è stato compromesso servono evidenze riferite a quel sistema: richieste, accessi, modifiche, file e cronologia disponibile. Un punteggio di gravità non è la percentuale di probabilità che i tuoi dati siano stati sottratti.

Il caso britannico aiuta a capire la distinzione. Nella seduta parlamentare del 22 ottobre, il governo ha spiegato che gran parte delle indisponibilità derivava da misure precauzionali durante aggiornamenti e mitigazioni. In quella comunicazione non risultavano compromissioni confermate dei sistemi del governo centrale dovute a queste vulnerabilità.

Per una verifica sul tuo sito raccogliamo i log disponibili e ne controlliamo periodo, completezza e provenienza. Le statistiche di visita non sostituiscono i log grezzi di accesso e autenticazione. Se mancano registrazioni, rendiamo esplicito quale parte non si può ricostruire: l’assenza di tracce in un insieme incompleto non dimostra l’assenza di accessi.

Come organizziamo aggiornamento e verifica del sito

Il primo obiettivo è ridurre l’esposizione con una correzione pertinente, mantenendo sotto controllo le funzioni da cui dipende la tua attività. Il piano cambia tra un sito vetrina, un portale con documenti e un negozio online.

Individuiamo l’ambiente che serve davvero il sito

Confrontiamo versione mostrata dal pannello hosting e runtime effettivo delle richieste web. Verifichiamo quali domini o sottocartelle condividono la stessa impostazione PHP: cambiare la versione su un hosting può coinvolgere più installazioni. Uno staging che condivide quella configurazione con la produzione non permette una prova indipendente del cambio.

Prepariamo una copia utilizzabile e un percorso di ripristino

Salviamo file e database e definiamo come recuperarli. Per un e-commerce consideriamo anche gli ordini che possono arrivare durante l’intervento: ripristinare un vecchio database senza questa valutazione può sovrascrivere informazioni recenti. La copia di prova va protetta e deve usare credenziali, invii e pagamenti adatti ai test.

Scegliamo il passaggio compatibile con il sito

La correzione urgente e il passaggio a un altro ramo PHP sono due decisioni da coordinare. Non è obbligatorio migrare a 8.4 se esiste una release corretta e supportata del ramo già in uso. Quando il cambio di ramo è necessario, controlliamo anche codice, estensioni e incompatibilità indicate dalle guide ufficiali di migrazione PHP.

Il calendario ufficiale del supporto PHP serve a pianificare il passo successivo: al 23 ottobre 2026, la sicurezza del ramo 8.2 è prevista fino al 31 dicembre 2026, quella di 8.3 fino al 2027, di 8.4 fino al 2028 e di 8.5 fino al 2029. Per versioni più vecchie servono una verifica delle eventuali correzioni del fornitore e un piano di migrazione.

Ripetiamo i percorsi importanti dopo il cambio

Controlliamo pagine e amministrazione, ma anche le operazioni effettive: invio e ricezione dei moduli, caricamento di allegati, accessi, prenotazioni e integrazioni presenti. Un test superato in copia è un’evidenza utile; sul pubblico verifichiamo nuovamente l’ambiente e i percorsi concordati. Registriamo versione, controlli, esiti e anomalie aperte.

Nell’intervento di ottobre abbiamo usato copie locali per le prove prima del cambio sui siti pubblici. Nel percorso e-commerce abbiamo verificato in sandbox Stripe un pagamento riuscito, un pagamento rifiutato e l’autenticazione 3D Secure. Sono controlli su comportamenti specifici, da scegliere in base ai sistemi di pagamento realmente utilizzati.

La guida agli aggiornamenti WordPress prima e dopo approfondisce l’organizzazione ordinaria di backup, prove e rilascio.

Per un e-commerce il controllo arriva fino all’ordine

Se vendi online, la verifica deve seguire il percorso completo: scelta del prodotto, eventuale configurazione o upload, carrello, spedizione, checkout, pagamento e aggiornamento dello stato dell’ordine. Un acquisto può dipendere da collegamenti fra sito, gestore dei pagamenti, email e gestionale.

Le prove in sandbox permettono di controllare esiti positivi, rifiuti e autenticazione aggiuntiva senza addebiti reali. I webhook, cioè le notifiche inviate dal servizio al sito, richiedono una verifica propria: una risposta simulata localmente e una consegna effettiva dall’esterno dimostrano passaggi diversi. Il piano di collaudo deve chiarire quali sono stati provati.

Questo lavoro comincia già nella progettazione. Nel servizio di realizzazione siti e-commerce colleghiamo catalogo, acquisto e strumenti operativi, definendo anche come mantenere e verificare le integrazioni. Se il negozio esiste già, il punto di partenza è una valutazione tecnica del sistema attuale.

Le informazioni da chiedere subito a chi gestisce l’hosting

Puoi iniziare con una richiesta precisa, senza dover inviare password:

Qual è la versione completa di PHP che serve le richieste web del mio dominio? Sono applicate le correzioni per CVE-2026-109618 e CVE-2026-109619? Avete verificato l’applicabilità e la mitigazione dell’avviso del 23 ottobre per CVE-2026-115560? La configurazione coinvolge altre installazioni sullo stesso hosting? Quali log sono disponibili e per quale periodo?

Conserva la risposta e la data della verifica. Se usi un servizio gestito, chiedi quali attività copre il fornitore e quali restano a chi mantiene WordPress. Una conferma generica come “l’hosting è aggiornato” lascia aperti dettagli essenziali per decidere l’intervento.

Ti serve assistenza per aggiornare WordPress o PHP?

Da Ferrara seguiamo siti WordPress e integrazioni con un rapporto diretto: analizziamo lo stato iniziale, definiamo cosa aggiornare, prepariamo le prove e verifichiamo le funzioni concordate. Possiamo affrontare un problema specifico, preparare un aggiornamento WordPress dedicato oppure organizzare una manutenzione WordPress continuativa.

Per iniziare mandaci l’indirizzo del sito, il nome dell’hosting e le funzioni importanti per la tua attività, per esempio richieste, appuntamenti o vendita online. Se hai ricevuto un avviso, allega il testo evitando credenziali e dati personali. Da queste informazioni definiamo priorità, accessi necessari e perimetro dell’intervento.

Chiedici una verifica del tuo sito WordPress. Partiamo da ciò che deve continuare a funzionare per te e per chi usa il sito.

Fonti e aggiornamenti

• PHP: avvisi del 21 e del 23 ottobre 2026.
• Avviso ufficiale GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp.
• CERT-EU 2026-018, revisione del 23 ottobre.
• Parlamento britannico: comunicazione del 22 ottobre 2026.
• Versioni PHP supportate; migrazione a PHP 8.4; sicurezza e manutenzione WordPress.

Questo approfondimento viene aggiornato in base ai nuovi avvisi e alle release ufficiali. Le prove descritte documentano il nostro metodo di intervento; per valutare il tuo sito occorrono le sue versioni, la sua configurazione e i suoi dati tecnici.