Tailscale espone i server a root: PHP2Shell alimenta nuovi attacchi mirati

🛡️ Executive Summary

• Tailworm documenta 11 problemi di sicurezza in Tailscale e headscale, compresi percorsi di escalation a root attraverso SSH forwarding, dimostrati in laboratorio ma non ancora associati ad attacchi reali.
• PHP2Shell è al centro di attività di scansione globale e di una campagna attribuita con moderata confidenza a operatori nordcoreani, con 216 obiettivi selezionati in settori strategici.
• Unit 42 ha ritirato l’attribuzione a PHP2Shell di un attacco contro un ente governativo europeo: la compromissione osservata non dimostra lo sfruttamento delle due CVE.

Tailscale SSH e PHP2Shell evidenziano due problemi differenti che possono convergere nella compromissione delle infrastrutture aziendali: l’accesso iniziale attraverso applicazioni web vulnerabili e la successiva possibilità di estendere il controllo ai sistemi interni. Il 25 ottobre 2026, la ricercatrice Erica Windisch di Cyberdione Labs ha pubblicato Tailworm, un rapporto che descrive 11 problemi di sicurezza in Tailscale e headscale, compresi percorsi capaci di ottenere privilegi root partendo da un dispositivo già compromesso. Contemporaneamente, le vulnerabilità PHP2Shell continuano ad attirare attività offensive su scala internazionale, con una campagna di ricognizione mirata individuata da CYFIRMA. La gravità delle due vicende richiede però una distinzione: le tecniche contro Tailscale sono state riprodotte in laboratorio, mentre per PHP2Shell esistono tentativi di sfruttamento osservati ma anche un’importante rettifica relativa a un presunto attacco governativo.

Tailworm sfrutta Tailscale SSH per raggiungere privilegi root

Il rapporto Tailworm pubblicato da Erica Windisch documenta un insieme di debolezze individuate attraverso verifiche condotte dal 22 al 24 ottobre sulle versioni Tailscale 1.104.2 e headscale 0.29.5. La criticità principale interessa il funzionamento di Tailscale SSH, componente che permette di stabilire connessioni amministrative tra dispositivi appartenenti alla stessa rete privata senza utilizzare necessariamente il tradizionale meccanismo di autenticazione SSH basato sulle chiavi dell’utente. Il sistema identifica infatti i dispositivi autorizzati e applica regole di accesso definite nel piano di controllo, semplificando le attività amministrative ma introducendo una dipendenza significativa dalla corretta separazione dei privilegi. Windisch ha dimostrato che, in particolari configurazioni nelle quali è consentito l’SSH port forwarding, un attaccante che controlla già un dispositivo autorizzato può abusare delle operazioni di inoltro verso socket Unix locali, ottenendo l’accesso a risorse che normalmente richiedono privilegi root. Il percorso è particolarmente delicato perché il processo tailscaled opera con autorizzazioni elevate e può quindi diventare un intermediario involontario tra una sessione SSH meno privilegiata e componenti amministrative del sistema operativo. Nei test sono stati documentati accessi a socket riservati, esecuzione di comandi privilegiati e acquisizione di informazioni sensibili. L’attacco non richiede necessariamente il furto della password root, ma presuppone il controllo di un dispositivo già autorizzato dalle regole della rete e la disponibilità del percorso di forwarding vulnerabile. Non si tratta quindi di una vulnerabilità che consente automaticamente a un aggressore anonimo su Internet di compromettere qualsiasi server Tailscale.

Un dispositivo compromesso può diventare la porta d’ingresso alla rete interna

