PHP2Shell, due falle critiche da 9,2: aggiornamento di emergenza per PHP

🛡️ Executive Summary

• Il team PHP annuncia un rilascio straordinario di sicurezza per il 21 ottobre 2026 alle 16:00 italiane, destinato a correggere due falle CVSS 4.0 da 9,2.
• Le vulnerabilità CVE-2026-109618 e CVE-2026-109619 sono descritte dai ricercatori come RCE, ma PHP non ha ancora confermato versioni interessate e vettori tecnici.
• Non risultano campagne di sfruttamento confermate. Amministratori e hosting provider devono identificare le installazioni PHP e preparare gli aggiornamenti.

PHP prepara un aggiornamento straordinario di sicurezza per due vulnerabilità critiche, entrambe valutate 9,2 secondo CVSS 4.0 e associate dai ricercatori alla possibilità di eseguire codice remoto sui server. Il team di sviluppo ha anticipato il rilascio al 21 ottobre 2026, alle 14:00 UTC, corrispondenti alle 16:00 italiane, dopo che informazioni riservate sulle due falle sono circolate pubblicamente prima della conclusione della divulgazione coordinata. Le vulnerabilità, identificate nei report come CVE-2026-109618 e CVE-2026-109619 e associate alla denominazione PHP2Shell, rappresentano un rischio potenzialmente esteso per le infrastrutture web. La gravità dichiarata è elevata, ma l’esatto perimetro delle versioni interessate e le condizioni necessarie allo sfruttamento non sono ancora stati pubblicati ufficialmente.

PHP anticipa la pubblicazione delle patch dopo la fuga di informazioni

La decisione del team PHP arriva il 20 ottobre attraverso un annuncio ufficiale di sicurezza che comunica l’esistenza di due vulnerabilità critiche e invita tutti gli utilizzatori del linguaggio a prepararsi all’aggiornamento. Il documento non presenta ancora identificativi CVE, componenti interessati, versioni vulnerabili o dettagli sulla causa tecnica delle falle. Conferma invece due punteggi CVSS 4.0 pari a 9,2 e un rilascio correttivo straordinario programmato per il pomeriggio del 21 ottobre. Gli sviluppatori si riservano anche la possibilità di anticipare ulteriormente la distribuzione delle patch qualora emergano dettagli sufficienti per riprodurre gli exploit oppure evidenze di sfruttamento attivo. Questa formulazione è importante perché segnala un rischio considerato urgente dallo stesso progetto, senza costituire una conferma di compromissioni già avvenute. La scelta di pubblicare un preavviso prima di rendere disponibili gli aggiornamenti è inoltre insolita rispetto alle normali release di manutenzione, ma comprensibile quando la riservatezza della divulgazione coordinata risulta compromessa. Il precedente della vulnerabilità critica PHP CVE-2024-4577, capace di consentire esecuzione remota del codice, aveva già dimostrato quanto una debolezza nell’interprete possa assumere rapidamente rilevanza per i servizi web pubblicamente raggiungibili. La differenza, in questo caso, è che non esiste ancora una conferma ufficiale della specifica superficie vulnerabile, impedendo di stabilire quali configurazioni debbano essere considerate maggiormente esposte.

Leggi anche: Vulnerabilità CVE-2024-4577 PHP sfruttata per diffondere malware

CVE-2026-109618 e CVE-2026-109619: cosa è confermato e cosa resta sconosciuto

Le informazioni sulle due CVE provengono dalla divulgazione anticipata e dalle successive attività dei ricercatori. La ricostruzione tecnica di watchTowr identifica CVE-2026-109618 e CVE-2026-109619 come vulnerabilità riconducibili all’esecuzione di codice remoto, ma precisa che la documentazione ufficiale non ha ancora confermato le versioni affette o i meccanismi di sfruttamento. Il gruppo di ricerca ha dichiarato di aver riprodotto almeno la prima vulnerabilità, senza pubblicare dettagli che consentano di ricostruire direttamente l’exploit. Le indiscrezioni circolate inizialmente indicano un possibile coinvolgimento di versioni PHP risalenti alla serie 5, ma non costituiscono una matrice ufficiale di vulnerabilità: non è quindi possibile sostenere che tutte le installazioni PHP siano sfruttabili nelle medesime condizioni. Mancano informazioni decisive, come il componente interessato, la necessità di autenticazione, le configurazioni vulnerabili, l’eventuale dipendenza dal sistema operativo e la raggiungibilità del codice attraverso richieste HTTP. Una RCE non equivale automaticamente a compromissione remota senza autenticazione di qualsiasi server che utilizzi PHP. Il rischio concreto dipenderà dalle condizioni documentate con l’advisory e dalle versioni effettivamente vulnerabili. È una distinzione già necessaria nel trattamento delle vulnerabilità critiche corrette nei software Microsoft, Cisco, Apache e PHP, dove gravità tecnica, prerequisiti e sfruttamento reale richiedono valutazioni separate. Allo stato delle informazioni pubbliche, inoltre, non risulta un exploit completo liberamente disponibile e non esistono evidenze confermate di campagne offensive basate specificamente su PHP2Shell.

WordPress, Drupal e hosting condivisi ampliano la superficie da controllare

