CVE-2024-1856 is a high severity (CVSS 8.5) insecure deserialization flaw in Progress Telerik Reporting that a remote attacker can use to run code. Versions before 2024 Q1 (18.0.24.130) are affected. Progress says updating to 18.0.24.305 or later is the only way to remove it.
What's affected
Progress Telerik Reporting 2024 Q1 (18.0.24.130) and older. The record says versions prior to 2024 Q1 (18.0.24.130) are affected.
Progress's knowledge base article covers CVE-2024-1801 and CVE-2024-1856 together. It says that updating to at least Reporting 2024 Q1 (18.0.24.305) is the only way to remove the vulnerability. As with Report Server, 18.0.24.130 is the last vulnerable build named and 18.0.24.305 is the first fixed build named.
The weakness is CWE-502, deserialization of untrusted data. The record describes this variant as a code execution attack by a remote threat actor. Progress adds a qualifier: in the case of CVE-2024-1856, it may be possible to use the flaw remotely in a special set of circumstances, in a misconfigured web application. So application configuration affects how reachable it is.
The qualifier from Progress is worth reading twice. A correctly configured application may be harder to attack, but you should not rely on configuration to protect an old library when the upgrade is available.
How to check if you're exposed
Telerik Reporting is a library that ships inside your own application, so the version sits in your dependencies. The Progress article gives two ways to read it.
If your application exposes the Reporting REST service, the version is available at the /api/reports/version/ endpoint of that service. If you only use the desktop tooling, open Settings, Apps, Installed apps on the machine and expand the Telerik Reporting item.
For code projects, search your NuGet references:
dotnet list package | findstr /i Telerik.Reporting
grep -ri "Telerik.Reporting" --include=*.csproj .
Check every solution that builds reports, including internal tools. These libraries get copied into many projects and tend to stay on old versions.
What to do now
- List every project that references Telerik Reporting and note the version.
- Upgrade to 2024 Q1 (18.0.24.305) or later by following the Telerik Reporting upgrade documentation for your starting version.
- Rebuild and redeploy each application that bundles the library.
- Review the web configuration of any app that exposes the Reporting REST service and keep it off untrusted networks until it is patched.
- Re-scan afterwards to confirm no old copy of the library remains in build outputs or container images.
Why it matters
Insecure deserialization turns data into running logic. When a web application accepts data from the network and rebuilds objects from it, an attacker who controls the data can influence which code runs. Progress notes the remote path depends on a misconfigured web application, which means the weak point is the combination of library and setup.
For defenders, that makes inventory the hard part. Many teams do not know which web apps expose a Reporting service, and a misconfigured one can sit unnoticed for years. The upgrade removes the dependency on getting configuration right.
The record's Known Exploited Vulnerabilities flag is false, and I found no report of exploitation on the Progress page.
Quick check
How is this different from CVE-2024-1801?
This is the remote variant, with a score of 8.5. CVE-2024-1801 is the local one at 7.7. One upgrade fixes both.
Do I need a misconfiguration to be at risk?
Progress says the remote path may work in a special set of circumstances in a misconfigured web application. Upgrade regardless of how confident you are in your configuration.
Sources
Last reviewed: 19 October 2026.
