CVE-2026-6023 is a high severity (CVSS 8.1) insecure deserialization flaw in the RadFilter control of Progress Telerik UI for ASP.NET AJAX, versions 2024.4.1114 through 2026.1.421. It matters when filter state is exposed to the client, such as in a cookie. Upgrade, or keep state server side.
What's affected
- Product: Progress Telerik UI for ASP.NET AJAX.
- Record: versions 2024.4.1114 through 2026.1.421.
- Component: only
RadFilteris affected, according to Telerik. Other controls that use the persistence framework, such as RadDock, RadGrid and RadScheduler, use safe deserialization. - Fixed: Telerik's knowledge base points to 2026 Q1 SP2 (2026.1.421) or later. The record lists 2026.1.421 as the end of the affected range, so confirm the exact build in the KB and install the newest release.
- Weakness: CWE-502, deserialization of untrusted data. CVSS 8.1 (high), vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
Telerik says it is exploitable only when the persisted filter state is exposed to an attacker. All of these must hold: RadFilter is on the page, RadPersistenceManager is on the page, a custom storage provider keeps state in a cookie (for example CookieStateStorageProvider), and LoadState() reads it back.
How to check if you're exposed
Start with the version of the Telerik assembly your web app ships, then look for the conditions above in your code.
# Version of the Telerik web assembly in a deployed app
powershell -Command "(Get-Item .\bin\Telerik.Web.UI.dll).VersionInfo.FileVersion"
# Where does your code use the vulnerable pattern?
grep -rn "RadFilter" --include=*.aspx --include=*.cs .
grep -rn "CookieStateStorageProvider\|LoadState" --include=*.cs .
If you have RadFilter but no cookie based storage provider, the stated prerequisites are not met. Do not stop there. Upgrade anyway, since a later code change could introduce the cookie provider.
What to do now
- Find every application that ships Telerik UI for ASP.NET AJAX and note the build.
- Upgrade to the fixed release named in Telerik's knowledge base article, or newer.
- If you cannot upgrade yet, switch the custom storage provider to one that keeps state server side (session, database or file system).
- Alternatively remove the custom provider so the default
AppDataStorageProvideris used. Telerik says it keeps state on the server file system. - Review any page that restores state from data a browser can edit.
Why it matters
Deserialization turns stored bytes back into objects. If an attacker can edit those bytes and the server trusts them, the server may build objects the attacker chose. This is CWE-502, and the record notes server side remote code execution is possible.
The design lesson is simple. State that the browser holds can be edited by the browser's owner. Keep it on the server, or sign and validate it. Telerik's own mitigation follows that advice. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Am I exposed if I use RadFilter with the default storage?
Telerik says the default AppDataStorageProvider keeps state on the server file system and is safe. Server side providers are not affected.
What is the quick mitigation?
Store filter state in the session, a database or the file system, or remove the custom cookie based provider.
Sources
Last reviewed: 19 October 2026.
