Die schwerwiegendste der Schwachstellen ist eine ungeschützte Typauflösung, geführt als CVE-2026-13181 mit einem CVSS-Wert von 8,1 („hoch"). Die als hoch eingestufte Angriffskomplexität spiegelt dabei die konfigurativen Voraussetzungen wider, nicht etwa eine technische Hürde bei der Ausnutzung selbst.
Denn eine verwundbare Version allein genügt nicht. Die Kette habe „Vorbedingungen, die von einer Standardinstallation nicht erfüllt werden", schreibt TantoSec: Eine Seite muss ein RadAsyncUpload-Steuerelement einbinden, dessen serverseitiger Handler das Upload-Ergebnis ausliest, und die Anwendung muss mit einem ausdrücklich gesetzten, nicht standardmäßigen Verschlüsselungsschlüssel für das Steuerelement konfiguriert sein — ausgerechnet eine Einstellung, die Telerik als Härtungsmaßnahme empfiehlt. Fehlt eine der beiden Bedingungen, ist die Anwendung über diesen Weg nicht angreifbar.
Wo sie erfüllt sind, endet die Kette in Codeausführung mit den Rechten des IIS-Anwendungspools. Einstiegspunkt ist ein Padding-Oracle (CVE-2026-13182): Das Steuerelement verschlüsselt seinen clientseitigen Zustand mit AES-CBC ohne Integritätsprüfung, sodass der Server auf manipulierte Daten unterschiedlich reagiert — je nachdem, ob die entschlüsselten Bytes ein gültiges Padding aufweisen oder lediglich nicht als JSON geparst werden können.
Über diesen Unterschied lässt sich die verschlüsselte Upload-Konfiguration entschlüsseln und, mit einer von TantoSec um den festen Verschlüsselungs-Seed des Steuerelements herum entwickelten Technik, auch fälschen — ohne den Schlüssel je zu kennen. Die Fälschung erlaubt es, einen beliebigen .NET-Typ zu benennen, den das Steuerelement ohne Positivliste auflöst (CVE-2026-13181) und zu einem Gadget deserialisiert, das eine DLL von einem angreiferkontrollierten Ort lädt. Diese Mixed-Mode-Assembly führt nativen Code aus, sobald sie geladen wird.
Schnell ist das nicht: Der Durchlauf von TantoSec benötigte rund 127.000 Oracle-Anfragen, etwa eine Stunde gegen ein Laborziel und länger gegen einen ratenbegrenzten Server. Blendet die Anwendung detaillierte Fehlermeldungen aus, lässt sich das Oracle über Antwortzeiten auslesen — eine als CVE-2026-13183 geführte Variante, für die Almeida seinem Kollegen Justin Steven dankt.
Der Anbieter IONIX gibt auf seiner Website an, „laufende Ausnutzungsversuche" zu beobachten, nennt aber weder Daten noch Mengen oder andere Details und unterscheidet nicht zwischen echter Ausnutzung und gewöhnlichem Scannen des Handlers im Internet. Dieselbe Komponente hat allerdings eine lange Angriffsgeschichte über ältere Fehler: Die Deserialisierungslücke CVE-2019-18935 wurde mit einer Verschlüsselungsschwäche von 2017 verkettet und von Ransomware-Gruppen wie auch staatlichen Akteuren ausgenutzt, unter anderem bei einem Einbruch bei einer US-Bundesbehörde im Jahr 2022 und noch 2025.
Das Progress-Bulletin vom Juli deckt zudem eine zweite, eigenständige Kette zur Codeausführung in den Komponenten RadPersistenceManager und RadDockLayout ab (CVE-2026-13185, -13186 und -13190), die Markus Wulftange von CODE WHITE und Progress zugeschrieben wird; dafür existiert kein öffentlicher Exploit. Ein vierter Fehler der RadAsyncUpload-Kette, ein vorhersagbarer Standardschlüssel (CVE-2026-13184), betrifft nur einen alternativen Angriffsmodus, den die Demonstration nicht nutzte.
Progress nennt das Upgrade auf 2026.2.708 oder neuer als einzige offizielle Empfehlung — die Version ersetzt das fehlerhafte AES-CBC-Verfahren durch authentifizierte Verschlüsselung. Ein stärkerer eigener Schlüssel helfe nicht, da das Oracle den Schlüssel gar nicht benötige. Weil erfolgreiche Ausnutzung laut Progress „keine offensichtliche Spur in den üblichen ASP.NET-Fehlerprotokollen" hinterlässt, sollten Verteidiger verhaltensbasiert suchen: der IIS-Arbeitsprozess w3wp.exe, der cmd.exe startet, neue oder unerwartete .aspx-Dateien im Web-Root oder eine Mixed-Mode-DLL im temporären Ordner des Upload-Steuerelements oder unter App_Data.
TantoSec meldete die Probleme am 22. Mai an Progress.