Telerik UI Padding-Oracle-bug gekoppeld aan niet-geverifieerde RCE – publieke exploit vrijgegeven

Een TantoSec ​​proof-of-concept verandert een AES-CBC “padding orakel” in Telerik UI voor ASP.NET AJAX in niet-geverifieerde uitvoering van externe code – maar alleen tegen applicaties in een specifieke niet-standaardconfiguratie, en Progress heeft de keten in juli gepatcht. Er zijn geen bevestigde meldingen van uitbuiting in het wild.

Beveiligingsbedrijf TantoSec heeft een werkende exploit-keten gepubliceerd die zich richt op kwetsbaarheden in Telerik-gebruikersinterface voor ASP.NET AJAX waarmee een niet-geverifieerde aanvaller externe code kan uitvoeren op de server waarop een kwetsbare applicatie wordt gehost.

Progress Software heeft de tekortkomingen in juli verholpen en voor exploitatie is een niet-standaardconfiguratie vereist. Maar de release combineert een gedetailleerde beschrijving met een kant-en-klare tool en twee payloads, waardoor een volledig aanvalspad voor het eerst in publieke handen komt.

De onderliggende tekortkomingen zijn niet nieuw. Progress heeft de oplossing op 8 juli in versie 2026.2.708 (2026 Q2 SP1) uitgebracht en op 22 juli de CVE’s en het advies gepubliceerd.

Wat op 7 september veranderde, is de onthulling van de methode en de tooling: Marcio Almeida van TantoSec ​​doorliep de volledige keten en bracht een opdrachtregelprogramma uit, telerik-rau-exploit, samen met twee mixed-mode DLL-payloads: één die een webshell naar schijf schrijft en één die volledig in het geheugen draait.

De keten beïnvloedt het RadAsyncUpload-bestandsuploadbeheer in de versies 2010.1.309 tot en met 2026.2.519, volgens het advies van Progress; 2026.2.708 en hoger zijn opgelost.

De ernstigste van de bugs is een onbewaakte fout in de typeresolutie die wordt gevolgd als CVE-2026-13181heeft een CVSS-score van 8,1 (“hoog”); de “hoge” aanvalscomplexiteitsclassificatie weerspiegelt de hieronder beschreven configuratievereisten en niet de problemen bij de exploitatie zodra hieraan is voldaan.

Het uitvoeren van een getroffen versie is niet voldoende om misbruikt te kunnen worden. TantoSec ​​zegt dat de keten “voorwaarden heeft waaraan niet wordt voldaan door een standaardinstallatie”: een pagina moet een RadAsyncUpload-controle weergeven waarvan de server-side handler het uploadresultaat leest, en de applicatie moet worden geconfigureerd met een expliciete, niet-standaard encryptiesleutel voor de controle – wat, in een twist, een instelling is die Telerik aanbeveelt als verharding. Sites op een getroffen versie zonder beide voorwaarden kunnen niet via deze keten worden geëxploiteerd.

Wanneer deze voorwaarden gelden, is de beloning het uitvoeren van code met de bevoegdheden van de IIS-toepassingsgroep. Het toegangspunt is een opvulorakel (CVE-2026-13182): omdat het besturingselement de status aan de clientzijde codeert met AES-CBC en geen integriteitscontrole, reageert de server anders op gemanipuleerde gegevens, afhankelijk van of de gedecodeerde bytes geldige opvulling hebben of alleen niet kunnen worden geparseerd als JSON.

Door dat verschil kan een aanvaller de gecodeerde uploadconfiguratie decoderen (en, met een techniek die TantoSec ​​heeft gebouwd rond het vaste encryptiezaad van het besturingselement, vervalsen) zonder ooit de sleutel te kennen.

Met dezelfde vervalsing kan de aanvaller een willekeurig .NET-type een naam geven, die door het besturingselement wordt omgezet zonder een toelatingslijst (CVE-2026-13181) en wordt gedeserialiseerd in een gadget dat een DLL laadt vanaf een locatie die de aanvaller beheert.

