Telerik UI: exploit RCE pubblico, chiave di cifratura diventa…

TantoSec ha rilasciato una catena di exploit completa per Telerik UI. La chiave di cifratura esplicita, raccomandata come hardening, è il prerequisito per l'attacco

Il 7 settembre 2026 TantoSec ha pubblicato una catena di exploit completa che trasforma un padding oracle crittografico in Telerik UI for ASP.NET AJAX in esecuzione remota di codice non autenticata. Il rilascio abbassa drasticamente la barriera all'attacco, ma nasconde un paradosso: l'exploit funziona solo contro le organizzazioni più diligenti, quelle che hanno seguito le raccomandazioni di hardening del vendor configurando esplicitamente una chiave di cifratura personalizzata. Progress Software aveva già corretto la vulnerabilità il 8 luglio 2026, quattro settimane prima della pubblicazione dei CVE e quasi due mesi prima dell'exploit pubblico.

Punti chiave

TantoSec ha rilasciato il tool telerik-rau-exploit con payload DLL mixed-mode per web shell su disco e in-memory
La catena sfrutta CVE-2026-13182 (padding oracle AES-CBC) e CVE-2026-13181 (unguarded type-resolution, CVSS 8.1) per RCE non autenticato
Il prerequisito decisivo è la chiave di cifratura esplicita Telerik.AsyncUpload.ConfigurationEncryptionKey, raccomandata da Telerik come misura di sicurezza
Progress Software ha patchato la vulnerabilità nella versione 2026.2.708 rilasciata l'8 luglio 2026; le versioni affette spaziano dalla 2010.1.309 alla 2026.2.519

Come funziona l'attacco: dal padding oracle alla shell

Il nucleo della catena è un padding oracle in AES-CBC senza meccanismo di integrità nella gestione della configurazione di upload. Secondo quanto documentato da TantoSec e riportato da The Hacker News, il server risponde in modo distinguibile a padding valido rispetto a padding invalido, permettendo la decrittazione byte-per-byte. Quando customErrors è attivato — configurazione comune negli ambienti di produzione — il discriminante diventa temporale: CVE-2026-13183 trasforma la differenza di timing in un oracle funzionale.

L'attaccante forza la configurazione di upload per aggirare le restrizioni sui tipi di file consentiti. La mancanza di allowlist nella risoluzione dei tipi .NET permette quindi una deserialization controllata. Secondo GBHackers, il gadget utilizzato è System.Configuration.Install.AssemblyInstaller con un Path controllato dall'attaccante: la DLL mixed-mode C++/CLI viene caricata e il codice nativo contenuto in DllMain esegue prima ancora dell'eventuale esecuzione managed. Il payload può operare da web shell persistente su disco o rimanere interamente in-memory.

La forgery crittografica impiega una tecnica specifica: un "sacrificial block" per inserire dati forgiati all'interno di un payload JSON in codifica UTF-16LE. L'intero processo richiede circa 127.000 richieste oracle, con un tempo stimato di circa un'ora in condizioni di laboratorio.

Il paradosso del hardening: chi si è protetto è più esposto

La configurazione vulnerabile non è quella di default. Secondo TantoSec, citato da The Hacker News, la catena ha "preconditions that are not met by a default installation". Servono tre elementi concomitanti: una pagina con il componente RadAsyncUpload, un handler server-side che legge la proprietà UploadResult, e — elemento decisivo — la chiave di cifratura esplicita Telerik.AsyncUpload.ConfigurationEncryptionKey configurata su valore non default.

Quest'ultimo requisito è il cuore del paradosso. La chiave personalizzata è una raccomandazione di hardening documentata da Telerik: le organizzazioni che l'hanno implementata per rafforzare la sicurezza si sono trasformate in target privilegiati. Progress Software ha esplicitamente avvisato che "a stronger custom key does not help, because the oracle never needs the key": la vulnerabilità risiede nel modo in cui il padding viene validato, non nella segretezza del materiale crittografico.

