RadAsyncUpload encrypts its client-side upload configuration with AES-CBC and no integrity check, so the server answers tampered ciphertext differently depending on whether the decrypted bytes have valid padding or merely fail to parse as JSON [11]. That difference is CVE-2026-13182, and it lets an attacker read the blob without the key; because the control derives its encryption from a fixed seed, TantoSec turned reading into writing and forged a configuration of its own [12]. A forged configuration can name any .NET type. The control resolves the name with no allowlist, which is CVE-2026-13181, and deserializes it into a gadget that loads a DLL from a location the attacker controls [13]. The DLL is a mixed-mode assembly, so native code runs the moment it loads [14]. Where the application suppresses detailed errors, the oracle is still readable through response timing, tracked separately as CVE-2026-13183 [16].
None of that is quiet. TantoSec's end-to-end run took roughly 127,000 oracle requests, about an hour against a lab target and longer against a rate-limited server [15]. An hour for 127,000 requests is about 35 per second sustained against a single upload handler [3]. Rate limiting stretches the clock rather than closing the path [15], which makes request volume the practical detection surface for anyone whose change window is weeks out.
Version scanning gets you part way. The affected range is 2010.1.309 through 2026.2.519, with 2026.2.708 and later fixed [5], roughly sixteen years of releases in scope [4]. What the version does not tell you is which of those applications render a RadAsyncUpload control whose server-side handler reads the upload result, and which have an explicit encryption key set for the control [7]. That second condition is the awkward one, because setting the key is hardening Telerik recommends [8]. An affected install missing either condition is not exploitable through this chain [9].
The tooling landed 61 days after the fix shipped and 47 days after Progress published the CVEs [1][2]. Attack-surface vendor IONIX says on its site that it is tracking ongoing exploitation attempts, but supplies no dates or volumes and does not separate exploitation from ordinary internet scanning of the handler [18]. Treat that as unconfirmed until someone puts a date on it.
The handler's history is with older bugs. CVE-2019-18935, a deserialization flaw in the same component, was chained with a 2017 encryption weakness and used by ransomware crews and nation-state actors, including in a 2022 breach of a U.S. federal agency, and was still being exploited in 2025 [19]. CVE-2026-13181 is scored 8.1 with high attack complexity, and that rating describes the configuration prerequisites, not any difficulty once they are met [6]. For most affected estates the work is a version bump. For the subset with an explicit upload key, the work is finding them before someone else finishes 127,000 requests.