La conseguenza più significativa della ricerca riguarda la possibilità di trasformare un accesso iniziale relativamente limitato in un movimento laterale attraverso altri dispositivi della stessa rete. Tailworm descrive una sequenza nella quale l’attaccante, dopo aver compromesso un endpoint legittimamente connesso, utilizza le autorizzazioni SSH disponibili per raggiungere altri server e tentare l’escalation dei privilegi. In laboratorio, Windisch ha verificato che alcune configurazioni permettono di estendere rapidamente il controllo ad altri sistemi accessibili, senza richiedere ulteriori credenziali amministrative. La ricercatrice definisce questo comportamento wormable, cioè potenzialmente propagabile attraverso i rapporti di fiducia esistenti tra i dispositivi; la definizione non deve però essere confusa con l’identificazione di un worm già diffuso nelle reti aziendali. Non risultano campagne reali documentate che utilizzino Tailworm, né una riproduzione pubblica indipendente dell’intera ricerca. Un’ulteriore tecnica sperimentata dalla ricercatrice sfrutta una condizione di time-of-check to time-of-use, nella quale il percorso verificato durante un controllo di sicurezza può essere modificato prima dell’effettivo utilizzo. Questa condizione ha permesso, nei test, di raggiungere materiale utilizzato per registrare nuovi dispositivi nella rete e, in assenza di Tailnet Lock, completare l’inserimento di un sistema controllato dall’attaccante. In presenza di Tailnet Lock, la ricerca descrive comunque la possibilità di intercettare informazioni sensibili, senza riuscire a completare il medesimo percorso di registrazione. Il problema richiama le conseguenze dei precedenti attacchi ai sistemi di amministrazione remota e alle piattaforme di accesso privilegiato, nei quali la compromissione di uno strumento considerato affidabile può produrre effetti superiori rispetto all’accesso iniziale.

Tailscale e headscale non hanno ancora una correzione per Tailworm

Al momento della pubblicazione della ricerca, non risultava disponibile una versione correttiva specifica per i problemi descritti da Tailworm, né erano stati assegnati identificativi CVE alle singole vulnerabilità. Tailscale ha riconosciuto pubblicamente di aver ricevuto il rapporto e di essere già impegnata nell’analisi di alcune delle aree interessate insieme a specialisti esterni. Mike Shaver, vicepresidente dell’ingegneria della società, ha precisato che il produttore sta valutando quali configurazioni siano realmente coinvolte e non raccomanda una disattivazione indiscriminata di Tailscale SSH. La differenza tra il servizio ufficiale e headscale, alternativa self-hosted per il piano di controllo, assume particolare importanza: secondo Tailworm, sul servizio gestito da Tailscale è possibile limitare il forwarding attraverso specifiche regole, mentre nella versione headscale 0.29.5 analizzata non sarebbe disponibile una restrizione equivalente. Il rapporto comprende inoltre problemi relativi agli app connector sperimentali, a tailscale serve, ai relay DERP e ad altri componenti dell’infrastruttura di comunicazione. In particolare, la ricercatrice sostiene che alcune configurazioni degli app connector possano consentire a un dispositivo autorizzato di raggiungere destinazioni non previste dalle policy, comprese risorse interne e servizi di metadati cloud potenzialmente contenenti credenziali. Queste conclusioni rimangono attribuite alla ricerca di Windisch, in assenza di una validazione pubblica indipendente di tutti gli scenari descritti. L’assenza di una patch rende comunque necessaria una verifica delle configurazioni effettivamente utilizzate, distinguendo i deployment che espongono i percorsi interessati da quelli che adottano restrizioni più granulari.

Leggi anche: AnyDesk Linux, exploit pubblico AnyPwn apre una RCE root pre-auth

PHP2Shell entra nel mirino di campagne mirate contro infrastrutture strategiche

L’altro fronte riguarda le vulnerabilità CVE-2026-109618 e CVE-2026-109619, due criticità PHP2Shell con punteggio CVSS 4.0 pari a 9,2, per le quali sono disponibili correzioni dal 21 ottobre. A differenza di Tailworm, queste vulnerabilità interessano direttamente il runtime delle applicazioni web e possono permettere esecuzione remota di codice senza autenticazione nei sistemi vulnerabili. La novità riguarda soprattutto il passaggio dalle scansioni opportunistiche alla selezione di obiettivi considerati strategici. La ricerca originale pubblicata da CYFIRMA descrive attività riconducibili a una presunta campagna nordcoreana che avrebbe utilizzato 21 nodi compromessi per esaminare infrastrutture PHP e identificare sistemi da colpire successivamente.

