L'exploit pubblico di Telerik RadAsyncUpload concatena un padding oracle e porta all'esecuzione di codice remoto senza autenticazione

Una catena di exploit funzionante contro Progress Telerik UI for ASP.NET AJAX è stata resa pubblica il 7 settembre 2026, trasformando diverse vulnerabilità di RadAsyncUpload in un'esecuzione di codice remoto senza autenticazione.

La società di sicurezza TantoSec ha pubblicato lo strumento da riga di comando telerik-rau-exploit insieme a due payload DLL mixed-mode. Uno scrive una web shell sul server bersaglio, mentre l'altro viene eseguito interamente in memoria.

L'attacco non è universale. Oltre a una versione vulnerabile di Telerik, richiede una specifica configurazione applicativa non predefinita. Tuttavia, quando queste condizioni sono presenti, un attaccante senza autenticazione può recuperare o falsificare metadati di upload crittografati, selezionare un tipo .NET arbitrario e fare in modo che IIS carichi codice malevolo.

Progress ha corretto la catena in Telerik UI for ASP.NET AJAX 2026.2.708, identificato anche come 2026 Q2 SP1. La versione è stata rilasciata l'8 luglio, prima della pubblicazione delle CVE e dell'advisory, avvenuta il 22 luglio.

L'exploit richiede tre condizioni di distribuzione

Progress identifica come interessate dalla catena di RadAsyncUpload le versioni di Telerik UI for ASP.NET AJAX dalla 2010.1.309 alla 2026.2.519. La versione 2026.2.708 e quelle successive contengono la correzione.

NVD indica in modo più ampio CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 e CVE-2026-13184 come vulnerabilità che interessano le versioni precedenti alla 2026.2.708.

L'utilizzo di una versione vulnerabile non è sufficiente per eseguire l'exploit pubblicato. Secondo TantoSec, devono essere presenti tutte e tre le condizioni seguenti:

• L'applicazione visualizza un controllo RadAsyncUpload.
• Il codice applicativo lato server legge o elabora in altro modo il risultato dell'upload.
• Il controllo utilizza una chiave di crittografia configurata esplicitamente e non predefinita.

Il requisito della chiave personalizzata è significativo, perché Telerik ha raccomandato impostazioni di crittografia personalizzate come misura di rafforzamento. La semplice rotazione della chiave o la sua sostituzione con un valore più robusto non blocca questo attacco: il padding oracle opera senza dover conoscere la chiave.

Le applicazioni prive di uno dei due comportamenti applicativi richiesti non sono sfruttabili attraverso la catena pubblicata per RadAsyncUpload. Gli amministratori dovrebbero quindi verificare l'utilizzo effettivo dei controlli e la configurazione, anziché affidarsi esclusivamente agli inventari dei pacchetti.

L'attacco genera inoltre un volume di traffico considerevole. Un'esecuzione completa in laboratorio ha richiesto circa 127.000 richieste all'oracle e circa un'ora. Il rate limiting o un'infrastruttura di produzione più lenta potrebbero prolungare ulteriormente questo periodo, creando una possibile opportunità di rilevamento.

Come il padding oracle porta all'esecuzione di codice

RadAsyncUpload protegge lo stato lato client con AES in modalità CBC, ma non aggiunge un meccanismo di integrità in grado di rilevare la manipolazione del testo cifrato prima dell'elaborazione.

Quando un server riceve metadati crittografati modificati, il comportamento varia a seconda dell'esito. I dati con padding crittografico non valido seguono un percorso, mentre quelli che superano la validazione del padding ma non vengono elaborati correttamente durante il parsing JSON ne seguono un altro.

Questa differenza crea un padding oracle. Modificando ripetutamente il testo cifrato e osservando le risposte dell'applicazione, un attaccante può dedurre informazioni sui metadati di upload protetti.

La disattivazione delle risposte di errore dettagliate non elimina necessariamente il segnale. Le differenze nei tempi di elaborazione possono ancora rivelare se il padding è stato accettato, producendo l'oracle basato sui tempi tracciato come CVE-2026-13183. TantoSec ha attribuito questa variante a Justin Steven.

TantoSec ha inoltre sviluppato un metodo che utilizza il seed di crittografia fisso del controllo per falsificare una configurazione di upload crittografata senza recuperare la chiave di crittografia configurata. La configurazione risultante può impostare un tipo .NET scelto dall'attaccante.

RadAsyncUpload risolve questo tipo senza applicare una allowlist. L'oggetto viene quindi deserializzato in un gadget che recupera e carica una DLL da una posizione controllata dall'attaccante.

I payload pubblicati sono assembly mixed-mode contenenti componenti gestiti e nativi. Il codice nativo viene eseguito al caricamento della DLL, con l'identità e i permessi dell'application pool IIS. Di conseguenza, l'attaccante può accedere ai file dell'applicazione, ai segreti e ad altre risorse disponibili al processo worker.

Quattro CVE compongono la catena RadAsyncUpload pubblicata

Le vulnerabilità divulgate riguardano l'oracle crittografico, la falsificazione dei metadati e la fase finale di esecuzione del codice.

Vulnerabilità	Funzione nell'attacco	CVSS
CVE-2026-13181	L'elaborazione di AsyncUploadTypeName controllato dall'attaccante consente la risoluzione non sicura di tipi .NET e l'RCE	8,1
CVE-2026-13182	Errori distinti durante la decrittazione e l'elaborazione JSON espongono un padding oracle AES-CBC	7,5
CVE-2026-13183	Le differenze nei tempi di risposta mantengono attivo l'oracle anche quando gli errori dettagliati sono nascosti	7,5
CVE-2026-13184	Una chiave di integrità predefinita prevedibile può consentire la falsificazione dei metadati in una modalità di attacco alternativa	7,5

