Seven Telerik UI flaws chain into pre-auth code execution on ASP.NET servers

The chain starts at key material. Progress's stopgap checklist is almost entirely about three web.config values (Telerik.AsyncUpload.ConfigurationEncryptionKey, Telerik.Upload.ConfigurationHashKey, Telerik.Web.UI.DialogParametersEncryptionKey) and the ASP.NET machineKey that the components fall back on when those are absent ^[9]. One line in the checklist carries the weight: even a strong custom key will not prevent padding oracle attacks ^[10]. CWE-326, inadequate encryption strength, heads the weakness list, ahead of deserialization of untrusted data and path traversal ^[7]. The bulletin does not map any of the seven identifiers to a component or a weakness class, and it ships no proof of concept ^[19]. It also publishes no indicators of compromise and no detection guidance ^[23].

The silence claim is narrower than it first reads. Progress says exploitation is silent, produces no application errors visible to the owner, and leaves no obvious trace in standard ASP.NET error logs ^[5]. Error logging is one telemetry source. The bulletin makes no statement about IIS request logs, worker process behaviour, or files written under the site root ^[20]. Shops with request log retention reaching back before July 2026 can still run the question; shops whose only retention was application error logging have to go to file system state and endpoint telemetry instead.

For inventory purposes, the identifiers run CVE-2026-13181 through 13186 and then jump to CVE-2026-13190, leaving three numbers in the range that this bulletin does not account for ^[18], so a scanner feed match should expect seven entries rather than a contiguous block ^[17]. Version confirmation comes down to a single check: the assembly version of Telerik.Web.UI.dll in the project references ^[22].

The stopgap guidance forks, and the two paths do not sit well together. Option 2, offered specifically for web farm environments, drops the custom key in favour of machineKey, notes that machineKey is weaker than AES-GCM, and says the autogenerate keys at runtime setting can be used again ^[12]. The instruction block that follows says to generate keys manually in IIS, choose HMACSHA256 validation, and uncheck both automatic-generation boxes, flagged as very important, because autogenerating recreates the same HMAC guard collapse ^[13]. Both cannot be followed on the same site. The one with the warning attached is the one to follow, and either way Progress calls all of it temporary and says the upgrade to 2026.2.708 is the fix ^[3][8].