QVD-2026-57410 spiegata: come un Host contraffatto può portare alla RCE su DeepSeek Harness

QVD-2026-57410 è una vulnerabilità critica segnalata in DeepSeek Harness (DSH) 0.1.1-rc.2. I report collegati a QiAnXin la descrivono come una falla di esecuzione remota di codice senza autenticazione con punteggio CVSS 3.0 di 9,8. Il problema centrale è che il servizio può basare la decisione di fidarsi delle richieste dirette a /api su un header HTTP Host controllato dal client: un dato facilmente falsificabile, non un meccanismo di autenticazione. 1924

La gravità concreta dipende però dalla configurazione. Il comando web documentato da DeepSeek avvia l’interfaccia su 127.0.0.1:3080, limitando l’accesso remoto diretto. Il rischio aumenta sensibilmente quando il servizio viene pubblicato su un’interfaccia non locale o inoltrato tramite Docker, reverse proxy, tunnel, VPN, rete locale o ingress. 1118

Come funziona l’aggiramento tramite Host

Il design interessato prova a distinguere le richieste locali da quelle remote utilizzando le informazioni sull’host della richiesta. Il problema è che l’header Host viene fornito dal richiedente e può essere modificato a piacimento. Un attaccante in grado di raggiungere il servizio può quindi inviare un valore che sembri appartenere a una richiesta locale, inducendo il livello /api a considerarla attendibile. I report descrivono il meccanismo come un aggiramento del confine di fiducia basato sull’accesso dall’interfaccia di loopback. 1924

A un livello generale, la catena d’attacco riportata è questa:

1. Raggiungere un endpoint web o di gestione DSH esposto.
2. Inviare una richiesta con un header Host contraffatto, simile a quello previsto per l’accesso locale.
3. Superare la limitazione /api pensata per proteggere le operazioni interne.
4. Invocare funzionalità RPC riservate.
5. Registrare o utilizzare un percorso verso un provider di modelli controllato dall’attaccante.
6. Sfruttare le capacità dell’agente DSH per eseguire comandi sul sistema. 1920

Non si tratta quindi soltanto di un difetto di routing o di una semplice esposizione di informazioni: l’aggiramento può raggiungere funzioni progettate per gestire un agente AI dotato di capacità operative sul sistema.

Perché la falla può trasformarsi in RCE

DeepSeek definisce Harness un software sperimentale, in anteprima per sviluppatori, che non è stato sottoposto a un audit di sicurezza. L’avviso ufficiale precisa che il progetto può eseguire codice e comandi generati dal modello e accedere a rete, processi, credenziali e file messi a sua disposizione. 4

Il sottosistema LLM supporta inoltre la registrazione dei provider e la scoperta dei modelli, inclusa un’operazione remota denominata discoverModels. 23 Secondo la catena d’exploit descritta nei report, un provider controllato dall’attaccante può fornire l’input necessario a raggiungere le capacità di esecuzione dei comandi dell’agente. 19

Un exploit riuscito non garantirebbe automaticamente i privilegi di root. I comandi verrebbero eseguiti con i permessi dell’account o del processo che esegue DSH. Tali permessi potrebbero comunque bastare per leggere o modificare file accessibili, usare credenziali o chiavi API disponibili, avviare processi, alterare dati applicativi o effettuare connessioni in uscita.

L’impatto finale dipende dalla distribuzione: per esempio, dai permessi sul filesystem, dall’eventuale uso di container privilegiati, dalla presenza di un socket Docker montato o dall’accesso a credenziali cloud. Le informazioni disponibili non dimostrano che ogni installazione comporti automaticamente la compromissione completa dell’host.

Quali installazioni sono più esposte?

Gli amministratori dovrebbero considerare come priorità di verifica le configurazioni in cui:

• DSH ascolta su 0.0.0.0 o su un altro indirizzo non appartenente alla loopback.
• Docker o un altro runtime di container pubblica la porta 3080 oltre il computer locale.
• Un reverse proxy inoltra l’API di gestione verso Internet o verso una rete locale non affidabile.
• Un tunnel, una VPN o un ingress rende il servizio raggiungibile da utenti non sottoposti a un’autenticazione forte.
• Il proxy accetta valori Host arbitrari o inoltra senza modificarli quelli forniti dal client.