CVE-2026-13181 presenta il vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Il livello elevato di complessità dell'attacco riflette le condizioni di distribuzione necessarie, non la necessità di autenticazione o di interazione da parte dell'utente.

CVE-2026-13182 e CVE-2026-13183 presentano entrambe il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Forniscono primitive di divulgazione delle informazioni che supportano le successive manipolazioni.

CVE-2026-13184 presenta il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. Si applica quando Telerik.Upload.ConfigurationHashKey è assente e machineKey non è stato configurato esplicitamente, lasciando potenzialmente l'integrità dei metadati di upload dipendente da una chiave predefinita prevedibile. Questa modalità alternativa non è stata utilizzata nella dimostrazione pubblicata.

Anche un'altra catena RCE di Telerik ha ricevuto correzioni

Il bollettino di luglio di Progress ha inoltre corretto un percorso indipendente di RCE senza autenticazione che interessa le applicazioni che utilizzano l'archiviazione basata su cookie in RadPersistenceManager o RadDockLayout.

La catena comprende CVE-2026-13185, CVE-2026-13186 e CVE-2026-13190. Tutte e tre hanno un punteggio CVSS di 8,1 e il vettore CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-13185 riguarda la deserializzazione di contenuti dei cookie controllati dall'attaccante. Non sono note informazioni precise sulle versioni interessate, le classificazioni CWE o i dettagli tecnici relativi a CVE-2026-13186 e CVE-2026-13190.

La ricerca è stata attribuita a Markus Wulftange, ricercatore di CODE WHITE, e a Progress. Per questa seconda catena non è stato pubblicato alcun exploit.

Applicare prima la patch, poi cercare gli indicatori a livello IIS

La raccomandazione ufficiale di Progress è installare Telerik UI for ASP.NET AJAX 2026.2.708 o una versione successiva. L'implementazione corretta sostituisce la costruzione CBC vulnerabile con una crittografia autenticata e chiude l'intero percorso di RadAsyncUpload.

Quando l'installazione immediata non è possibile, Progress indica diverse misure temporanee:

1. Impostare customErrors di ASP.NET su RemoteOnly o On. In questo modo vengono nascoste le differenze esplicite negli errori, anche se gli attaccanti potrebbero comunque utilizzare il più lento oracle basato sui tempi.
2. Impostare Telerik.Web.DisableAsyncUploadHandler su true se RadAsyncUpload non è necessario.
3. Rimuovere la chiave di crittografia personalizzata per l'upload, consentendo al controllo di utilizzare una chiave macchina ASP.NET con AES e HMAC.
4. In alternativa, configurare manualmente chiavi macchina robuste invece di generarle durante l'esecuzione.

Questi controlli devono essere considerati misure temporanee di riduzione del rischio, non sostituti della versione corretta.

I log degli errori standard di ASP.NET potrebbero non fornire prove chiare di un exploit riuscito. I difensori dovrebbero analizzare la telemetria degli endpoint, del filesystem e delle richieste web alla ricerca di:

• w3wp.exe che avvia cmd.exe o altri processi figli imprevisti.
• File .aspx nuovi o modificati nella web root di un'applicazione.
• DLL mixed-mode presenti nelle directory temporanee di RadAsyncUpload.
• Creazione imprevista di DLL in App_Data.
• Richieste anomale persistenti verso l'handler di RadAsyncUpload.
• Lunghe sequenze di richieste compatibili con circa 127.000 sonde dell'oracle.
• Errori ripetuti relativi ai metadati crittografati o tentativi di analisi basati sui tempi di risposta.

Un payload eseguito in memoria potrebbe lasciare meno tracce sul filesystem, rendendo particolarmente rilevanti il comportamento del processo worker e la telemetria di rete.

Nessuno sfruttamento confermato nel 2026, ma Telerik ha una storia nel catalogo KEV

Al 7 settembre, nessuna delle vulnerabilità Telerik del 2026 descritte in questo articolo risultava nel catalogo Known Exploited Vulnerabilities di CISA. Non risultano inoltre segnalazioni confermate dell'utilizzo con successo della nuova catena nel mondo reale.

La società di attack-surface management IONIX afferma di monitorare tentativi di sfruttamento, ma non ha fornito date, volumi o prove tecniche che consentano di distinguere lo sfruttamento mirato dalla normale attività di scansione. L'affermazione non è verificata.

Il componente di upload di Telerik ha tuttavia una storia documentata di sfruttamento. CVE-2019-18935, una vulnerabilità critica di deserializzazione in RadAsyncUpload con un punteggio di 9,8, è entrata nel catalogo KEV di CISA il 3 novembre 2021. Alle agenzie federali statunitensi è stata assegnata una scadenza per la correzione del 3 maggio 2022, con l'indicazione di applicare gli aggiornamenti del fornitore.

La vulnerabilità precedente è stata utilizzata in campagne ransomware e da attori legati a Stati-nazione, anche in una violazione ai danni di un'agenzia federale statunitense nel 2022. Secondo quanto riferito, lo sfruttamento è proseguito fino al 2025. Questi incidenti non dimostrano lo sfruttamento delle nuove CVE, ma mostrano che gli handler Telerik esposti restano obiettivi interessanti.

Un'altra vulnerabilità associata a Telerik e Progress, CVE-2026-8037, è entrata nel catalogo KEV il 7 agosto 2026. La pubblicazione di un exploit completo per RadAsyncUpload offre ora ai difensori un ulteriore motivo per censire i controlli esposti e installare senza indugio la versione 2026.2.708.