Telerik Exploit Is Public: Check Your NC Web Portal

Does this apply to you? One question: did a software company build you a web application that people log into from outside the building? A customer portal, a dealer portal, a warranty lookup, an order status page, a quality dashboard. If no, you can stop here. If yes, or if you are not sure, keep reading, because as of today there is a public tool for breaking into a very common piece of those applications.

TL;DR: A security firm published a working exploit on September 7, 2026 for a flaw chain in Telerik UI for ASP.NET AJAX, a commercial parts kit that software vendors compile into the web applications they sell. The fix has existed since July 8, 2026 in version 2026.2.708, and the vendor bulletin came out July 22, so the patch has been sitting available for 61 days while almost nobody outside the software industry heard about it. Everything from version 2010.1.309 through 2026.2.519 is affected, which covers 16 years of releases. Finding out whether you are in scope takes about 20 minutes and does not require your vendor's help.

Why would a manufacturer in High Point care about a .NET parts kit?

Because you probably bought one without being told. Telerik UI for ASP.NET AJAX is a set of prebuilt web pieces, things like grids, upload boxes and date pickers, that software companies license so they do not have to build those pieces themselves. It ships as a file inside the application they hand you. You bought a dealer portal; you also bought Telerik, and it did not appear on the invoice.

That matters because four separate flaws in this exact product family reached CISA's exploited list between November 2021 and January 2023. CISA's Known Exploited Vulnerabilities catalog, the federal list of flaws with proven real-world exploitation, carries four Telerik UI for ASP.NET AJAX entries: CVE-2017-9248 and CVE-2019-18935 added November 3, 2021, CVE-2017-11317 added April 11, 2022, and CVE-2017-11357 added January 26, 2023. A fifth entry covers Progress Telerik Report Server, a separate product. Attackers know this component and have had tooling for it for years.

The honest status of the 2026 flaws: nobody has reported them exploited in the wild, and The Hacker News's September 7 report says so plainly. What changed today is that the research is public and so is a tool that turns it into a shell.

Key takeaway: You do not have a Telerik problem. You have an inventory problem, and Telerik is what made it visible this week. The question worth answering is not "are we running Telerik," it is "who here knows what is compiled into the software we bought."

One thing to do first: find out which of your applications came from a software vendor rather than from Microsoft. That list is the whole job, and most companies do not have it. If you want help building it, Preferred Data Corporation is at (336) 886-3282.

What is CVE-2026-13181 and what can someone actually do with it?

A file-upload box on an internet-facing page can be talked into running an attacker's code as your web server, with no login required. One caveat worth carrying upstairs: the flaw class needs no authentication, but the exploit the researchers released has preconditions, including a page that actually uses the upload control and a server-side handler that reads the upload result, so not every affected install is exploitable by the published tool. If that is all you need to act, skip to the next section.

For whoever runs your servers: Progress rated four flaws in the RadAsyncUpload control, with CVE-2026-13181 at CVSS 8.1 and CVE-2026-13182, CVE-2026-13183 and CVE-2026-13184 at 7.5, in its July 22, 2026 security bulletin. Three more, CVE-2026-13185, CVE-2026-13186 and CVE-2026-13190, sit in the RadPersistenceManager and RadDockLayout controls and were fixed in the same build. The chain is a padding oracle against encrypted upload configuration, fed into a deserialization gadget; TantoSec's September 7 write-up has the mechanics and the payloads.

What matters upstairs is the answer your vendor will give you, and whether it holds.

What the vendor may tell you	Why it does not settle it
"The application is behind a login"	It may help, and do not rely on it. The handler is often mapped application-wide, and no published source confirms that a login page blocks this chain. Check the version regardless
"We are on a supported version"	Supported is not patched. The fix is build 2026.2.708; anything from 2010.1.309 through 2026.2.519 is affected
"There is no evidence of exploitation"	True today. A public exploit tool now exists, and CVE-2019-18935 in this same library went from public research to CISA's exploited list, where it was added November 3, 2021
"We will pick it up in the next release"	Their release calendar is not your risk calendar. Ask for a date in writing and a workaround until then
"You would need our encryption key"	CVE-2026-13184 covers the case where the default key is predictable

How do I find out in 20 minutes, and what if I do not have the passwords?

Start with the check that needs nobody's permission.

Look at the page. Open the portal in a browser, view the page source, and use Ctrl-F for Telerik.Web.UI or RadAsyncUpload. If either appears, the component is in use. This works from any desktop and needs no credentials.
Read the version, if you can get on the server. In the application's bin folder, right-click Telerik.Web.UI.dll, choose Properties, then the Details tab. Anything below 2026.2.708 is in scope.

Step 2 is where most people in a 70-person plant stop, and the honest answer to why is that nobody in the building has the password. The server was racked by the software vendor in 2016, the credentials went to a contractor, and that contractor now answers on Wednesdays. That is not a personal failing; it is the default arrangement in most small manufacturers we walk into between Winston-Salem and Charlotte, and it is the actual finding. If step 2 is blocked, write down who you think holds those credentials. That name, or the absence of one, is worth more to you than the version number.

Then send the email. Do not phrase it as a question a support technician can close.

Subject: Telerik component version in [application name] - reply needed by [date]

Which version of Telerik UI for ASP.NET AJAX does our installation use?

1. Is it 2026.2.708 (2026 Q2 SP1) or later? Yes or no.
2. If no, what date will our installation be on 2026.2.708 or later?
3. Until then, which of the vendor's interim mitigations are applied to
   our instance?
4. Who at your company owns third-party component patching for our account?

