Apache IoTDB 2.0.11: Legacy Pipe RCE CVE-2026-59562 and Three More

On 21 October 2026 Apache IoTDB disclosed four vulnerabilities, all fixed in version 2.0.11. The headline issue, CVE-2026-59562, is a missing authentication check in the legacy pipe sendFile RPC that Apache titles remote code execution and unauthenticated path traversal. It affects IoTDB 2.0.0 up to 2.0.11. Upgrade servers and the JDBC driver to 2.0.11. No exploitation is reported.

This is a vulnerability disclosure, not a breach. As of the CISA Known Exploited Vulnerabilities catalog release of 23 October 2026 (version 2026.10.23), none of the four CVEs is listed, NVD shows all of them as "Awaiting Analysis" with no score, and we found no public proof of concept. Apache published severity words ("important" and "low") rather than CVSS scores, so any numeric score you see elsewhere did not come from the project.

The part worth slowing down for is the calendar. The fixed release, 2.0.11, went out on GitHub on 11 September 2026. The code change that appears to harden the legacy pipe file transfer path was merged on 29 May 2026. The advisories arrived on 21 October. Teams that watch CVE feeds rather than release notes were running a publicly fixed, unannounced bug for six weeks after the release and almost five months after the commit. That gap, and how to close it for a database that usually sits on a plant floor or an energy network rather than in a web stack, is the real story here.

What happened

The Apache IoTDB project management committee, through release manager Haonan Hou, sent four advisories to the oss-security mailing list and to dev@iotdb.apache.org within about half an hour on the morning of 21 October (UTC). The CVE Program records, assigned by the Apache Software Foundation, went live in the same window.

The four CVEs at a glance

Three of the four are server side and only touch the 2.0 line. The fourth sits in the JDBC driver, a library that ends up inside your own Java applications, and it reaches back to 1.3.3. That split matters for who has to act: database operators for the first three, application teams for the fourth.

Timeline

All times are UTC. Dates before October come from the GitHub repository and package registries; October times come from the mailing list headers and the CVE records.

Two notes on that table. First, the mapping between the May to July pull requests and the October CVEs is our reading of the public code history, not something Apache stated. The advisories link to no commits. The titles and descriptions line up closely, but treat the pairing as an informed inference. Second, there is no 2.0.9 release on GitHub; the 2.0 line went from 2.0.8 (13 April) to 2.0.10 (4 July).

Who is affected

IoTDB is a time-series database designed for device and sensor data. The project's own threat model describes it as operator-deployed infrastructure, written to by device data pipelines and read by analytics clients over the network, and meant to sit inside a trusted network. In practice that often means historians and telemetry stores in factories, utilities, building systems and fleets. Those networks are frequently flatter than the threat model assumes, with engineering laptops, remote access gateways and integration servers on the same segment as the database.

Where IoTDB hides

IoTDB is easy to miss in an inventory because it rarely arrives as a line in a package manifest:

• Docker images and Helm charts that pull apache/iotdb:latest or a floating 2.0 tag.
• Unzipped binary distributions such as apache-iotdb-2.0.x-all-bin running under systemd on an edge gateway.
• Edge deployments. Release 2.0.11 introduces an Edge Edition limited to 512 MB for the ConfigNode and DataNode combined, aimed at constrained devices. Older 2.0 builds may already be running on similar hardware with hand-tuned memory settings.
• Vendor platforms in industrial IoT and energy that bundle IoTDB as their storage layer.
• The JDBC driver inside dashboards, ETL jobs and reporting tools, which is where CVE-2026-41114 lives.

How the issues work

This section stays at the level Apache and the public code history describe. It contains no request formats or attack steps.

Background: what a pipe is, and what "legacy" means

IoTDB pipes move data between instances, for example from an edge node to a central cluster, or between two sites for backup. A sending IoTDB opens a connection to a receiving IoTDB and streams data and files to it. The 1.x series used an older sync protocol; the 2.0 series keeps a receiver for that older protocol so that 1.x senders can still deliver data to 2.0 receivers. That compatibility path is the "legacy pipe".

