Telerik RadAsyncUpload-Exploit-Kette ermöglicht Remote-Code-Ausführung

Sicherheitsforscher von TantoSec haben eine funktionierende Exploit-Kette für das Telerik UI for ASP.NET AJAX Webentwicklungs-Toolkit veröffentlicht, die es einem nicht authentifizierten Angreifer ermöglicht, beliebigen Code auf einem Hosting-Server auszuführen. Der Angriff zielt auf das RadAsyncUpload-Datei-Upload-Steuerelement ab, und Progress Software, dem Telerik gehört, hat die zugrunde liegenden Schwachstellen in Version 2026.2.708 am 8. Juli gepatcht. Die öffentliche Veröffentlichung am 7. September enthält einen detaillierten technischen Bericht, ein Befehlszeilentool namens telerik-rau-exploit und zwei Payload-Dateien, womit erstmals ein vollständiger Angriffspfad in die Hände der Öffentlichkeit gelangt. Die Kette funktioniert jedoch nur gegen Anwendungen, die zwei bestimmte nicht standardmäßige Bedingungen erfüllen, und es gibt keine bestätigten Berichte über aktive Ausnutzung in freier Wildbahn zum Stand vom 7. September.

Die betroffenen Versionen sind laut Progress-Advice 2010.1.309 bis 2026.2.519. Allein die Ausführung einer betroffenen Version reicht nicht aus, um angreifbar zu sein. TantoSec sagt, dass die Kette Vorbedingungen hat, die von einer Standardinstallation nicht erfüllt werden. Erstens muss eine Seite ein RadAsyncUpload-Steuerelement rendern, dessen serverseitiger Handler das Upload-Ergebnis liest. Zweitens muss die Anwendung mit einem expliziten, nicht standardmäßigen Verschlüsselungsschlüssel für das Steuerelement konfiguriert sein. Diese zweite Bedingung ist heikel, da Telerik tatsächlich empfiehlt, einen benutzerdefinierten Verschlüsselungsschlüssel als Härtungsmaßnahme zu setzen, was bedeutet, dass einige gut gemeinte Konfigurationen angreifbar sein können. Wenn beide Bedingungen erfüllt sind, ist das Ergebnis Codeausführung mit den Rechten des IIS-Anwendungspools, also des Teils der Microsoft-Webserver-Software, der den Code der Website ausführt.

Der Einstiegspunkt ist ein Padding-Oracle, das als CVE-2026-13182 verfolgt wird. Das Steuerelement verschlüsselt seinen clientseitigen Zustand mit AES-CBC, einer gängigen Verschlüsselungsmethode, fügt jedoch keine Integritätsprüfung hinzu. Infolgedessen reagiert der Server unterschiedlich auf manipulierte Daten, je nachdem, ob die entschlüsselten Bytes gültiges Padding haben oder nur als JSON fehlschlagen. Ein Angreifer kann diesen Unterschied nutzen, um die Upload-Konfiguration zu entschlüsseln und, unter Verwendung einer Technik, die TantoSec um den festen Verschlüsselungs-Seed des Steuerelements herum entwickelt hat, zu fälschen, ohne den Verschlüsselungsschlüssel zu kennen. Die gefälschte Konfiguration ermöglicht es dem Angreifer dann, einen beliebigen .NET-Typ zu benennen. Da das Steuerelement diesen Typ ohne Allowlist auflöst, hat die Schwachstelle CVE-2026-13181 einen CVSS-Score von 8,1, was im hohen Schweregradbereich liegt. Der aufgelöste Typ deserialisiert in ein Gadget, das eine DLL von einem vom Angreifer kontrollierten Ort lädt. Diese hochgeladene DLL ist eine Mixed-Mode-Assembly, das heißt, sie enthält sowohl verwalteten .NET-Code als auch nativen Maschinencode, und sie führt den nativen Code sofort beim Laden aus.

TantoSecs End-to-End-Demonstration benötigte etwa 127.000 Oracle-Anfragen, was etwa eine Stunde gegen ein Laborziel und länger gegen einen Server mit Ratenbegrenzung dauerte. Wenn die Anwendung detaillierte Fehlermeldungen verbirgt, kann das Padding-Oracle dennoch über das Antwortzeitverhalten ausgelesen werden, eine Variante, die als CVE-2026-13183 verfolgt wird. Die beiden veröffentlichten Payloads zeigen unterschiedliche Ziele: Eine schreibt eine Web-Shell auf die Festplatte, eine andere läuft vollständig im Speicher. Eine Web-Shell ist eine kleine Datei, die auf einem Server platziert wird und einem Angreifer über einen Webbrowser ein Hintertür-Kontrollpanel bietet. Die In-Memory-Version hinterlässt an dieser Stelle keine Datei.