Vendors answer that faster and more precisely when the version is already in the message, which is the practical reason to do the browser check first. Budget an hour to write them, and plan around the wait for a reply rather than assuming one comes back this week.

If you cannot patch immediately, Progress's bulletin lists interim hardening: set customErrors to RemoteOnly or On so error responses stop leaking, generate strong machine keys manually in IIS instead of accepting defaults, and disable the upload handler if the application does not use it. All three are a bridge. The vendor's own words: upgrading to the patched release is their only official recommendation.

Key takeaway: The browser check needs no credentials and no ticket, and it answers the only question that matters this week. Do it before you ask anyone for anything.

What should we watch for if the patch slips to October?

Assume it does, because for a vendor-controlled application that is a realistic outcome. TantoSec's own detection suggestions, which are the finder's and have not been independently validated, are at least specific enough to alert on rather than a general instruction to monitor.

Process lineage. As the researchers put it, w3wp.exe spawning cmd.exe "almost never happens in normal operation and is worth alerting on outright."
New files in the web root. Hunt for a new or off-schedule .aspx file where the application lives, and lock the web root so the application pool account cannot write there.
Odd DLL loads. A DLL under an upload temp path, or w3wp.exe loading one out of App_Data, is well off the normal path.

In our experience the server hosting a vendor-built customer portal is often the one machine in a Piedmont Triad plant with no endpoint detection on it, because the software vendor set it up, it sits in a corner of the rack, and it never reached anyone's asset list. The detection advice above is free to implement. What you have to arrange is somewhere for the alert to go at 2am, and that is ordinary managed IT and cybersecurity scope rather than a special project.

If you would rather hand this to someone: Preferred Data Corporation has been doing this work from High Point since 1987, which is 39 years of watching software vendors install something and stop thinking about it. We are 45 minutes from most Triad plants and go on-site within 200 miles, which covers Greensboro, Winston-Salem, Charlotte and Raleigh. 1208 Eastchester Drive, Suite 131, High Point, NC 27265. (336) 886-3282.

Who is actually responsible when a bought application gets breached?

You are, in every way that matters operationally, and the contract usually agrees. Your support agreement covers defects in what the vendor wrote. It almost never says anything binding about the components they bought and compiled in. Nobody lied to anybody; that obligation was never assigned to a person.

North Carolina carried roughly 449,300 manufacturing jobs in July 2026, per preliminary Bureau of Labor Statistics state data, and many of those employers are small and mid-sized firms running a line-of-business application bought years ago. The pattern repeats with unhelpful reliability: the vendor built it, installed it on a server in your building, moved on, and the annual maintenance invoice buys feature support, not component patching.

The fix is a single sentence at your next software renewal. Ask the vendor to name the third-party components in the product and commit to a patch window measured in days, in writing. It costs nothing at renewal and is close to impossible to get afterward, which is exactly why vendors would rather you asked afterward.

We will not attach a dollar figure to your building, because anyone quoting you an average breach cost for a 70-person manufacturer is selling something. The number swings by an order of magnitude on one question: can that portal server reach your ERP and your file server, or is it segmented off? A web server running an attacker's code on a segmented network is an expensive nuisance. The same server on a flat network is an incident with lawyers in it.

No provider, PDC included, can promise this never happens to you. A provider can make sure the server is on a list, the version is known, the patch has an owner, and somebody's phone rings when w3wp.exe does something strange. That is the job.

Monday move: Open a ticket titled "Telerik version check." Assign one person. The deliverable is a two-column list of every vendor-supplied web application you run and its Telerik.Web.UI.dll version, or a written "not present." Where the answer is "we cannot get on that server," write that down too. Inventory now; the list is the deliverable.

Questions NC owners are asking about this

How do I know if my application uses Telerik at all?

View the page source of the portal in any browser and search for Telerik.Web.UI or RadAsyncUpload. That check needs no credentials. On the server, the file is Telerik.Web.UI.dll in the application's bin folder, and its file version is in Properties, Details.

What version fixes it?

Telerik UI for ASP.NET AJAX 2026.2.708, labelled 2026 Q2 SP1, which The Hacker News reports shipped on July 8, 2026. Everything from 2010.1.309 through 2026.2.519 inclusive is affected, per Progress's July 22 bulletin.

Are these flaws being exploited right now?

Not yet, publicly. The exploit tool went public today, September 7, 2026, and the last four flaws in this component family all ended up on CISA's exploited list. You are early, not safe.

Our portal is only reachable from inside the plant. Does that help?

Meaningfully, because the flaw needs network reach to the upload handler. It does not make you safe: a phished laptop on the plant Wi-Fi is inside. Fix the version anyway, and confirm that "internal only" is still true, because internal-only applications have a habit of acquiring a port forward for one remote user and keeping it for six years.

Our software vendor says they will handle it. Is that enough?

Get a version number and a date in writing. "We are aware" is not a commitment and will not satisfy a cyber-insurance underwriter asking whether you track third-party components. A vendor who will not name a date has told you something useful about your next renewal.

We patched. Do we still need to look for a break-in?

If the application was internet-reachable and unpatched between July and now, spend the hour: check for unexpected .aspx files in the web root, unfamiliar processes spawned by w3wp.exe, and outbound connections from that server to places it has no business talking to. Patching closes the door. It does not tell you who came through it in August.

Nobody here can get on that server. What now?

That is the most common answer we get, and it is a finding rather than a dead end. Write down the application, the vendor, and who you believe holds the credentials, then make recovering that access the ticket. An application nobody can log into is also an application nobody can patch, back up or restore, and this flaw is simply the thing that made that visible. Our software development and PDC Software Suite teams untangle exactly this for North Carolina manufacturers. Call (336) 886-3282.