La rilevanza delle due vulnerabilità deriva soprattutto dalla diffusione dell’interprete PHP nei sistemi di pubblicazione e nelle applicazioni web. WordPress, Drupal, Joomla, Magento, piattaforme e-commerce e numerosi pannelli di amministrazione dipendono da PHP, direttamente oppure attraverso componenti installati dai fornitori. Questo non significa che tali applicazioni siano automaticamente vulnerabili, ma che una debolezza nel runtime può interessare ambienti differenti anche in assenza di errori nei singoli CMS. Il rischio riguarda inoltre server Linux, infrastrutture Windows, hosting condivisi, applicazioni aziendali e appliance che incorporano distribuzioni PHP non immediatamente visibili agli amministratori. La valutazione operativa pubblicata da Huntress richiama proprio la necessità di cercare l’interprete anche nei prodotti di terze parti, nei software che integrano php.exe o php-cgi.exe e negli ambienti che utilizzano PHP-FPM. La società dichiara di non aver rilevato sfruttamento delle due vulnerabilità nel proprio perimetro di monitoraggio al momento della pubblicazione, ma avverte che gli ambienti esposti e scarsamente monitorati possono rappresentare bersagli interessanti quando i dettagli tecnici diventeranno pubblici. Il precedente delle campagne che sfruttavano vulnerabilità PHP già note dimostra perché una patch disponibile non coincida necessariamente con una riduzione immediata della superficie d’attacco. Per le organizzazioni italiane che affidano la manutenzione a hosting provider o fornitori gestiti, il controllo deve comprendere anche le responsabilità contrattuali relative all’aggiornamento dell’interprete, separandole dalla semplice manutenzione del CMS.

Le versioni fuori supporto possono diventare il problema più difficile

La questione più delicata riguarda gli ambienti legacy. Se le vulnerabilità coinvolgeranno effettivamente rami PHP molto vecchi, le versioni fuori supporto potrebbero non ricevere correzioni ufficiali, obbligando gli amministratori a pianificare una migrazione verso release mantenute oppure ad adottare misure compensative. Questa prospettiva rimane subordinata alla conferma del perimetro vulnerabile e non autorizza a dichiarare già prive di patch determinate versioni. La gestione diventa particolarmente complessa quando applicazioni aziendali sviluppate anni prima dipendono da librerie obsolete, plugin non più mantenuti o framework incompatibili con le versioni moderne dell’interprete. In questi contesti l’aggiornamento di PHP può richiedere verifiche applicative e modifiche al codice, ma il rinvio indefinito aumenta l’esposizione quando emergono falle critiche nel runtime. Occorre distinguere anche tra pacchetti distribuiti direttamente dal progetto PHP e versioni mantenute dai produttori delle distribuzioni Linux attraverso backport di sicurezza, perché il numero di versione visualizzato dal sistema non sempre riflette tutte le correzioni applicate. Il problema della fiducia nella catena software è già emerso attraverso pacchetti Laravel malevoli distribuiti su Packagist, ma PHP2Shell riguarda un livello differente: non un componente aggiuntivo compromesso, bensì potenziali debolezze dell’infrastruttura che esegue direttamente le applicazioni. Per questo l’inventario delle versioni PHP deve essere indipendente dall’inventario dei CMS e dei framework.

Continua con:

Glutton: il sofisticato backdoor PHP che minaccia framework diffusi e cybercriminali

Oracle NetSuite e Windows: rischi e vulnerabilità PHP

Come preparare gli aggiornamenti e individuare eventuali compromissioni

La risposta operativa deve concentrarsi su attività documentabili, evitando contromisure presentate come specifiche per vulnerabilità delle quali non sono ancora noti i vettori. Gli amministratori dovrebbero innanzitutto censire le installazioni PHP realmente in esecuzione, identificare i server raggiungibili da Internet, verificare le versioni utilizzate dalle applicazioni e preparare procedure di aggiornamento con backup e test di compatibilità. Dopo la pubblicazione del bollettino ufficiale sarà necessario confrontare la matrice delle versioni vulnerabili con l’inventario interno, verificando anche eventuali pacchetti corretti dai maintainer delle distribuzioni Linux. Huntress suggerisce inoltre di monitorare comportamenti anomali dei processi PHP, soprattutto quando php-fpm, php-cgi, apache2 o altri processi web generano shell, interpreti di comando o strumenti di download in contesti non previsti. Questi comportamenti sono utili segnali generici di compromissione, non indicatori specifici e già convalidati per PHP2Shell. Nei sistemi per i quali non sarà possibile applicare tempestivamente una correzione, la riduzione dell’esposizione di rete e l’isolamento delle applicazioni più sensibili potranno limitare il rischio, pur senza costituire un workaround ufficiale delle due falle. La pubblicazione delle patch del 21 ottobre rappresenterà quindi il passaggio determinante per conoscere prodotti coinvolti, prerequisiti tecnici ed eventuali mitigazioni. La criticità attualmente confermata è l’esistenza di due vulnerabilità valutate 9,2 dal team PHP; l’estensione effettiva dell’esposizione e la disponibilità delle correzioni devono ancora essere definite dall’advisory definitivo. È su questa distinzione che deve basarsi la risposta difensiva, evitando sia di minimizzare il problema sia di trasformare una divulgazione anticipata in una campagna di compromissione già dimostrata.