Gli obiettivi individuati comprendono 216 host distribuiti fra Stati Uniti, Europa, Giappone, Corea del Sud e altri Paesi asiatici e mediorientali, appartenenti a settori governativi, bancari, logistici, aeroportuali, manifatturieri e dei servizi finanziari online. La campagna viene descritta come un’operazione a basso volume, con rotazione dei nodi e progressiva selezione dei bersagli, caratteristiche che possono ridurre l’efficacia dei sistemi di rilevamento basati esclusivamente sul numero di richieste. CYFIRMA collega con moderata confidenza le attività a operatori di lingua coreana potenzialmente appartenenti all’ecosistema Lazarus, utilizzando elementi linguistici, canali I2P e analogie infrastrutturali. L’attribuzione non rappresenta una prova definitiva del coinvolgimento dello Stato nordcoreano, né dimostra che tutti gli host selezionati siano stati compromessi. L’evoluzione deve essere letta insieme alle precedenti rilevazioni sui tentativi di sfruttamento PHP2Shell iniziati prima della distribuzione delle patch, che avevano già mostrato una finestra di esposizione particolarmente delicata.

Palo Alto Networks ritira l’attribuzione a PHP2Shell dell’attacco governativo

La ricostruzione degli attacchi contro PHP2Shell presenta un punto particolarmente importante sul piano della correttezza delle informazioni. Palo Alto Networks Unit 42 aveva inizialmente associato alle vulnerabilità PHP2Shell un incidente che aveva coinvolto un’organizzazione governativa europea, nel quale gli attaccanti sarebbero riusciti ad accedere a hash di password e segreti di autenticazione multifattore entro due ore dall’accesso iniziale. Le attività osservate comprendevano inoltre ricognizione dell’ambiente Active Directory, tentativi di escalation verso privilegi Domain Admin e la creazione di un tunnel NTLM relay. Tuttavia, nell’aggiornamento del 25 ottobre 2026, Unit 42 ha ritirato la precedente attribuzione perché non è stato possibile dimostrare che l’accesso iniziale fosse stato ottenuto sfruttando specificamente CVE-2026-109618 oppure CVE-2026-109619. Il bollettino ufficiale aggiornato da Palo Alto Networks Unit 42 mantiene l’allarme sulle due vulnerabilità, ma separa le informazioni verificate dalle precedenti conclusioni sull’incidente governativo. L’attacco contro l’organizzazione europea non costituisce quindi una prova confermata di compromissione mediante PHP2Shell, nonostante l’iniziale associazione tra i due eventi. Questa distinzione riguarda anche le ipotesi sull’utilizzo dell’intelligenza artificiale durante le operazioni successive all’accesso: alcuni comandi osservati presentavano delimitatori e formati compatibili con elaborazioni automatizzate, ma l’aspetto non dimostra autonomamente che un agente AI abbia condotto l’intera intrusione. La rettifica non riduce la gravità delle vulnerabilità PHP, ma impedisce di trasformare un collegamento investigativo iniziale in un fatto definitivamente accertato.

PHP2Shell continua a generare scansioni e tentativi di sfruttamento