"A TantoSec proof-of-concept turns an AES-CBC 'padding oracle' in Telerik UI for ASP.NET AJAX into unauthenticated remote code execution — but only against applications in a specific non-default configuration, and Progress patched the chain in July." — The Hacker News

Timeline e contesto storico: una componente sotto tiro da anni

Il report di TantoSec a Progress Software risale al 22 maggio 2026. Il vendor ha rilasciato la patch il 8 luglio 2026 nella versione 2026.2.708 (2026 Q2 SP1), sostituendo AES-CBC con authenticated encryption. I CVE sono stati pubblicati il 22 luglio 2026. L'exploit pubblico è arrivato il 7 settembre 2026, circa sei settimane dopo la divulgazione coordinata.

Il componente RadAsyncUpload non è nuovo agli attacchi. CVE-2019-18935, con CVSS 9.8 Critical, è stato sfruttato attivamente da operatori ransomware e gruppi attribuiti a threat state-sponsored. La storia precedente rende la nuova catena particolarmente sensibile: le infrastrutture che non hanno aggiornato tempestivamente nel luglio 2026 si trovano ora con un exploit pubblico completo e verificato, in un componente già noto agli attaccanti per la sua profittabilità.

Marcio Almeida di TantoSec ha riconosciuto il contributo di Justin Steven per la variante timing-oracle. La ricerca, come riportato nel blog di TantoSec, è stata condotta "with some AI assistance, and a lot of old-fashioned human persistence".

Tracce e rilevamento: un attacco che sfugge ai log standard

Progress Software ha avvisato che "successful exploitation leaves no obvious trace in standard ASP.NET error logs". L'assenza di artefatti evidenti nei log convenzionali complica il rilevamento post-compromissione e impone approcci di hunting comportamentale: analisi delle sequenze di richieste ripetute contro endpoint di upload, monitoraggio del caricamento di DLL non previste, e correlazione di timing anomali nelle risposte del server.

Non emergono conferme di sfruttamento in-the-wild delle vulnerabilità CVE-2026-13181, CVE-2026-13182 e CVE-2026-13183 al 7 settembre 2026. IONIX ha dichiarato di tracciare "ongoing exploitation attempts" ma senza fornire dettagli verificabili.

Cosa fare adesso

Le organizzazioni che utilizzano Telerik UI for ASP.NET AJAX devono verificare immediatamente la versione in uso. Il range affetto è 2010.1.309 attraverso 2026.2.519: chiunque si trovi in questo intervallo e abbia configurato Telerik.AsyncUpload.ConfigurationEncryptionKey con valore esplicito è potenzialmente vulnerabile.

L'aggiornamento alla versione 2026.2.708 o successiva è l'unica raccomandazione ufficiale di Progress Software. Il vendor ha sostituito AES-CBC con authenticated encryption, eliminando la superficie d'attacco del padding oracle. Non è necessario — né utile — modificare la chiave di cifratura esistente: l'oracle non dipende dalla segretezza del materiale crittografico.

Per le infrastrutture dove l'aggiornamento immediato non è fattibile, il controllo della configurazione è essenziale. Verificare se esistono pagine con RadAsyncUpload dove l'handler server-side legge UploadResult e se customErrors è impostato su On, condizione che abilita la variante timing-oracle.

Il rilevamento deve concentrarsi su pattern comportamentali: sequenze di circa 127.000 richieste contro endpoint di upload, caricamenti di file DLL inattesi, e anomalie di timing nelle risposte del server. I team di sicurezza devono assumere che gli exploit pubblici per componenti con storia di sfruttamento attivo — come RadAsyncUpload — vengano adottati rapidamente da threat actor.

Chiusura editoriale

La catena TantoSec rappresenta un caso studio raro: una misura di hardening diventa prerequisito per l'attacco. Il paradosso non invalida le raccomandazioni di sicurezza, ma dimostra che la loro implementazione deve essere accompagnata da aggiornamento continuo. Progress Software ha corretto tempestivamente; la finestra di esposizione dipende ora esclusivamente dalla velocità di patching delle organizzazioni. Con CVE-2019-18935 già nella storia degli exploit attivi, il margine per l'inazione è azzerato.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter