There's no vendor to patch this one. The vulnerable code is inside an app you built.

Most catalog entries have a clear remediation owner: the vendor ships a patch, you apply it. CVE-2017-11357 is different in a way that traps people. It’s a flaw in Telerik UI for ASP.NET AJAX, a set of web UI controls that developers compile into their own applications. The vulnerable code isn’t running in a product you bought and can update independently; it’s baked into web apps your team built and deployed, possibly years ago, possibly without anyone today remembering that Telerik is in the dependency list at all. There’s no vendor server to patch. You own the remediation, and that’s exactly why this bug has such a long, exploited tail.

What the bug is

CVE-2017-11357 is an arbitrary file upload / insecure direct object reference flaw (CWE-20) in Telerik’s RadAsyncUpload control, CVSS 9.8. User input reaches the upload handler without proper validation, letting a remote attacker upload files to a controllable location and, in the right conditions, achieve remote code execution. It affects all versions before R2 2017 SP2 (2017.2.711), and Telerik’s guidance is to upgrade the component. CISA added it to the Known Exploited Vulnerabilities catalog on January 26, 2023, with the ransomware flag.

It rarely travels alone. It’s part of a cluster of Telerik UI bugs, alongside CVE-2017-11317 (a hardcoded encryption key), CVE-2017-9248 (a cryptographic weakness), and CVE-2019-18935 (a .NET deserialization RCE). CISA’s advisory AA23-074A documented threat actors, including an APT, exploiting CVE-2019-18935 together with CVE-2017-11357 or 11317 against a federal agency’s IIS web server between November 2022 and January 2023. CISA described the affected component as “older, unpatched versions of Telerik released between 2007 and 2017,” which is the whole problem in one phrase.

Why “compiled in” changes everything

When a vulnerability lives in a product, your patch program can find it: scan the host, identify the version, apply the vendor update. When it lives in a component compiled into a custom application, that machinery mostly doesn’t apply, and several things go wrong at once:

• You may not know it’s there. Telerik was added by a developer during a project that shipped years ago. The current team inherited a binary, not a dependency list. Asset scanners see “a .NET web app,” not “a web app containing Telerik 2015.”
• There’s no auto-update and no separate patch. Fixing it means obtaining the updated Telerik assembly, rebuilding the application against it, regression-testing, and redeploying, a software-development task, not a patch-deployment task. For an app considered “finished,” nobody owns that work.
• The app outlives the knowledge. Line-of-business web apps run for a decade. The developer who chose Telerik is gone, the source may be poorly maintained, and “just rebuild it with a newer component” turns out to be a project.

That combination is why a 2017 bug was still breaching a federal agency in 2023. The fix existed for years; it just required someone to know Telerik was embedded and to rebuild the app, and no one did.

What to do

• Inventory your custom applications for embedded components, not just installed products. This is the hard prerequisite. You need to know which of your in-house and contractor-built web apps include Telerik (and other compiled-in libraries), and at what versions. Source-code and binary-composition analysis, not just host scanning, is what surfaces this.
• Update the Telerik assembly and redeploy. Get the component to a current, supported version (well past R2 2017 SP2) and rebuild the apps that use it. Treat it as the development work it is, and prioritize internet-facing apps first.
• If you can’t rebuild immediately, mitigate the control. Where the vulnerable RadAsyncUpload control isn’t needed, disabling it or restricting the upload handler reduces exposure. Telerik documented configuration hardening; treat it as a stopgap before the rebuild.
• Build software composition analysis (SCA) into your SDLC. The durable fix for this entire class is knowing your applications’ bill of materials continuously, so the next embedded-component CVE is a query, not an archaeology project. This is the same lesson Log4Shell taught for transitive dependencies, applied to the components your own developers chose.
• Assume compromise on long-exposed apps. Public exploits are ancient. An internet-facing ASP.NET app with old Telerik should be hunted for web shells and the w3wp worker spawning unexpected processes.

The reframe is about who’s responsible for the patch. For software you bought, the vendor writes the fix and you deploy it. For components compiled into software you built, you are the vendor, and the remediation is a build-and-redeploy that someone has to own. CVE-2017-11357 persisted for years because organizations treated it as someone else’s patch when it was their own application to fix. Know what’s compiled into your apps, because the bugs in there don’t get patched by anyone but you. We track the embedded-component entries because they’re the ones that fall through the gap between “our code” and “their product.”

Sources

• CISA Known Exploited Vulnerabilities Catalog
• CISA AA23-074A: Threat actors exploit Progress Telerik vulnerabilities in U.S. government IIS servers — 2023-03-15
• NVD CVE-2017-11357 — 2017-08
• Telerik: AsyncUpload insecure direct object reference — 2017
• FortiGuard: Multiple Progress Telerik UI vulnerabilities exploited in the wild — 2023