Öffentliche Telerik-RadAsyncUpload-Exploit-Kette führt über Padding Oracle zu unauthentifizierter RCE

Am 7. September 2026 wurde eine funktionierende Exploit-Kette gegen Progress Telerik UI for ASP.NET AJAX öffentlich veröffentlicht. Sie verwandelt mehrere Schwachstellen in RadAsyncUpload in eine unauthentifizierte Remote-Code-Ausführung.

Das Sicherheitsunternehmen TantoSec veröffentlichte gemeinsam mit dem Kommandozeilentool telerik-rau-exploit zwei Payloads in Form von Mixed-Mode-DLLs. Eine schreibt eine Webshell auf den Zielserver, während die andere vollständig im Arbeitsspeicher ausgeführt wird.

Der Angriff funktioniert nicht unter allen Umständen. Neben einer verwundbaren Telerik-Version ist eine bestimmte, nicht standardmäßige Anwendungskonfiguration erforderlich. Sind diese Voraussetzungen jedoch erfüllt, kann ein nicht authentifizierter Angreifer verschlüsselte Upload-Metadaten auslesen oder fälschen, einen beliebigen .NET-Typ auswählen und IIS dazu bringen, Schadcode zu laden.

Progress behob die Angriffskette mit Telerik UI for ASP.NET AJAX 2026.2.708, auch als 2026 Q2 SP1 bezeichnet. Die Version wurde am 8. Juli veröffentlicht – vor der Veröffentlichung der CVEs und des Advisories am 22. Juli.

Für die Ausnutzung müssen drei Bedingungen erfüllt sein

Progress stuft die Versionen 2010.1.309 bis 2026.2.519 von Telerik UI for ASP.NET AJAX als durch die RadAsyncUpload-Angriffskette gefährdet ein. Version 2026.2.708 und spätere Versionen enthalten die Fehlerbehebung.

NVD führt CVE-2026-13181, CVE-2026-13182, CVE-2026-13183 und CVE-2026-13184 allgemeiner als Schwachstellen in Versionen vor 2026.2.708.

Eine verwundbare Version allein reicht für den veröffentlichten Exploit nicht aus. Laut TantoSec müssen alle drei folgenden Bedingungen erfüllt sein:

• Die Anwendung rendert ein RadAsyncUpload-Steuerelement.
• Anwendungscode auf dem Server liest das Upload-Ergebnis aus oder verarbeitet es anderweitig.
• Das Steuerelement verwendet einen explizit konfigurierten, nicht standardmäßigen Verschlüsselungsschlüssel.

Die Anforderung eines benutzerdefinierten Schlüssels ist bemerkenswert, da Telerik benutzerdefinierte Verschlüsselungseinstellungen als Härtungsmaßnahme empfohlen hat. Das bloße Rotieren des Schlüssels oder Ersetzen durch einen stärkeren Wert verhindert diesen Angriff nicht: Das Padding Oracle funktioniert, ohne dass der Schlüssel selbst bekannt sein muss.

Anwendungen, bei denen eines der beiden erforderlichen anwendungsseitigen Verhaltensmuster fehlt, können über die veröffentlichte RadAsyncUpload-Kette nicht angegriffen werden. Administratoren sollten daher die tatsächliche Nutzung und Konfiguration der Steuerelemente prüfen und sich nicht ausschließlich auf Paketinventare verlassen.

Der Angriff erzeugt außerdem erheblichen Datenverkehr. Ein vollständiger Laborlauf erforderte rund 127.000 Oracle-Anfragen und dauerte etwa eine Stunde. Ratenbegrenzungen oder eine langsamere Produktionsinfrastruktur können diesen Zeitraum verlängern und dadurch eine mögliche Gelegenheit zur Erkennung schaffen.

Wie das Padding Oracle zur Codeausführung führt

RadAsyncUpload schützt den clientseitigen Zustand mit AES im CBC-Modus, ergänzt jedoch keinen Integritätsmechanismus, der Manipulationen am Chiffretext vor dessen Verarbeitung erkennen kann.

Wenn ein Server veränderte verschlüsselte Metadaten empfängt, unterscheidet sich sein Verhalten je nach Ergebnis. Daten mit ungültigem kryptografischem Padding durchlaufen einen anderen Pfad als Daten, die die Padding-Prüfung bestehen, aber beim Parsen des JSON-Formats scheitern.

Diese Unterscheidung erzeugt ein Padding Oracle. Indem ein Angreifer den Chiffretext wiederholt verändert und die Antworten der Anwendung beobachtet, kann er Informationen über geschützte Upload-Metadaten ableiten.

