Aggiornamento PHP2Shell programmato per due vulnerabilità RCE critiche
PHP2Shell è il nome assegnato dai ricercatori a due vulnerabilità PHP critiche che, secondo watchTowr, possono consentire la remote code execution (RCE), ovvero permettere a un attaccante di eseguire da remoto comandi su un server vulnerabile. PHP ha programmato una release di sicurezza fuori ciclo per le 14:00 UTC del 21 ottobre e ha assegnato a entrambe le vulnerabilità un punteggio di 9,2 secondo la versione 4.0 del Common Vulnerability Scoring System (CVSS), una scala standard per valutare la gravità delle vulnerabilità. Al momento della stesura, l'aggiornamento non era ancora stato pubblicato e PHP non aveva reso note le versioni interessate, la causa tecnica, la configurazione necessaria o le versioni corrette.
L'avviso di emergenza è seguito a un post pubblicato il 20 ottobre su Hacker News, secondo il quale due vulnerabilità RCE interessavano tutte le versioni di PHP a partire da PHP 5. Il post assegnava un punteggio CVSS di 10,0, indicava il 22 ottobre come data prevista per la divulgazione e non forniva prove a sostegno. In seguito, watchTowr ha dichiarato che l'esistenza delle vulnerabilità soggette a embargo era autentica, ma non ha pubblicato dettagli tecnici. PHP ha pubblicato il proprio avviso alle 19:33 UTC della stessa sera e ha programmato l'aggiornamento un giorno prima della data indicata nel leak. L'avviso affermava inoltre che la release avrebbe potuto essere anticipata se i dettagli delle vulnerabilità fossero diventati pubblici o fossero emerse prove di attacchi attivi.
I ricercatori utilizzano gli identificatori CVE-2026-109618 e CVE-2026-109619, entrambi comparsi nel post oggetto del leak. L'avviso di PHP non menzionava nessuno dei due identificatori, quindi la loro associazione ufficiale con le vulnerabilità non era stata confermata in quella sede. Non era confermata neppure l'affermazione del leak secondo cui sarebbero vulnerabili tutte le release a partire da PHP 5. La pagina delle domande frequenti di watchTowr affermava che nessun vendor advisory ufficiale aveva stabilito una portata così ampia e che non era stata descritta alcuna funzionalità o configurazione PHP necessaria. Anche l'etichetta PHP2Shell proviene dai ricercatori, non da PHP.
Solo i quattro branch supportati di PHP, dalla versione 8.2 alla 8.5, possono ricevere le correzioni. Prima della release, i tracker citati prevedevano aggiornamenti numerati PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, ma PHP non aveva confermato tali versioni. Al 24 settembre, le release correnti erano 8.5.11, 8.4.26, 8.3.35 e 8.2.34. PHP 8.5 era in active support fino al 31 dicembre 2027, mentre PHP 8.4 era in active support fino al 31 dicembre 2026. PHP 8.3 riceveva security-only support fino al 31 dicembre 2027 e PHP 8.2 fino al 31 dicembre 2026.
PHP 8.1, PHP 8.0, tutte le release 7.x e tutte le release 5.x sono end of life, ossia PHP non fornisce più aggiornamenti di sicurezza per tali versioni. Se le vulnerabilità venissero infine confermate anche per questi branch, le installazioni che li utilizzano ancora non riceverebbero una patch dal vendor. La questione è particolarmente rilevante per siti web meno recenti, account di hosting, control panel, appliance dei vendor e applicazioni Windows che potrebbero includere un'installazione PHP integrata non controllata abitualmente dagli amministratori.
La società di sicurezza Mallory ha contato circa 884.000 host internet-facing il cui HTTP banner, ossia le informazioni identificative che un web server può esporre, segnalava al motore di ricerca Shodan l'utilizzo di PHP 8.1 o di una versione precedente il 20 ottobre. La cifra rappresentava il 59% dei circa 1,5 milioni di host che dichiaravano una versione di PHP. Altri 740.000 host dichiaravano di utilizzare PHP, ma non ne rivelavano la versione. Questi dati descrivono banner visibili, non sistemi nei quali sia stata confermata la presenza di una delle vulnerabilità PHP2Shell, e quindi non consentono di stabilire il numero dei server interessati.
PHP non aveva pubblicato alcun workaround prima della release programmata. Huntress ha raccomandato di identificare ogni installazione PHP, comprese le copie integrate in appliance, software Windows, cPanel e Plesk, e quindi di prepararsi ad aggiornare per primi i sistemi internet-facing. Gli amministratori dovrebbero inoltre verificare se la propria distribuzione Linux o il proprio hosting provider fornisca un backported package, che applica una specifica correzione di sicurezza a una release pacchettizzata meno recente senza sostituirla con la più nuova release completa. I sistemi che utilizzano un branch end of life dovrebbero essere aggiornati, rimossi dall'accesso pubblico a Internet oppure collocati dietro una virtual private network o un web application firewall finché non possano essere aggiornati. CERT-EU ha inoltre consigliato di valutare l'isolamento delle applicazioni public-facing dalle reti pubbliche fino alla disponibilità di una correzione.
Il monitoraggio può aiutare a identificare attività sospette, ma non sostituisce l'applicazione delle patch. Agli amministratori è stato consigliato di generare un alert quando php-fpm, php-cgi, httpd o apache2 avviano command shell, interpreters o download utility. Una utility process-watcher pubblicata da un ricercatore può registrare ogni programma avviato da un PHP process su Linux, insieme alla relativa command line, ma rileva un programma solo dopo l'inizio dell'esecuzione e non lo blocca. Se viene rilevata un'attività sospetta, le indicazioni prevedono di isolare il server, conservare i logs di PHP e del web server e verificare la presenza di web shells, ossia file dannosi che consentono il controllo remoto del server, nonché di file imprevisti nella directory del sito web, nuovi cron jobs, scheduled tasks o account.
Huntress ha dichiarato che, al 20 ottobre, non aveva osservato attività di exploitation negli ambienti dei partner, non aveva creato né riprodotto un proof of concept e non era a conoscenza di exploit code pubblico. Analogamente, watchTowr non indicava alcuna exploitation segnalata al 21 ottobre e affermava che le vulnerabilità non erano presenti nel Known Exploited Vulnerabilities catalog della US Cybersecurity and Infrastructure Security Agency. Questo stato potrebbe cambiare dopo la pubblicazione dei dettagli tecnici. A titolo di confronto, Akamai ha rilevato tentativi di sfruttare CVE-2024-4577, una vulnerabilità PHP distinta che interessa il CGI mode su Windows, contro i propri sistemi honeypot entro 24 ore dalla divulgazione pubblica della vulnerabilità nel giugno 2024.
La release ufficiale avrebbe dovuto chiarire quali versioni sono vulnerabili, quale componente PHP è coinvolto, se l'exploitation dipende da una specifica modalità operativa, configurazione o login e quali release contengono le correzioni. I proprietari di siti web dovrebbero chiedere al proprio hosting provider o amministratore di confermare il branch PHP installato e lo stato dell'aggiornamento, anziché affidarsi a un intervallo di versioni non verificato. Per i proprietari di siti WordPress che cercano una gestione professionale, AEU Hosting offre managed WordPress hosting protetto end to end. Fino alla pubblicazione del vendor advisory definitivo da parte di PHP, l'esatta esposizione rimane incerta, ma le installazioni PHP non supportate richiedono già un aggiornamento o l'isolamento, poiché non possono ricevere una correzione dal vendor.