Definire un servizio come “interno” non equivale a proteggerlo con un controllo di autorizzazione. Qualunque soggetto in grado di raggiungere l’endpoint e influenzare gli header rilevanti potrebbe tentare l’aggiramento.

PoC pubblico, stato CVE e prove di sfruttamento

Diversi report affermano che per QVD-2026-57410 sono pubblici materiali di proof of concept o dettagli tecnici. 192027 Questo aumenta l’urgenza delle misure di contenimento, ma la disponibilità di una PoC non costituisce di per sé una prova che una specifica installazione sia stata compromessa.

Le informazioni fornite indicano che, al momento della divulgazione, non erano stati osservati sfruttamenti su larga scala nel mondo reale e non risultavano collegamenti con attori o campagne note. 1924 Si tratta tuttavia di una fotografia limitata nel tempo, non di una garanzia di sicurezza. Le istanze esposte dovrebbero essere controllate per richieste anomale, registrazioni inattese di provider, nuovi processi e connessioni in uscita insolite.

QVD-2026-57410 è un identificativo QVD, non un identificativo CVE. Il codice numericamente simile CVE-2026-57410 riguarda invece una vulnerabilità distinta di escalation dei privilegi in MailerPress, secondo la voce NVD. 17

Cosa devono fare gli amministratori

1. Eliminare subito l’esposizione di rete

Smettete di pubblicare su Internet il servizio DSH di gestione e API. Legatelo all’interfaccia di loopback o a una rete dedicata alla gestione; se serve l’amministrazione remota, utilizzate una VPN controllata o un bastion host.

2. Limitare l’accesso a ogni livello

Applicate regole di firewall, security group cloud, rete dei container e reverse proxy che consentano l’accesso soltanto a sorgenti esplicitamente affidabili. Non affidatevi a un percorso “interno” o a un header dall’aspetto locale come prova dell’identità del richiedente.

3. Validare e sovrascrivere gli header del proxy

Rifiutate all’ingresso i valori Host inattesi. Se il proxy deve inoltrare la richiesta, sostituite l’header upstream con un valore noto e fisso invece di trasmettere ciecamente quello del client. Considerate attendibili gli header relativi all’IP originario soltanto quando provengono da un proxy sotto il vostro controllo.

4. Aggiungere un’autenticazione indipendente da Host

Proteggete le operazioni di gestione e le RPC interne con autenticazione e autorizzazione reali, per esempio tramite un gateway con autenticazione forte, mTLS e controlli dei permessi per singola operazione. La validazione dell’header Host può contribuire al routing, ma non deve mai essere l’unico controllo d’identità.

5. Ridurre i rischi di discovery dei provider e di traffico in uscita

Disabilitate o limitate llm.discoverModels quando non è necessario. Se la scoperta dei provider è indispensabile, consentite soltanto endpoint autorizzati e applicate controlli sul traffico in uscita. Limitare l’accesso a destinazioni interne sensibili e ai servizi di metadati cloud può ridurre l’impatto di un eventuale abuso del percorso di discovery come primitiva di richieste lato server. La documentazione LLM di DSH conferma che la registrazione dei provider e la scoperta dei modelli sono funzionalità esposte. 23

6. Verificare la correzione nelle comunicazioni ufficiali

Le fonti disponibili identificano la versione 0.1.1-rc.2 come interessata e mostrano attività di rilascio successive, ma non stabiliscono che una specifica build successiva risolva questa vulnerabilità. Consultate le note di rilascio e gli avvisi di sicurezza aggiornati di DeepSeek per una correzione esplicitamente confermata prima di considerare sufficiente un aggiornamento. L’avviso ufficiale continua a definire Harness sperimentale e non pronto per la produzione. 410

7. Cercare tracce di compromissione e ruotare le credenziali

Esaminate i log del reverse proxy e di DSH alla ricerca di richieste /api anomale, valori Host falsificati che simulano l’accesso locale, registrazioni inattese di provider, avvii di processi, modifiche ai file e connessioni in uscita insolite. Ruotate le credenziali accessibili al processo DSH. Se emergono prove di esecuzione di comandi o persistenza, isolate e ricostruite l’host o il container interessato invece di presumere che un semplice riavvio abbia eliminato la compromissione.