Das Deaktivieren detaillierter Fehlermeldungen beseitigt das Signal nicht zwangsläufig. Unterschiede bei der Verarbeitungszeit können weiterhin erkennen lassen, ob das Padding akzeptiert wurde. Dadurch entsteht das zeitbasierte Oracle, das als CVE-2026-13183 erfasst ist. TantoSec schreibt diese Variante Justin Steven zu.

TantoSec entwickelte außerdem eine Methode, mit der sich anhand des festen Verschlüsselungs-Seeds des Steuerelements eine verschlüsselte Upload-Konfiguration fälschen lässt, ohne den konfigurierten Verschlüsselungsschlüssel wiederherzustellen. Mit der daraus resultierenden Konfiguration kann ein vom Angreifer ausgewählter .NET-Typ festgelegt werden.

RadAsyncUpload löst diesen Typ auf, ohne eine Allowlist durchzusetzen. Das Objekt wird anschließend in ein Gadget deserialisiert, das eine DLL von einem vom Angreifer kontrollierten Speicherort abruft und lädt.

Bei den veröffentlichten Payloads handelt es sich um Mixed-Mode-Assemblies mit verwalteten und nativen Komponenten. Beim Laden der DLL wird nativer Code mit der Identität und den Berechtigungen des IIS-Anwendungspools ausgeführt. Der Angreifer kann dadurch möglicherweise auf Anwendungsdateien, Geheimnisse und andere Ressourcen zugreifen, die dem Workerprozess zur Verfügung stehen.

Vier CVEs bilden die veröffentlichte RadAsyncUpload-Angriffskette

Die offengelegten Schwachstellen betreffen das kryptografische Oracle, die Fälschung von Metadaten und die abschließende Phase der Codeausführung.

Schwachstelle	Funktion im Angriff	CVSS
CVE-2026-13181	Die Verarbeitung von angreifergesteuertem AsyncUploadTypeName ermöglicht eine unsichere .NET-Typauflösung und RCE	8.1
CVE-2026-13182	Unterschiedliche Fehler bei Entschlüsselung und JSON-Verarbeitung legen ein AES-CBC-Padding-Oracle offen	7.5
CVE-2026-13183	Unterschiede bei der Antwortzeit erhalten das Oracle auch dann, wenn detaillierte Fehlermeldungen verborgen werden	7.5
CVE-2026-13184	Ein vorhersehbarer Standardschlüssel für die Integrität kann in einem alternativen Angriffsmodus die Fälschung von Metadaten ermöglichen	7.5

CVE-2026-13181 hat den Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Die hohe Komplexität des Angriffs spiegelt die erforderlichen Bereitstellungsbedingungen wider, nicht die Notwendigkeit einer Authentifizierung oder einer Benutzerinteraktion.

CVE-2026-13182 und CVE-2026-13183 haben beide den Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Sie liefern Primitive zur Offenlegung von Informationen, die eine spätere Manipulation unterstützen.

CVE-2026-13184 hat den Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. Die Schwachstelle greift, wenn Telerik.Upload.ConfigurationHashKey fehlt und machineKey nicht explizit konfiguriert wurde. Dadurch kann die Integrität der Upload-Metadaten von einem vorhersehbaren Standardschlüssel abhängen. Dieser alternative Angriffsweg wurde in der veröffentlichten Demonstration nicht verwendet.

Eine separate Telerik-RCE-Kette wurde ebenfalls behoben

Progress behob in seinem Bulletin vom Juli außerdem einen unabhängigen Weg zu unauthentifizierter RCE. Betroffen sind Anwendungen, die in RadPersistenceManager oder RadDockLayout cookiebasierte Speicherung verwenden.

Diese Angriffskette umfasst CVE-2026-13185, CVE-2026-13186 und CVE-2026-13190. Alle drei haben einen CVSS-Wert von 8.1 und den Vektor CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.

CVE-2026-13185 betrifft die Deserialisierung von angreifergesteuerten Cookie-Inhalten. Genaue Informationen zu den betroffenen Versionen, CWE-Klassifizierungen und technischen Details zu CVE-2026-13186 und CVE-2026-13190 sind nicht bekannt.

Die Forschung wurde dem CODE-WHITE-Forscher Markus Wulftange und Progress zugeschrieben. Für diese zweite Angriffskette wurde kein öffentlicher Exploit veröffentlicht.

Zuerst patchen, dann nach Indikatoren auf IIS-Ebene suchen

Progress empfiehlt offiziell, Telerik UI for ASP.NET AJAX 2026.2.708 oder eine spätere Version zu installieren. Die korrigierte Implementierung ersetzt die verwundbare CBC-Konstruktion durch authentifizierte Verschlüsselung und schließt den vollständigen Angriffsweg über RadAsyncUpload.

