Catena di exploit Telerik RadAsyncUpload consente l'esecuzione remota di codice

I ricercatori di sicurezza di TantoSec hanno pubblicato una catena di exploit funzionante per il toolkit di sviluppo web Telerik UI for ASP.NET AJAX che può consentire a un attaccante non autenticato di eseguire codice arbitrario su un server di hosting. L'attacco prende di mira il controllo di upload file RadAsyncUpload, e Progress Software, che possiede Telerik, ha corretto le vulnerabilità sottostanti nella versione 2026.2.708 l'8 luglio. La pubblicazione pubblica del 7 settembre include una descrizione tecnica dettagliata, uno strumento da riga di comando chiamato telerik-rau-exploit e due file payload, mettendo per la prima volta un percorso di attacco completo nelle mani del pubblico. Tuttavia, la catena funziona solo contro applicazioni che soddisfano due specifiche condizioni non predefinite, e non ci sono segnalazioni confermate di sfruttamento attivo in natura al 7 settembre.

Le versioni vulnerabili sono dalla 2010.1.309 alla 2026.2.519, secondo l'avviso di Progress. Il semplice utilizzo di una versione affetta non è sufficiente per essere sfruttabili. TantoSec afferma che la catena ha prerequisiti che non sono soddisfatti da un'installazione predefinita. In primo luogo, una pagina deve visualizzare un controllo RadAsyncUpload il cui handler lato server legge il risultato dell'upload. In secondo luogo, l'applicazione deve essere configurata con una chiave di crittografia esplicita e non predefinita per il controllo. Questa seconda condizione è scomoda perché Telerik raccomanda effettivamente di impostare una chiave di crittografia personalizzata come misura di hardening, il che significa che alcune configurazioni ben intenzionate potrebbero essere vulnerabili. Quando entrambe le condizioni sono presenti, il risultato è l'esecuzione di codice con i privilegi del pool di applicazioni IIS, che è la parte del software del server web Microsoft che esegue il codice del sito web.

Il punto di ingresso è un padding oracle, tracciato come CVE-2026-13182. Il controllo crittografa il suo stato lato client usando AES-CBC, un metodo di crittografia comune, ma non aggiunge un controllo di integrità. Di conseguenza, il server risponde in modo diverso ai dati manomessi a seconda che i byte decifrati abbiano padding valido o semplicemente non riescano a essere analizzati come JSON. Un attaccante può usare questa differenza per decifrare la configurazione di upload e, usando una tecnica che TantoSec ha costruito attorno al seed di crittografia fisso del controllo, falsificarla senza mai apprendere la chiave di crittografia. La configurazione falsificata consente quindi all'attaccante di nominare un tipo .NET arbitrario. Poiché il controllo risolve quel tipo senza una lista consentita, la vulnerabilità CVE-2026-13181 ha un punteggio CVSS di 8.1, che è nell'intervallo di gravità alta. Il tipo risolto viene deserializzato in un gadget che carica una DLL da una posizione controllata dall'attaccante. Quella DLL caricata è un assembly in modalità mista, il che significa che contiene sia codice .NET gestito che codice macchina nativo, ed esegue il codice nativo appena viene caricato.

La dimostrazione end-to-end di TantoSec ha richiesto circa 127.000 richieste oracle, che hanno richiesto circa un'ora contro un target di laboratorio e più a lungo contro un server con limitazione di velocità. Se l'applicazione nasconde messaggi di errore dettagliati, il padding oracle può ancora essere letto attraverso i tempi di risposta, una variante tracciata come CVE-2026-13183. I due payload rilasciati mostrano obiettivi diversi: uno scrive una web shell su disco, e uno viene eseguito interamente in memoria. Una web shell è un piccolo file posizionato su un server che dà a un attaccante un pannello di controllo backdoor attraverso un browser web. La versione in memoria non lascia alcun file in quella posizione.

Progress non ha visto segnalazioni confermate di queste vulnerabilità del 2026 sfruttate in natura, e nessuna appare nel catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency degli Stati Uniti al 7 settembre. Un fornitore di gestione della superficie di attacco, IONIX, dichiara sul suo sito web che sta monitorando tentativi di sfruttamento in corso, ma non fornisce date, volumi o altri dettagli e non distingue lo sfruttamento dalla scansione internet ordinaria dell'handler. Il componente stesso ha una lunga storia di attacchi nel mondo reale, ma attraverso bug più vecchi, non questi. Una vulnerabilità di deserializzazione del 2019 nello stesso handler, CVE-2019-18935, è stata concatenata con una debolezza di crittografia del 2017 e sfruttata da gruppi ransomware e attori statali, incluso in una violazione del 2022 di un'agenzia federale degli Stati Uniti, ed è stata ancora sfruttata fino al 2025. Questo track record è il motivo per cui un percorso di esecuzione di codice non autenticato in questo handler attira l'attenzione, anche se i nuovi bug non hanno sfruttamento confermato.

Il bollettino di luglio di Progress copre in realtà due catene di attacco separate. La catena RadAsyncUpload dettagliata da TantoSec è una. L'altra è una distinta catena di esecuzione remota di codice nei componenti RadPersistenceManager e RadDockLayout, tracciata come CVE-2026-13185, CVE-2026-13186 e CVE-2026-13190, accreditata a Markus Wulftange di CODE WHITE e Progress. Nessun exploit pubblico è stato rilasciato per quella seconda catena. All'interno della catena RadAsyncUpload, un quarto bug che coinvolge una chiave predefinita prevedibile, CVE-2026-13184, si applica solo a una modalità di attacco alternativa che la dimostrazione rilasciata non ha utilizzato.

La correzione principale è aggiornare a Telerik UI for ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) o successiva, che sostituisce lo schema AES-CBC difettoso con crittografia autenticata e chiude l'intera catena. Progress definisce l'aggiornamento la sua unica raccomandazione ufficiale e avverte che una chiave personalizzata più forte non aiuta, perché l'oracolo non ha mai bisogno della chiave. Per i siti che non possono aggiornare immediatamente, Progress elenca diverse misure provvisorie. Impostare customErrors su RemoteOnly o On costringe un attaccante alla variante più lenta basata sui tempi. Disabilitare completamente l'handler di upload impostando Telerik.Web.DisableAsyncUploadHandler su true è appropriato se RadAsyncUpload non è richiesto. Rimuovere qualsiasi chiave di crittografia personalizzata fa sì che il controllo ripieghi sulla chiave macchina ASP.NET con AES e HMAC, oppure gli amministratori possono generare chiavi macchina forti manualmente piuttosto che in fase di esecuzione.

Poiché lo sfruttamento riuscito non lascia tracce ovvie nei log di errore ASP.NET standard, i difensori dovrebbero cercare comportamenti piuttosto che firme di errore. Ciò significa cercare il processo di lavoro IIS (w3wp.exe) che genera cmd.exe, un file .aspx nuovo o inaspettato nella radice web, o una DLL in modalità mista scritta nella cartella temporanea del controllo di upload o in App_Data.

Per le organizzazioni che eseguono applicazioni web .NET più vecchie, un partner IT e di consulenza incentrato sulla sicurezza come AEU-I può aiutare a fare un inventario dei controlli Telerik interessati e pianificare un aggiornamento sicuro, ma la patch ufficiale di Progress rimane l'unica correzione completa.

TantoSec ha segnalato i problemi a Progress il 22 maggio; la correzione è stata rilasciata l'8 luglio, e i CVE sono seguiti il 22 luglio. Almeida ha accreditato il collega Justin Steven per la variante dell'oracolo basata sui tempi.