The detail that shapes every mitigation below: in the 2.0.10 Thrift definition of the client service (client.thrift, service IClientRPCService), the legacy methods handshake, sendPipeData and sendFile, and the newer pipeTransfer method, sit in the same service as ordinary client calls. That service listens on the DataNode client RPC port, dn_rpc_port, which defaults to 6667. You cannot firewall the pipe receiver separately from your normal clients on that port. Anyone who can reach port 6667 can reach these methods.

CVE-2026-59562: a file transfer method that did not check who was calling

Apache's description is a single line: missing authentication for a critical function. The title adds the impact words: remote code execution and unauthenticated path traversal in the legacy pipe sendFile RPC.

Pull request #17741, merged on 29 May, describes what it changed in that path, which gives a reasonable picture of what was wrong without needing any attack detail:

• The receiver now validates file names before any file input or output.
• It rejects empty names, path separators, parent directory references and normalised paths that land outside the receiver's file-data directory.
• It applies the same check when handling received TsFile pipe data.
• It requires an authenticated session holding the USE_PIPE privilege for the legacy handshake, sendFile and sendPipeData calls.

Read together with the advisory title, the plain-language summary is: before 2.0.11, a caller who could reach the client RPC port could ask the legacy receiver to write a file, without logging in, and the file name was not confined to the receiver directory. Writing attacker-chosen files to attacker-chosen places on a server is a well known route to code execution, which is presumably why Apache put "remote code execution" in the title. Apache has not published how code execution is achieved, and we will not speculate about it.

What this means for you: on an affected 2.0 server, the security of the host rests on who can open a TCP connection to port 6667. Passwords on IoTDB accounts do not help against this specific issue, because the vulnerable call did not ask for one.

CVE-2026-58663: an authentication bypass in pipeTransfer

pipeTransfer is the method the current pipe framework uses to deliver data between 2.0 instances. Apache describes the issue as "an authentication bypass vulnerability" in the Thrift RPC service, with the title naming the pipeTransfer() interface. There is no further public detail. The release history shows several pipe authentication changes between 2.0.10 and 2.0.11, including password check fixes for pipe sinks and session handling for the pipe receiver, but we could not tie a specific commit to this CVE with confidence, so we do not.

The practical meaning is the same as for CVE-2026-59562: the data ingestion path on port 6667 could be used by someone the server should have refused.

CVE-2026-59229: legacy pipe writes ran as root

This is the one with the most detailed advisory. The legacy receiver protocol executed its data loading and deletion operations under a hardcoded SUPER_USER identity, which is root in IoTDB. A user who held only a system-level privilege such as USE_PIPE or MAINTAIN, and who did not hold WRITE_DATA or DELETE_DATA on a database, could send pipe data through the legacy API and have the server load or delete data in that database as root. Apache's description calls this "effectively bypassing IoTDB's permission model entirely".

Pull request #18111, merged on 10 July, describes the matching change: the legacy loaders now use the session context supplied by the RPC request, so deletion and TsFile loading follow the caller's own permissions. It also stops the legacy receiver from registering databases during the handshake.

The practical point: if you granted USE_PIPE or MAINTAIN to a service account or an operator on the assumption that it could manage pipelines but not touch data, that assumption did not hold on 2.0.0 to 2.0.10.

CVE-2026-41114: a large number that fills the JDBC client's memory

