Een padding-oracle RCE in Telerik UI voor ASP.NET AJAX heeft in korte tijd extra aandacht gekregen. Waar eerdere beveiligingsfixes al bestonden, is de volledige aanvalsketen pas recent publiek uitgelegd én voorzien van een werkende tool. Dat maakt het voor aanvallers eenvoudiger om de kwetsbare configuraties te herkennen en te misbruiken.
Progress heeft de problemen in juli gepatcht, maar de proof-of-concept van TantoSec toont dat het niet genoeg is om alleen een getroffen versie te draaien. De exploit werkt alleen wanneer specifieke, niet-standaard voorwaarden samenkomen. Er zijn tot nu toe geen bevestigde meldingen van misbruik in het wild.
Wat is de padding-oracle RCE precies?
In de kern draait de aanval om een padding oracle: een kwetsbaarheid die aan de serverzijde verschillende reacties uitlokt wanneer aanvallers gecodeerde of gemanipuleerde data aanbieden. Omdat de Telerik UI-component de client-side toestand versleutelt met AES-CBC zonder integriteitscontrole, kan de server bij foutieve invoer onderscheid maken tussen “correcte padding” en “niet-correcte padding”.
Dat ogenschijnlijke detail is in de praktijk waardevol. Het maakt het mogelijk om versleutelde configuratie-informatie te ontcijferen of te vervalsen zonder dat de aanvaller over de bijbehorende sleutel hoeft te beschikken.
Van padding oracle naar code-uitvoering
TantoSec beschrijft een keten die uiteindelijk uitkomt op remote code execution op de server die de kwetsbare applicatie host. De uiteindelijke code draait met de rechten van de IIS application pool.
De logica van de keten bestaat uit meerdere stappen:
- Decryptie of vervalsing via de padding-oracle op basis van serverreacties op getampereerde gegevens.
- Forging van de uploadconfiguratie, waardoor de component verder kan met een gemanipuleerde instelling.
- Type-resolutie zonder allowlist: een kwetsbaarheid waarmee een aanvaller een willekeurig .NET-type kan laten kiezen en vervolgens een geschikte deserialisatie-gadget kan activeren.
- DLL-gedrag bij laden: de gedemonstreerde payload is een mixed-mode assembly die native code kan uitvoeren zodra de DLL wordt geladen.
Volgens de beschrijving van TantoSec is de keten niet “instant”. In een lab kostte de end-to-end uitvoering ongeveer 127.000 oracle-verzoeken, grofweg een uur. Op servers met rate limiting kan dit langer duren.
Wanneer werkt het wél en wanneer niet?
Een belangrijk punt: het draaien van een getroffen Telerik UI-versie is op zichzelf niet voldoende. TantoSec meldt dat de aanval preconditions kent die niet door een standaardinstallatie worden gedekt.
De voorwaarden die genoemd worden:
- Een pagina moet een RadAsyncUpload-control renderen.
- De server-side handler moet het uploadresultaat verwerken.
- De applicatie moet zijn ingesteld met een expliciete, niet-standaard encryptiesleutel voor de control.
Progress geeft bovendien aan dat het gebruik van een sterkere custom sleutel dit specifieke oracle-probleem niet oplost, omdat de oracle-benadering niet afhankelijk is van het geheim zelf.
Voor sites die niet aan beide voorwaarden voldoen, is de aanval via deze keten niet exploiteerbaar.
Relevante versies en de fix van Progress
De keten wordt gekoppeld aan versies waarin de RadAsyncUpload-control voorkomt. Progress vermeldt dat getroffen versies lopen van 2010.1.309 tot en met 2026.2.519. De fix zit in 2026.2.708 (2026 Q2 SP1) en alle latere releases.
Progress heeft de problemen gefixt op 8 juli. Daarna volgden de publicatie van CVE’s en een advisory op 22 juli. Wat op 7 september veranderde, is de openbaarmaking van de volledige aanvalsmethode en tooling.
Waarom timing-changes nóg steeds helpen
Als een applicatie geen uitgebreide foutmeldingen toont, wil dat nog niet zeggen dat de oracle onbruikbaar wordt. Zowel voor de padding-oracle als voor een timing-gerelateerde variant beschrijft TantoSec dat het verschil in respons (bijvoorbeeld door timing) kan worden gelezen door een aanvaller.
In de beschrijving worden varianten genoemd waarbij de oracle ook af te leiden is uit response timing, zelfs wanneer standaard error output is afgeschermd.
Wat maakt de publieke tool extra relevant?
De impact van deze disclosure zit niet alleen in de kwetsbaarheden zelf, maar ook in wat nu beschikbaar is. TantoSec publiceerde een command-line tool (telerik-rau-exploit) en twee payloads:
- Een payload die een webshell op disk schrijft.
- Een payload die volledig in memory draait.
Die combinatie van uitgebreide uitleg met een “ready-to-run” aanpak kan de drempel voor misbruik aanzienlijk verlagen, ook al vereist de keten alsnog een specifieke niet-standaard configuratie.
Geen bevestigde aanvallen, maar let op gedrag
Er zijn geen bevestigde rapporten van exploitatie in het wild voor de 2026-gerelateerde kwetsbaarheden. Ook lijkt het (volgens de bronbeschrijving) niet te zijn opgenomen in CISA’s Known Exploited Vulnerabilities-catalogus op het moment van publicatie.
Een kanttekening blijft: Progress waarschuwt dat een succesvolle uitbuiting mogelijk geen duidelijke sporen achterlaat in standaard ASP.NET error logs. Daarom verschuift de focus naar gedrag en host-indicatoren, zoals:
- Het IIS-workerproces (w3wp.exe) dat onverwacht cmd.exe start.
- Een nieuw of onverwacht .aspx-bestand in de webroot.
- Een gemengde DLL die onder tijdelijke uploadlocaties of binnen App_Data wordt weggeschreven.
Wat kun je doen? Praktische maatregelen
De meest directe stap is updates toepassen. Progress adviseert om te upgraden naar Telerik UI for ASP.NET AJAX 2026.2.708 of later. Daarmee wordt de volledige chain gesloten door het probleem in het versleutelingsmechanisme aan te pakken.
Voor omgevingen waar upgraden niet direct kan, noemt Progress een reeks tijdelijke maatregelen. Deze maatregelen zijn bedoeld om ofwel de oracle-timingvariant te bemoeilijken, ofwel de kwetsbare functionaliteit uit te zetten:
- Set customErrors op RemoteOnly of On, zodat een aanvaller minder direct aan foutdetails kan komen en meer op timingvarianten is aangewezen.
- Disable de uploadhandler als RadAsyncUpload niet nodig is (via Telerik.Web.DisableAsyncUploadHandler = true).
- Verwijder of minimaliseer de custom encryptiesleutel zodat het control terugvalt op de ASP.NET machine key met AES en HMAC, of pas machine keys correct toe volgens een veilig proces.
Hoewel deze stappen niet hetzelfde niveau van bescherming bieden als volledig patchen, kunnen ze de kans op succesvolle uitbuiting aanzienlijk verkleinen.
Vergelijkbare risico’s: waarom dit niet “alleen maar patchen” is
Deze casus laat zien hoe belangrijk het is om verder te kijken dan alleen de aanwezigheid van een kwetsbaarheid. De exploit vereist namelijk een combinatie van kwetsbare code én een specifieke configuratie. Dat soort “aanvalsoppervlak door configuratie” zie je ook terug in andere incidenten rondom webcomponenten en supply chain-achtige risico’s.
Als je je defensieproces breder wilt maken, kan het helpen om te leren van eerdere patterns in applicatiebeveiliging. Bijvoorbeeld: waarom een cloud security checklist soms niet genoeg is en hoe je beter combineert tussen configuratie, logging en detectie.
Daarnaast is ook het detectie-denken relevant bij applicatie-aanvallen. Deze publicatie benadrukt dat je gedragssignalen moet monitoren in plaats van uitsluitend op typische fouten te vertrouwen.
Conclusie
De openbaarmaking van een padding-oracle RCE in Telerik UI voor ASP.NET AJAX verandert het speelveld: een werkende tool met payloads maakt de aanvalsketen concreter. Tegelijkertijd is het geen “plug-and-play” issue—de exploit werkt alleen onder specifieke niet-standaard voorwaarden rond RadAsyncUpload en encryptie-instellingen.
Voor organisaties die Telerik UI gebruiken is het advies helder: upgrade naar 2026.2.708 of later om de chain volledig te blokkeren. Kan dat niet meteen, neem dan de tijdelijke maatregelen om de kwetsbare functionaliteit te beperken en stuur op gedragsdetectie, niet alleen op error logs.
Bron: https://thehackernews.com/2026/09/telerik-ui-padding-oracle-bug-chained.html