De geüploade DLL is een mixed-mode-assembly die native code uitvoert zodra deze wordt geladen. Het is niet onmiddellijk: de end-to-end-run van TantoSec ​​kostte ongeveer 127.000 orakelverzoeken – ongeveer een uur tegen een laboratoriumdoel, en langer tegen een server met beperkte snelheid.

Als de applicatie gedetailleerde foutmeldingen verbergt, kan het orakel nog steeds worden gelezen via responstiming, een variant die wordt bijgehouden als CVE-2026-13183.

Er zijn geen bevestigde rapporten dat de kwetsbaarheden uit 2026 in het wild worden uitgebuit, en geen daarvan verschijnt sinds 7 september in CISA’s Known Exploited Vulnerabilities-catalogus.

Eén leverancier van aanvalsoppervlakbeheer, IONIX, stelt op zijn site dat het “voortdurende exploitatiepogingen volgt”, maar geeft geen data, volumes of andere bijzonderheden, en maakt geen onderscheid tussen exploitatie en gewone internetscans van de handler.

Het onderdeel zelf heeft een lange geschiedenis van aanvallen in de echte wereld, maar door oudere bugs, niet door deze. Een deserialisatiefout uit 2019 in dezelfde handler, CVE-2019-18935, ging gepaard met een encryptiezwakte uit 2017 en werd uitgebuit door ransomware-ploegen en nationale actoren, onder meer bij een inbreuk op een Amerikaans federaal agentschap in 2022, en werd tot in 2025 nog steeds misbruikt.

Dat trackrecord is de reden waarom een ​​niet-geauthenticeerd code-uitvoeringspad in deze handler de aandacht trekt, ook al is er geen bevestigd misbruik van de nieuwe bugs.

Nog twee punten bepaalden het verhaal. Het julibulletin van Progress behandelt eigenlijk twee afzonderlijke aanvalsketens: de RadAsyncUpload-keten die TantoSec ​​gedetailleerd beschrijft, en een afzonderlijke keten voor het uitvoeren van code op afstand in de RadPersistenceManager- en RadDockLayout-componenten (CVE-2026-13185, -13186 en -13190), toegeschreven aan Markus Wulftange en Progress van CODE WHITE, waarvoor geen openbare exploit is vrijgegeven.

En binnen de RadAsyncUpload-keten is een vierde bug met betrekking tot een voorspelbare standaardsleutel (CVE-2026-13184) alleen van toepassing op een alternatieve aanvalsmodus die in de vrijgegeven demonstratie niet werd gebruikt.

Wat te doen

Upgrade naar Telerik UI voor ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) of hoger, die het gebrekkige AES-CBC-schema vervangt door geverifieerde encryptie en de hele keten sluit.

Progress noemt het upgraden van zijn enige officiële aanbeveling en waarschuwt dat een sterkere aangepaste sleutel niet helpt, omdat het orakel de sleutel nooit nodig heeft.

Voor sites die niet onmiddellijk kunnen upgraden, wijst Progress op verschillende tussenstappen:

• Stel customErrors in op RemoteOnly of On, waardoor een aanvaller wordt gedwongen de langzamere, op timing gebaseerde variant te gebruiken.
• Schakel de uploadhandler volledig uit (Telerik.Web.DisableAsyncUploadHandler ingesteld op true) als RadAsyncUpload niet vereist is.
• Verwijder eventuele aangepaste encryptiesleutels zodat de controle terugvalt op de ASP.NET-machinesleutel met AES en HMAC, of ​​genereer handmatig sterke machinesleutels in plaats van tijdens runtime.

Omdat Progress waarschuwt dat succesvolle exploitatie “geen duidelijk spoor achterlaat in de standaard ASP.NET-foutlogboeken”, moeten verdedigers eerder op gedrag jagen dan op foutsignaturen: het IIS-werkproces (w3wp.exe) dat cmd.exe voortbrengt, een nieuw of onverwacht .aspx-bestand in de webroot, of een mixed-mode DLL geschreven onder de tijdelijke map van het uploadbesturingselement of App_Data.

TantoSec ​​rapporteerde de problemen op 22 mei aan Progress; de oplossing werd op 8 juli verzonden en de CVE’s volgden op 22 juli. Almeida gaf collega Justin Steven de eer voor de timing-orakelvariant.