Wenn eine sofortige Bereitstellung nicht möglich ist, führt Progress mehrere vorläufige Maßnahmen auf:

1. ASP.NET customErrors auf RemoteOnly oder On setzen. Dadurch werden eindeutige Unterschiede bei Fehlermeldungen verborgen, allerdings können Angreifer weiterhin das langsamere zeitbasierte Oracle verwenden.
2. Telerik.Web.DisableAsyncUploadHandler auf true setzen, wenn RadAsyncUpload nicht benötigt wird.
3. Den benutzerdefinierten Verschlüsselungsschlüssel für Uploads entfernen, damit das Steuerelement einen ASP.NET-Maschinenschlüssel mit AES und HMAC verwendet.
4. Alternativ starke Maschinenschlüssel manuell konfigurieren, anstatt sie zur Laufzeit zu generieren.

Diese Maßnahmen sollten als vorübergehende Risikoreduzierung betrachtet werden und nicht als Ersatz für die korrigierte Version.

Standardmäßige ASP.NET-Fehlerprotokolle liefern möglicherweise keine eindeutigen Hinweise auf eine erfolgreiche Ausnutzung. Verteidiger sollten Endpoint-, Datei- und Web-Request-Telemetrie auf folgende Anzeichen prüfen:

• w3wp.exe, das cmd.exe oder andere unerwartete Kindprozesse startet.
• Neue oder veränderte .aspx-Dateien im Webroot einer Anwendung.
• Mixed-Mode-DLLs in temporären Verzeichnissen von RadAsyncUpload.
• Unerwartete DLL-Erstellung unter App_Data.
• Anhaltende fehlerhafte Anfragen an den RadAsyncUpload-Handler.
• Umfangreiche Anfragesequenzen, die zu etwa 127.000 Oracle-Abfragen passen.
• Wiederholte Fehler bei verschlüsselten Metadaten oder Versuche, die gezielt auf eine zeitbasierte Analyse hindeuten.

Ein Payload, der ausschließlich im Arbeitsspeicher ausgeführt wird, hinterlässt möglicherweise weniger Spuren im Dateisystem. Dadurch werden das Verhalten des Workerprozesses und die Netzwerk-Telemetrie besonders relevant.

Keine bestätigte Ausnutzung im Jahr 2026, aber Telerik hat eine KEV-Vorgeschichte

Mit Stand vom 7. September 2026 war keine der hier beschriebenen Telerik-Schwachstellen aus dem Jahr 2026 im Katalog der bekannten ausgenutzten Schwachstellen von CISA enthalten. Außerdem gibt es keine bestätigten Berichte darüber, dass die neue Angriffskette in freier Wildbahn erfolgreich eingesetzt wurde.

Das Unternehmen für Angriffsflächenmanagement IONIX gibt an, Ausnutzungsversuche zu verfolgen, hat jedoch weder Zeiträume noch Mengenangaben oder technische Belege vorgelegt, die gezielte Angriffe von routinemäßigen Scans unterscheiden. Die Angabe ist weiterhin nicht verifiziert.

Die Upload-Komponente von Telerik kann allerdings auf eine dokumentierte Ausnutzungsgeschichte zurückblicken. CVE-2019-18935, eine kritische Deserialisierungs-Schwachstelle in RadAsyncUpload mit einem Wert von 9.8, wurde am 3. November 2021 in den KEV-Katalog von CISA aufgenommen. US-Bundesbehörden erhielten eine Frist zur Behebung bis zum 3. Mai 2022 und wurden angewiesen, die Hersteller-Updates einzuspielen.

Diese ältere Schwachstelle wurde bei Ransomware-Kampagnen und von staatlich unterstützten Akteuren eingesetzt, unter anderem bei einem Angriff auf eine US-Bundesbehörde im Jahr 2022. Die Ausnutzung soll bis ins Jahr 2025 angedauert haben. Diese Vorfälle belegen keine Ausnutzung der neuen CVEs, zeigen jedoch, dass exponierte Telerik-Handler weiterhin attraktive Ziele sind.

Eine weitere mit Telerik und Progress verbundene Schwachstelle, CVE-2026-8037, wurde am 7. August 2026 in den KEV-Katalog aufgenommen. Die Veröffentlichung eines vollständigen RadAsyncUpload-Exploits liefert Verteidigern nun einen zusätzlichen Grund, exponierte Steuerelemente zu inventarisieren und 2026.2.708 ohne Verzögerung zu installieren.