This one is client side and low severity. The fix pull request (#17508) explains it in detail. A Java BigDecimal built from extreme scientific notation has an enormous negative scale. When the IoTDB JDBC driver converted such a value to a plain decimal string, Java tried to build a string roughly a billion characters long, about 2 GB, and the client process ran out of memory. The pull request says this was reachable when an application passed a user-controlled BigDecimal into a prepared statement as a string value.

The fix adds a guard: when the absolute scale exceeds 10,000, the driver falls back to the compact scientific form instead of the plain form. A 10,000 character string is about 10 KB, so ordinary data is unaffected.

Who should care: applications that take numeric input from users or from devices and write it to IoTDB through JDBC prepared statements. The impact is a crash of your application or worker process, not of the database server.

Technical details

Everything in this section was read in a fetched primary source: the Apache advisories, the CVE records, the GitHub release and pull requests, the repository source at tag v2.0.10, Apache's download server, Maven Central and Docker Hub.

Affected and fixed versions per CVE

The 2.0 releases published on GitHub inside the server range are 2.0.1-beta, 2.0.2, 2.0.2-1, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8 and 2.0.10. The JDBC range also covers 1.3.3, 1.3.4, 1.3.4-1, 1.3.5, 1.3.6 and 1.3.7. The advisories name no fixed 1.3.x driver; Apache's only recommendation is 2.0.11.

Severity and scoring

The CVE records carry only a "Textual description of severity" metric. If a scanner shows a CVSS base score for these CVEs, it came from a third party, not from Apache.

Code changes between 2.0.10 and 2.0.11 that match the advisories

GitHub's comparison of v2.0.10 and v2.0.11 shows 305 commits. The ones whose titles match the advisories:

No public commit is clearly labelled for CVE-2026-58663.

Where the vulnerable methods listen

From iotdb-protocol/thrift-datanode/src/main/thrift/client.thrift at tag v2.0.10, service IClientRPCService:

common.TSStatus handshake(TSyncIdentityInfo info);
common.TSStatus sendPipeData(1:binary buff);
common.TSStatus sendFile(1:TSyncTransportMetaInfo metaInfo, 2:binary buff);
TPipeTransferResp pipeTransfer(TPipeTransferReq req);
TPipeSubscribeResp pipeSubscribe(TPipeSubscribeReq req);

These are interface signatures from the public IDL, shown so you know which service and port to protect. They are not a request format.

Default ports and paths in 2.0.10

From iotdb-system.properties.template at tag v2.0.10:

The template default binds the client RPC service to localhost. Any real deployment changes that, because clients and other nodes need to connect. Check what your nodes actually bind to rather than trusting the template.

Release artifacts and checksums

From downloads.apache.org/iotdb/2.0.11/. Each archive also has an .asc signature; verify with the project KEYS file.

Package coordinates

Breaking change in 2.0.11

The 2.0.11 release notes open with one breaking change: the minimum JDK is now 17. That applies to the server and, because the driver is built from the same release, to applications that bump iotdb-jdbc to 2.0.11. Applications still on Java 8 or 11 need a runtime upgrade before they can take the driver fix.

Credits

• CVE-2026-59562: tonghuaroot and Opr4 (finders).
• CVE-2026-58663: Anurag Kumar (analyst).
• CVE-2026-59229: laodu (finder).
• CVE-2026-41114: Ho1aAs, movonow, zhid889773, WA-888, binghuangczc, errors11, Phoexina, skydiver-jay, V9d0g and FlyFish (finders). Ten independent finders for one low severity driver bug suggests the BigDecimal pattern has been widely noticed.

Indicators of compromise

Apache published none, and no exploitation has been reported, so there are no official indicators. The log review in step 6 below is about spotting misuse of the affected paths, not matching known attacker infrastructure.

What to do now

Work through these in order. Steps 1 to 3 take minutes and tell you how urgent the rest is.

1. Find every IoTDB you run

On a host with a binary install, the version is in the jar names:

# from the IoTDB home directory
ls lib | grep -E '^iotdb-(server|session|jdbc)-' 

From the IoTDB CLI, connected as an administrator:

SHOW VERSION;
SHOW CLUSTER;

SHOW CLUSTER lists every ConfigNode and DataNode, so you do not miss a node that was added later.

For containers:

docker ps --format '{{.Image}} {{.Names}}' | grep -i iotdb
docker image ls apache/iotdb

For Kubernetes:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' | grep -i iotdb

A tag of latest pulled before 14 September, or any 2.0.x tag below 2.0.11, is affected by the three server CVEs.

2. Find every IoTDB JDBC driver

The driver is a normal Maven dependency, so it shows up in builds:

# Maven
mvn -q dependency:tree -Dincludes=org.apache.iotdb:iotdb-jdbc

# Gradle
./gradlew dependencies --configuration runtimeClasspath | grep iotdb-jdbc

# Inside a built fat jar or a deployed lib directory
unzip -l app.jar | grep -i iotdb-jdbc
find / -name 'iotdb-jdbc-*.jar' 2>/dev/null

Anything from 1.3.3 up to 2.0.10 is in range for CVE-2026-41114.

3. See who can reach port 6667

This is the question that decides how urgent CVE-2026-59562 is for you.

# On each DataNode: what is listening, and on which address
ss -ltnp | grep -E ':(6667|10710|10720|10730|10740|10750|10760|18080|9780)\b'

# Check the configured bind address
grep -E '^(dn_rpc_address|dn_rpc_port|dn_internal_address)=' conf/iotdb-system.properties

If dn_rpc_address is 0.0.0.0 or a routable address, list every network that can route to it. From a host outside the trusted segment, a plain connectivity test is enough to confirm exposure:

nc -vz <iotdb-host> 6667

If that succeeds from somewhere it should not, fix that today, before the upgrade.

4. Restrict the client RPC port until you upgrade

Because the pipe methods share port 6667 with ordinary clients, the only network level control is an allowlist of client and sender addresses. On Linux with nftables:

sudo nft add table inet iotdb
sudo nft add chain inet iotdb input '{ type filter hook input priority 0; policy accept; }'
sudo nft add rule inet iotdb input tcp dport 6667 ip saddr { 10.20.0.0/24, 10.20.1.15 } accept
sudo nft add rule inet iotdb input tcp dport 6667 drop

Replace the addresses with your application servers, pipe senders and administrator hosts. Do the same for the internal ports (10710 to 10760) so that only other cluster nodes can reach them. In Kubernetes, a NetworkPolicy on the DataNode pods that admits port 6667 only from labelled client namespaces does the same job.

This lowers exposure; it does not fix the bugs. Any host on the allowlist can still reach the vulnerable methods.

5. Review who holds USE_PIPE and MAINTAIN

CVE-2026-59229 turns these system privileges into the ability to load or delete data as root. List users and their privileges from the CLI:

LIST USER;
LIST PRIVILEGES OF USER <username>;
LIST ROLE;
LIST PRIVILEGES OF ROLE <rolename>;

For any account that holds USE_PIPE or MAINTAIN but should not be able to change data, revoke the privilege until the server is on 2.0.11. In the tree model the documented form is:

REVOKE USE_PIPE ON root.** FROM USER <username>;

Check the Authority Management page for your data model before running revocations in production. The IoTDB threat model is also explicit that USE_PIPE is a grant of server-side execution capability, so keep it to accounts you would trust with that even after the upgrade.

While you are there, confirm the default root password has been changed. The project's threat model calls the default root:root account a must-change before production use.

6. Review logs for unexpected legacy pipe activity

Without published indicators, look for behaviour that should not happen in your environment:

• Legacy pipe handshakes or file transfers from addresses that are not known 1.x senders. If you never ran a 1.x to 2.0 pipe, any legacy pipe activity is unexpected.
• Files appearing outside data/datanode/system/pipe/receiver (or your configured dn_pipe_receiver_file_dirs) that were written by the IoTDB service account, especially in the IoTDB lib, conf or ext directories or the service account's home.
• Data loads or deletions in databases that no pipe should be writing to.
• New or modified jars in the IoTDB install directory.

# Files changed by the IoTDB user in the last 60 days, outside the data directory
sudo find / -user iotdb -newermt "$(date -d '60 days ago' +%F)" -type f \
  -not -path '*/data/*' -not -path '/proc/*' 2>/dev/null

# Pipe receiver related log lines
grep -iE 'legacy|handshake|sendfile|pipe.?receiver' logs/log_datanode_all.log | tail -200

Adjust the service user and log path to your installation. Log wording varies between versions, so treat the grep as a starting point.

7. Upgrade the server to 2.0.11

1. Read the 2.0.11 release notes and confirm the hosts have JDK 17 or newer (java -version).
2. Download from Apache and verify:

curl -O https://downloads.apache.org/iotdb/2.0.11/apache-iotdb-2.0.11-all-bin.zip
curl -O https://downloads.apache.org/iotdb/2.0.11/apache-iotdb-2.0.11-all-bin.zip.sha512
curl -O https://downloads.apache.org/iotdb/2.0.11/apache-iotdb-2.0.11-all-bin.zip.asc
curl -O https://downloads.apache.org/iotdb/KEYS
shasum -a 512 apache-iotdb-2.0.11-all-bin.zip
gpg --import KEYS && gpg --verify apache-iotdb-2.0.11-all-bin.zip.asc

The SHA-512 should match the value in the Technical details table.

3. Back up the data directories and configuration, and test a restore somewhere else.
4. Upgrade one node at a time in a cluster, ConfigNodes first if your runbook says so, and confirm each rejoins with SHOW CLUSTER before moving on.
5. For containers, pin the tag rather than relying on latest:

# docker-compose.yml
services:
  iotdb:
    image: apache/iotdb:2.0.11-standalone

6. Rebuild any derived images that start FROM apache/iotdb.

8. Upgrade the JDBC driver

<dependency>
  <groupId>org.apache.iotdb</groupId>
  <artifactId>iotdb-jdbc</artifactId>
  <version>2.0.11</version>
</dependency>

implementation 'org.apache.iotdb:iotdb-jdbc:2.0.11'

If the application cannot move to Java 17 yet, the interim option is to validate numeric input before it reaches a prepared statement: reject BigDecimal values whose absolute scale is far beyond any real measurement, which mirrors the guard Apache added.

9. Verify

• SHOW VERSION; on every node reports 2.0.11.
• mvn dependency:tree shows iotdb-jdbc:2.0.11 in every service that uses it.
• Your pipes still deliver data. After 2.0.11 the legacy receiver requires an authenticated session with USE_PIPE, per pull request #17741. If you still run 1.x senders against a 2.0 receiver, confirm they authenticate correctly after the upgrade.
• The allowlist from step 4 stays in place. It is good practice regardless of version.

What changed since first reports

• Maven availability confirmed. As of 24 October, the Maven Central metadata for iotdb-server, iotdb-session and iotdb-jdbc lists 2.0.11 as the latest version, updated on 11 September.
• CVE records enriched. All four records gained a CVE Program container at 18:10 UTC on 21 October. No CISA enrichment or CVSS score has been added.
• No exploitation. Nothing in the KEV catalog through 23 October, and no reports we could find.
• No new technical write-up from Apache. The advisories remain one line each for three of the four CVEs.

Open questions

• How does CVE-2026-59562 reach code execution? Apache's title says remote code execution; the description says only missing authentication. Until more detail is public, treat it as full host compromise for any 2.0 server reachable on port 6667.
• What exactly is CVE-2026-58663? "Authentication bypass in pipeTransfer" is all that is public.
• Is 1.3.x affected by anything similar? The server advisories name only 2.0.0 onward. Whether the 1.3 sync receiver has related weaknesses is not addressed.
• Why six weeks between release and advisory? Apache's process lets projects release first and announce later. The release notes for 2.0.11 list features and bug fixes but do not mention security fixes, so nobody reading them would have known to hurry.
• Will a CVSS score appear? If NVD or CISA scores these CVEs, expect scanners to start flagging them more loudly, which may be the first many teams hear of them.

What would have helped

There was no breach here. The useful question is how to turn a batch like this into a short, boring job, and how to have taken the fix in September rather than October.

Practices any team can use

1. Track releases, not only CVEs. The fix was in a release on 11 September and in the public code on 29 May. Subscribing to IoTDB's GitHub releases or the announce@apache.org list and taking minor releases routinely would have closed this exposure six weeks before the advisory. For infrastructure you run yourself, release cadence is a better trigger than CVE publication.
2. Inventory infrastructure, not just applications. A database installed from a zip on an edge gateway never shows up in a dependency scan of your source code. Keep a register of data stores by host, version and owner, and update it when you deploy.
3. Never expose a time-series database's client port beyond the hosts that need it. IoTDB's own threat model treats direct public exposure as unsupported. In operational technology networks, this means an allowlist on the DataNode and a firewall between the plant network and the corporate one.
4. Separate ingestion from administration. Use distinct accounts for pipe senders, applications and humans, with the least privilege each needs. Treat USE_PIPE, USE_UDF, USE_TRIGGER and USE_MODEL as powerful grants, which the IoTDB threat model says they are.
5. Turn off compatibility paths you do not use. If you never send from 1.x to 2.0, the legacy receiver is attack surface with no benefit. Where a product offers a switch, use it; where it does not, network controls are the fallback.
6. Pin versions in images and charts. apache/iotdb:latest hides which build is running and makes rollback guesswork.
7. Rehearse database upgrades. A tested backup and a node-by-node runbook make a JDK bump and a minor release a planned afternoon instead of a risk nobody wants to take.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. We are not claiming it found any of these IoTDB issues, or that an SGZ advisory existed for them.

Gold Open Source at gold.safeguard.sh is free with no login: CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is the paid service for hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge on regression. We are not claiming Gold had a patched IoTDB build before 2.0.11. The habit that matters is pulling fixed, signed components from a curated source and rebuilding quickly once a fix exists.

Where Safeguard fits

Safeguard helps most with the JDBC driver and with container images, and less with a server installed from a zip.

• Finding the driver. safeguard scan --dir . on a Java repository reads the Maven or Gradle dependency graph, and the platform shows which projects contain org.apache.iotdb:iotdb-jdbc and at which version, matched against vulnerability databases. Reachability analysis can show whether your code calls into the driver's prepared statement path at all.
• Finding the server in images. safeguard scan --image <name> on images built FROM apache/iotdb, or safeguard scan --sbom <file> on an SBOM a vendor supplies, writes JSON results under ./output and shows the bundled IoTDB jars.
• Keeping old versions out. Policies and gates in the platform can block promotion of an image or build that still carries an affected IoTDB, so a stale base image does not come back next sprint.
• Doing the edit. The Safeguard CLI's assistant can change a pom.xml, a Gradle file, a Compose file or a Helm values file to 2.0.11 and run your build and tests, asking before each command under the default permission mode; safeguard exec runs the same work in CI. Autonomous remediation can open fix pull requests and ships off by default.

Where it does not help: Safeguard does not patch a running IoTDB server, change its bind address, write your firewall rules or revoke database privileges. It will not see an IoTDB installed by hand on an edge gateway unless that host or an SBOM for it is scanned. And when IoTDB is embedded inside a vendor appliance, the fix has to come from the vendor.

To try the CLI on your own repositories and images, download Safeguard and follow the CLI docs.

For earlier IoTDB issues, see our posts on CVE-2026-24015, IoTDB's insecure default and CVE-2026-24713, IoTDB JEXL injection.

Common mistakes and troubleshooting

• Assuming passwords protect you from CVE-2026-59562. The vulnerable call did not require a login. Network reachability is what matters.
• Firewalling only the "pipe port". There is no separate port for these methods on 2.0.10; they share 6667 with every client.
• Upgrading the server and forgetting the driver. CVE-2026-41114 lives in your applications, not in the database.
• Bumping the driver on Java 11. 2.0.11 requires JDK 17. The build may fail, or the application may fail at start with a class version error. Upgrade the runtime first.
• Trusting latest. An image pulled before 14 September is 2.0.10 or older.
• Treating 1.3.x as safe from everything. It is outside the three server advisories, but the JDBC range starts at 1.3.3, and 1.3 has its own earlier advisories.
• Pipes stop after the upgrade. The legacy receiver now requires an authenticated session with USE_PIPE. Give the sender a dedicated account with that privilege and only that.
• Upgrading every cluster node at once. Go one node at a time and confirm with SHOW CLUSTER.
• Leaving the allowlist off after upgrading. The next advisory will not wait for your change window either.

FAQ

What is CVE-2026-59562 in Apache IoTDB?

It is a missing authentication check in the legacy pipe sendFile RPC of Apache IoTDB 2.0.0 up to 2.0.11. Apache titles it remote code execution and unauthenticated path traversal, rates it important, and fixed it in 2.0.11.

Which IoTDB versions are affected and which version fixes them?

The three server CVEs affect Apache IoTDB 2.0.0 before 2.0.11. The JDBC driver CVE affects org.apache.iotdb:iotdb-jdbc 1.3.3 before 2.0.11. Version 2.0.11 fixes all four.

Is anyone exploiting these vulnerabilities?

No exploitation has been reported. None of the four is in the CISA KEV catalog as of 23 October 2026, and we found no public proof of concept.

What is the CVSS score?

Apache did not publish one. The CVE records carry only the words "important" or "low", and NVD lists the records as awaiting analysis.

Is IoTDB 1.3.x affected?

Apache lists only 2.0.0 onward for the three server issues. The JDBC driver issue starts at 1.3.3, so applications using a 1.3 driver from 1.3.3 onward are in range.

Can I just disable the legacy pipe receiver?

The advisories do not describe a configuration switch for it, and in 2.0.10 the legacy methods share the client RPC service on port 6667. Restrict that port to known hosts and upgrade.

When was the fix actually released?

Version 2.0.11 was published on GitHub on 11 September 2026 and on Maven Central the same day. The advisories followed on 21 October. The related hardening change was merged on 29 May 2026.

Do I need to rotate credentials after upgrading?

The advisories do not say so. If step 3 showed port 6667 was reachable from untrusted networks, treat the host as possibly exposed: review it as in step 6 and rotate credentials stored on it as a precaution.

Why does upgrading the JDBC driver need Java 17?

Release 2.0.11 raised the minimum JDK to 17, and the driver ships with the same version number. Plan the runtime change with the driver bump.

Who found these bugs?

Apache credits tonghuaroot and Opr4 for CVE-2026-59562, Anurag Kumar for CVE-2026-58663, laodu for CVE-2026-59229, and ten finders for CVE-2026-41114.

Fix it without waiting for upstream

For IoTDB the upstream fix already exists; the gap is between 11 September and the day 2.0.11 is actually running on your nodes and inside your applications.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows IoTDB; each shows a real flow that maps onto this upgrade. The first is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For IoTDB you would ask it to move iotdb-jdbc to 2.0.11 in your pom.xml, or change apache/iotdb to 2.0.11-standalone in a Compose file, and approve each build and test command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is how you would ask which local repositories and images still carry an IoTDB server below 2.0.11 or a JDBC driver between 1.3.3 and 2.0.10.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. Here you would point it at the service that writes sensor data through JDBC, let it propose the 2.0.11 driver and the Java 17 toolchain change, and approve each edit and test run.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• oss-security: CVE-2026-59562, legacy pipe sendFile RCE and path traversal (openwall.com)
• oss-security: CVE-2026-58663, auth bypass in pipeTransfer() (openwall.com)
• oss-security: CVE-2026-59229, legacy pipe privilege escalation (openwall.com)
• oss-security: CVE-2026-41114, JDBC driver memory exhaustion (openwall.com)
• Apache IoTDB dev list: CVE-2026-59562 advisory (lists.apache.org)
• Apache IoTDB dev list: CVE-2026-58663 advisory (lists.apache.org)
• Apache IoTDB dev list: CVE-2026-59229 advisory (lists.apache.org)
• Apache IoTDB dev list: CVE-2026-41114 advisory (lists.apache.org)
• CVE-2026-59562 record (cve.org)
• CVE-2026-58663 record (cve.org)
• CVE-2026-59229 record (cve.org)
• CVE-2026-41114 record (cve.org)
• NVD entry for CVE-2026-59562 (nvd.nist.gov)
• NVD entry for CVE-2026-41114 (nvd.nist.gov)
• Apache IoTDB 2.0.11 release (github.com)
• Comparison of v2.0.10 and v2.0.11 (github.com)
• Pull request #17741: harden legacy pipe file transfer validation and access checks (github.com)
• Pull request #18111: use session context in legacy receiver loaders (github.com)
• Pull request #17508: prevent BigDecimal DoS in the JDBC driver (github.com)
• Pull request #17901: support legacy pipe receiver requests (github.com)
• Pull request #17823: threat model and security policy (github.com)
• IoTDB THREAT_MODEL.md at v2.0.11 (github.com)
• IoTDB SECURITY.md at v2.0.11 (github.com)
• client.thrift at v2.0.10 (github.com)
• iotdb-system.properties.template at v2.0.10 (github.com)
• Apache IoTDB 2.0.11 downloads and checksums (downloads.apache.org)
• Apache IoTDB download page (iotdb.apache.org)
• Apache IoTDB Authority Management (iotdb.apache.org)
• Maven Central metadata for iotdb-jdbc (repo1.maven.org)
• Maven Central metadata for iotdb-server (repo1.maven.org)
• apache/iotdb image tags (hub.docker.com)
• CISA Known Exploited Vulnerabilities catalog (cisa.gov)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.