CVE-2024-31849: CData Connect path traversal, unauthenticated admin access
The short version: CVE-2024-31849 is a path-traversal flaw in the Java version of CData Connect (before 23.4.8846) when it runs on the embedded Jetty server. By sending a request with traversal sequences, an unauthenticated attacker can reach administrative endpoints and gain complete administrative access to the application. There's a fix — update to 23.4.8846 or later. Steady hands, but patch.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — unauthenticated admin access, but a niche product and not KEV-listed |
| CVSS v3.1 (NVD) | Unknown at time of writing — NVD shows no NVD-assigned base score |
| CVSS (Tenable, CNA) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 6.08% · 92.59th percentile (2026-07-17) |
| In CISA KEV? | No |
| Known exploited? | Not confirmed in the wild; public proof-of-concept exists |
| Vulnerability type | CWE-22 path traversal → unauthenticated administrative access |
| Requires authenticated session? | No — pre-authentication |
| Affected | Java version of CData Connect < 23.4.8846 on the embedded Jetty server |
| Fixed in | 23.4.8846 (and later) |
What you need to know
The embedded Jetty server used by the Java build of CData Connect didn't properly constrain request paths, so traversal sequences in a crafted request reach administrative endpoints that should require authentication. The reporting researcher demonstrated retrieving settings without logging in, yielding full administrative access to the application.
- It's unauthenticated and network-reachable. No credential, no chain — just a crafted HTTP request.
- The prize is administrative control. CData Connect brokers access to data sources, so administrative access can reach configured connections and their credentials.
- It's part of a set. The same research covered related traversal issues in other CData products (API Server, Arc, Sync); if you run more than one, check them all.
How serious we see it
High. On mechanics alone — unauthenticated, remote, complete administrative access — this looks Critical, and the researcher's 9.8 reflects that. We land at High rather than Critical because there's no confirmed in-the-wild exploitation, it isn't in CISA's KEV catalog, and it affects a specialized data-connectivity product rather than a ubiquitous internet appliance. That's a prioritization nuance, not a reason to defer: if you run an affected CData Connect on the embedded Jetty server and it's reachable, treat it as urgent. The reassuring part is that it's bounded and fixed — a specific product and version, with a published update.
Recommendations
Straight from the vendor and the reporting advisory:
- Patch. Update CData Connect to 23.4.8846 or later.
- Check the rest of the CData suite. Review API Server, Arc, and Sync against their fixed versions from the same advisory.
- Restrict exposure. Keep CData management interfaces off the public internet or behind access controls until patched.
- If exposure predates the patch, rotate secrets. Assume configured data-source credentials could have been read, and rotate them.
- Confirm your exposure first. Verify whether you run the affected Java/Jetty build at all.
How BreachRisk sees it
BreachRisk discovers internet-facing services in your external footprint, fingerprints the product and version, and flags version-based exposures like this one. We identify and flag the affected CData build; we don't exploit it. A specialized data broker exposed on the internet is exactly the kind of asset that's easy to lose track of — the continuous outside-in view surfaces it as a ranked finding so the patch gets prioritized before someone walks in through it.