Progress hat keine bestätigten Berichte über die Ausnutzung dieser 2026-Schwachstellen in freier Wildbahn gesehen, und keine erscheint im Katalog der Known Exploited Vulnerabilities der US-amerikanischen Cybersecurity and Infrastructure Security Agency zum Stand vom 7. September. Ein Anbieter für Angriffsflächenmanagement, IONIX, gibt auf seiner Website an, laufende Ausnutzungsversuche zu verfolgen, nennt jedoch keine Daten, Mengen oder andere Einzelheiten und unterscheidet nicht zwischen Ausnutzung und gewöhnlichem Internet-Scannen des Handlers. Die Komponente selbst hat eine lange Geschichte realer Angriffe, aber durch ältere Fehler, nicht durch diese. Eine Deserialisierungsschwachstelle von 2019 im selben Handler, CVE-2019-18935, wurde mit einer Verschlüsselungsschwäche von 2017 verkettet und von Ransomware-Banden und staatlichen Akteuren ausgenutzt, unter anderem bei einem Einbruch in eine US-Bundesbehörde im Jahr 2022, und wurde noch bis 2025 ausgenutzt. Diese Erfolgsbilanz ist der Grund, warum ein nicht authentifizierter Code-Ausführungspfad in diesem Handler Aufmerksamkeit erregt, obwohl die neuen Fehler keine bestätigte Ausnutzung haben.

Das Juli-Bulletin von Progress deckt tatsächlich zwei separate Angriffsketten ab. Die RadAsyncUpload-Kette, die TantoSec detailliert beschrieb, ist eine. Die andere ist eine separate Remote-Code-Ausführungskette in den Komponenten RadPersistenceManager und RadDockLayout, verfolgt als CVE-2026-13185, CVE-2026-13186 und CVE-2026-13190, die Markus Wulftange von CODE WHITE und Progress zugeschrieben wird. Für diese zweite Kette wurde kein öffentlicher Exploit veröffentlicht. Innerhalb der RadAsyncUpload-Kette betrifft ein vierter Fehler, der einen vorhersehbaren Standardschlüssel betrifft, CVE-2026-13184, nur einen alternativen Angriffsmodus, der in der veröffentlichten Demonstration nicht verwendet wurde.

Die primäre Lösung ist ein Upgrade auf Telerik UI for ASP.NET AJAX 2026.2.708 (2026 Q2 SP1) oder neuer, das das fehlerhafte AES-CBC-Schema durch authentifizierte Verschlüsselung ersetzt und die gesamte Kette schließt. Progress bezeichnet das Upgrade als seine einzige offizielle Empfehlung und warnt, dass ein stärkerer benutzerdefinierter Schlüssel nicht hilft, da das Oracle den Schlüssel nie benötigt. Für Websites, die nicht sofort aktualisieren können, listet Progress mehrere Zwischenschritte auf. Das Setzen von customErrors auf RemoteOnly oder On zwingt einen Angreifer auf die langsamere timing-basierte Variante. Das vollständige Deaktivieren des Upload-Handlers durch Setzen von Telerik.Web.DisableAsyncUploadHandler auf true ist angebracht, wenn RadAsyncUpload nicht benötigt wird. Das Entfernen eines benutzerdefinierten Verschlüsselungsschlüssels bewirkt, dass das Steuerelement auf den ASP.NET-Maschinenkey mit AES und HMAC zurückfällt, oder Administratoren können starke Maschinenschlüssel manuell generieren, anstatt sie zur Laufzeit zu erzeugen.

Da eine erfolgreiche Ausnutzung keine offensichtlichen Spuren in standardmäßigen ASP.NET-Fehlerprotokollen hinterlässt, sollten Verteidiger verhaltensbasiert jagen und nicht nach Fehlersignaturen. Das bedeutet, nach dem IIS-Arbeitsprozess (w3wp.exe) zu suchen, der cmd.exe startet, nach einer neuen oder unerwarteten .aspx-Datei im Web-Root oder nach einer Mixed-Mode-DLL, die im temporären Ordner des Upload-Steuerelements oder in App_Data geschrieben wurde.

Für Organisationen, die ältere .NET-Webanwendungen betreiben, kann ein sicherheitsorientierter IT- und Beratungspartner wie AEU-I helfen, betroffene Telerik-Steuerelemente zu inventarisieren und ein sicheres Upgrade zu planen, aber der offizielle Progress-Patch bleibt die einzige vollständige Lösung.

TantoSec meldete die Probleme am 22. Mai an Progress; der Fix wurde am 8. Juli ausgeliefert, und die CVEs folgten am 22. Juli. Almeida dankte seinem Kollegen Justin Steven für die Timing-Oracle-Variante.