CVE-2026-111613 is a High severity (CVSS 7.5) unauthenticated JDBC injection in AllData through 0.7.1. The data-dts test endpoint opens connections to caller supplied databases, which can lead to file reads on the host. We could not confirm a fixed version, so block access.
What's affected
The record says AllData through 0.7.1 is affected. The researcher write-up says it reviewed the alldata-release-0.7.1 tag, released on 10 October 2026, in the data-dts module. We found no fixed release, so check the alldatacenter/alldata repository.
The weakness is CWE-306, missing authentication for a critical function. Per the write-up, the data-dts service sets its HTTP security to permit every request and never registers the authentication filters that the project ships. One route, a POST to the JDBC datasource test path, accepts a datasource definition and opens a database connection with the caller's JDBC URL and driver class, with no validation.
The record says an attacker can point a MySQL JDBC URL, with the local infile option turned on, at a server they control, and read files from the data-dts host. The write-up also lists CWE-610 and CWE-798. Severity differs by source. The record gives 7.5 (High) and VulnCheck lists 8.7 on a CVSS 4.0 vector.
How to check if you're exposed
Find out whether you run the data-dts module of AllData and whether its port is reachable.
ss -ltnp | grep java
Match the listening ports against your deployment notes. If data-dts is reachable from outside the host or from untrusted networks, treat it as exposed. The record says the default configuration requires no authentication, so version alone is not the right test: any 0.7.1 or earlier deployment that you did not lock down is in range.
Check access logs for POST requests to the JDBC datasource test route from unknown clients. Check outbound connections from the host to unfamiliar database servers. The free in-browser dependency scan at gold.safeguard.sh/scan can match a manifest or lockfile against known CVEs without installing anything.
What to do now
- Restrict network access to data-dts with firewall rules, and place it behind an authenticating gateway or VPN.
- Block outbound database connections from the service host except to approved servers.
- Check the project for a fix and upgrade once you have confirmed one.
- Run the service under a user that cannot read keys, credentials or configuration beyond its own needs.
- If the service was exposed, treat files readable by its account as possibly copied and rotate credentials.
Why it matters
Letting a caller supply a JDBC URL is dangerous because database drivers have connection options that do more than connect, such as reading local files for a server. The server decides what the client sends back, so a hostile server can ask for files.
Combine that with a service that requires no login, and an anonymous caller gets a file read on the host. Data platforms collect credentials for many systems, so the files on those hosts are valuable. The record does not mark this CVE as known exploited, and none of the pages we read say it is.
Quick check
Does the attacker need to log in?
No. According to the record, the endpoint is reachable without authentication in the default configuration.
Is there a fixed version?
We could not confirm one. Check the alldatacenter/alldata repository.
Sources
Last reviewed: 18 October 2026.