Nonostante la rettifica di Unit 42, le attività offensive contro PHP2Shell rimangono documentate attraverso altre rilevazioni. Cloudflare ha comunicato di aver osservato milioni di richieste riconducibili a tentativi di sfruttamento dopo la divulgazione delle vulnerabilità, mentre differenti operatori di sicurezza hanno segnalato sonde automatiche e tentativi di identificazione dei sistemi vulnerabili. Fra gli elementi analizzati compaiono richieste HTTP costruite per provocare particolari condizioni di errore nella gestione della memoria e controlli sulla funzionalità di avanzamento degli upload PHP. Quest’ultima è rilevante anche per CVE-2026-115560, terza vulnerabilità segnalata dopo le due RCE originarie e ancora priva di correzione alla data dell’allerta del CSIRT Italia. La rilevazione di richieste contenenti indicatori associati alla funzione PHP_SESSION_UPLOAD_PROGRESS non dimostra tuttavia automaticamente lo sfruttamento riuscito della terza vulnerabilità, perché possono trattarsi di tentativi di fingerprinting o di identificazione della configurazione del server. ReliaQuest ha inoltre descritto una sequenza di possibili evidenze individuate durante la riproduzione controllata di CVE-2026-109618, comprendente risposte HTTP 500, errori di esaurimento della memoria e anomalie dei processi Apache. Questi indicatori devono essere analizzati nel loro contesto: un singolo errore applicativo non equivale a una compromissione e l’assenza di anomalie evidenti non dimostra che un servizio sia sicuro. In Italia, la situazione è particolarmente rilevante perché il CSIRT Italia ha individuato 285.149 servizi PHP con versioni potenzialmente vulnerabili, corrispondenti all’81,9% delle installazioni per le quali è stata identificata la versione. Si tratta di una misura di esposizione e non di un conteggio delle compromissioni, ma conferma la necessità di completare rapidamente la verifica e l’aggiornamento delle infrastrutture.

Continua con:

PHP2Shell, 650 URL della PA a rischio: AWS rimuove le CA eMudhra

PHP2Shell, rilasciate le patch PHP contro due RCE senza autenticazione

Patch PHP e restrizioni SSH diventano prioritarie per le infrastrutture italiane

La gestione delle due emergenze richiede interventi differenti ma coordinati. Per PHP2Shell, la priorità resta l’installazione delle versioni corrette PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, verificando gli eventuali backport dei fornitori Linux e la reale versione caricata dai processi web. Le protezioni WAF costituiscono un livello aggiuntivo, non un’alternativa alla correzione del runtime, mentre la mitigazione della terza vulnerabilità richiede di verificare le particolari condizioni applicative e, quando necessario, disabilitare session.upload_progress.enabled. Per Tailscale SSH, in assenza di una patch specifica per Tailworm, gli amministratori devono invece verificare le policy di accesso, limitare le autorizzazioni a coppie esplicite di dispositivi sorgente e destinazione, disabilitare il port forwarding dove non indispensabile e controllare i servizi esposti attraverso socket Unix. L’utilizzo di SSH check mode, la scadenza delle chiavi dei dispositivi e la revoca degli endpoint compromessi dal piano di controllo possono aggiungere ulteriori barriere, senza eliminare necessariamente le vulnerabilità descritte dalla ricerca. Nei deployment headscale occorre considerare separatamente i limiti delle funzionalità di restrizione documentati per la versione analizzata. Per le organizzazioni italiane, comprese pubbliche amministrazioni, hosting provider e imprese che utilizzano accessi remoti per gestire server e ambienti cloud, il rischio più importante nasce dalla possibile combinazione tra compromissione iniziale e movimento laterale: un server web vulnerabile può fornire il primo accesso, mentre un sistema di amministrazione configurato con privilegi troppo ampi può amplificarne le conseguenze. Non esistono evidenze che PHP2Shell e Tailworm siano stati già concatenati in una campagna reale, ma la convergenza delle due superfici d’attacco dimostra quanto sia importante impedire che il controllo di un singolo endpoint si trasformi automaticamente nel controllo dell’intera infrastruttura. La differenza tra contenere un incidente e affrontare una compromissione estesa dipende soprattutto dalla granularità delle autorizzazioni, dalla rapidità degli aggiornamenti e dalla capacità di individuare tempestivamente gli accessi anomali.