Il 21 ottobre 2026 il team di sicurezza di PHP ha eseguito un rilascio d’emergenza per correggere due vulnerabilità critiche con punteggio CVSS v4.0 di 9,2. Nelle prime ore di incertezza, diverse istituzioni e grandi organizzazioni hanno scelto di mettere temporaneamente offline i propri portali per precauzione: tra questi, alcune voci di Wikipedia, il sito del governo finlandese, quello dell’agenzia per la cybersicurezza olandese e diverse prefetture francesi.
Oggi il quadro è chiaro: le patch ufficiali sono state pubblicate e le correzioni sono in fase di rilascio attivo su tutti i siti web e le infrastrutture a livello globale.
Se la tua azienda gestisce un sito, un e-commerce o una piattaforma web su stack PHP, la priorità si sposta ora dall’allarme all’esecuzione: verificare l’infrastruttura, applicare i correttivi ed evitare interruzioni di servizio.
Cosa è successo con PHP?
PHP è alla base di una fetta enorme del web moderno: secondo le analisi di settore alimenta circa sette siti su dieci (con stime conservative di Palo Alto Networks che parlano di oltre la metà dell’intero web).
Le due falle — tracciate come CVE-2026-109618 e CVE-2026-109619 — sono state individuate dai ricercatori delle società di cybersicurezza Calif e Wiz tramite l’ausilio di modelli di intelligenza artificiale. I difetti risiedevano nel codice da oltre un decennio senza mai essere stati rilevati.
L’unico modo per neutralizzare la minaccia è aggiornare l’interprete PHP. Il team del linguaggio ha reso disponibili le versioni corrette sui rami supportati:
Per le versioni del linguaggio ufficialmente dichiarate end-of-life (EOL), i maintainer delle principali distribuzioni Linux (come Debian, Ubuntu, Red Hat) e i provider specializzati hanno reso disponibili patch mirate di backporting. Per le installazioni legacy prive di qualsiasi supporto, la situazione impone invece un upgrade architetturale immediato o l’adozione di severe misure di mitigazione.
Il quadro confermato: dalla segnalazione al rilascio
A differenza delle prime ore concitate, le informazioni tecniche sono ormai consolidate dagli advisory ufficiali di PHP e del CERT-EU:
- Natura del rischio: le due vulnerabilità espongono a potenziale esecuzione di codice da remoto (RCE) non autenticata.
- Correzioni disponibili: le patch sono ufficiali e pubbliche; non è più necessario attendere chiarimenti o basarsi su indiscrezioni.
- Fase operativa: la mitigazione globale è in corso. Hosting provider, team DevOps e agenzie stanno distribuendo gli aggiornamenti su scala mondiale.
Perché questa vicenda fa da spartiacque?
- La scala: Unit 42 di Palo Alto Networks stima circa 22 milioni di istanze potenzialmente esposte. Per fare un confronto, falle critiche recenti su apparati NetScaler contavano circa 50.000 istanze a rischio.
- La velocità del ciclo patch-exploit: l’impiego dell’AI nella ricerca delle vulnerabilità ha accorciato drasticamente i tempi. Se i modelli analizzano il codice delle patch non appena rilasciato per tentare il reverse engineering del difetto, la finestra utile per proteggersi prima che compaiano i primi exploit automatici si misura in ore, non in settimane.
Il primo passo: l’inventario operativo
Prima ancora di lanciare script di aggiornamento a tappeto, serve avere visibilità completa del perimetro esposto. Il Centro nazionale per la cybersicurezza britannico (NCSC) raccomanda di censire tutte le istanze PHP, assegnando massima priorità a quelle raggiungibili da rete pubblica.
Verifica sistematicamente questi ambienti:
- Produzione e staging: server dedicati, VPS, cluster Kubernetes e ambienti di collaudo.
- Container e immagini di deploy: Dockerfile, base image e pipeline CI/CD (se la base image non viene aggiornata, ogni nuovo deploy reintrodurrà il runtime vulnerabile).
- Script CLI e tool interni: strumenti di automazione, worker di background o cron job che sfruttano il binario di sistema.
- Hosting gestiti e servizi terzi: pannelli cPanel/Plesk, appliance virtuali e plugin con runtime integrato.
Applicare l’aggiornamento: il valore dei deploy controllati
Una vulnerabilità critica non giustifica rilasci affrettati che rischiano di mandare in crash l’applicazione o generare regressioni inaspettate sul carrello di un e-commerce.
Cosa stiamo facendo per i clienti Instilla
Internamente, il nostro team tecnico sta gestendo la situazione senza allarmismi e senza disservizi: tutti gli ambienti dei nostri clienti sono oggetto di deploy controllati e patch di sicurezza mirate. Questo significa testare la compatibilità negli ambienti di staging, applicare le correzioni specifiche e verificare che il processo runtime in esecuzione (ad esempio php-fpm) sia effettivamente riavviato e aggiornato, mantenendo i servizi online e performanti.
Se gestisci l’aggiornamento internamente o con fornitori terzi, segui questi principi:
- Verifica il runtime attivo: un banale aggiornamento dei pacchetti di sistema spesso non riavvia il processo FastCGI/PHP-FPM. Verifica sempre che i worker attivi puntino alla nuova versione compilata.
- Deploy orchestrato: testa la compatibilità applicativa su un ambiente clone prima di promuovere la patch in produzione.
- Coordinamento con l’hosting: se sei su hosting condiviso o managed, richiedi conferma esplicita dell’avvenuto patch-level al fornitore.
Se non puoi aggiornare subito: isolamento o mitigazione?
CERT-EU e NCSC suggeriscono di valutare l’isolamento temporaneo dalla rete per i sistemi esposti che non possono essere aggiornati tempestivamente. Tuttavia, la decisione non può essere puramente tecnica: spegnere un portale e-commerce nel mezzo di una campagna ha impatti diretti sul fatturato.
Nei casi in cui l’aggiornamento immediato del runtime non sia praticabile:
- Interponi un WAF: configura regole di Web Application Firewall per filtrare payload anomali o bloccare chiamate non conformi verso endpoint sensibili.
- Restringi l’accesso di rete: se si tratta di gestionali o aree admin interne, vincola l’accesso a VPN aziendali o whitelist di IP statici.
- Evita workaround improvvisati: modifiche casuali al codice o configurazioni non testate possono rompere le sessioni utente e dare un falso senso di sicurezza.
Verso una postura di sicurezza strutturale
La rapidità con cui si è passati dalla scoperta assistita da AI al rilascio di emergenza dimostra che la manutenzione applicativa non è più un evento straordinario, ma un processo di business continuativo. Avere visibilità del proprio stack tecnologico e pipeline di rilascio automatizzate fa la differenza tra una gestione controllata e il panico operativo.
Se vuoi verificare lo stato di aggiornamento dei tuoi portali, revisionare le configurazioni di sicurezza o strutturare pipeline di deploy affidabili, parlane con gli specialisti di Instilla.
Fonti
- PHP, Security advisory: Critical remote code execution vulnerabilities, update now (21 ottobre 2026)
- PHP, Upcoming Critical PHP Security Release (20 ottobre 2026)
- PHP, GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- PHP, GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP
- NCSC, Critical security issue affecting PHP
- Unit 42 (Palo Alto Networks), Threat Brief: Critical Vulnerabilities in PHP
- Palo Alto Networks, Millions of PHP Instances Exposed: What Organizations Need To Do Right Now
- Wiz, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet
- Il Post, Molti siti sono stati messi offline in tutto il mondo per problemi di sicurezza
- Euronews, Websites go dark after AI exposes major programming language security flaw
