New data from the Ridge Security Research Team disclosed CVE-2026-42542, a pre-authentication vulnerability in TDengine, an open-source distributed time-series database used in industrial telemetry, energy, utilities, connected vehicles and IoT environments. The vulnerability allows an unauthenticated remote attacker to crash the database server with a single malformed network packet, without credentials, a valid session or user interaction.
TDengine’s design center is IoT, industrial telemetry, connected vehicles, energy and utilities, and large-scale device monitoring. Those are the deployments most likely to be affected, and they share an uncomfortable pair of properties: the data is operationally critical, and the maintenance windows are narrow or nonexistent.
Organizations most exposed tend to be those where TDengine sits on a flat OT or device network where ‘internal’ means reachable by a great many hosts. The database was deployed by an integrator or bundled inside a vendor appliance, and the operating team may not know it is there. Uptime requirements make patching a scheduled, quarterly event rather than a same-week one.
Ridge Security rated the vulnerability CVSS 7.5, or high, and said affected TDengine versions 3.4.0.0 through 3.4.1.5 are fixed in version 3.4.1.6. The vulnerability stems from an integer underflow in TDengine’s handling of a length field in its custom binary RPC protocol on TCP port 6030.
Ridge Security said an attacker-controlled value can be converted into an extremely large unsigned value and passed to memcpy(), causing the database process to crash with a segmentation fault. The confirmed impact is denial of service, with repeated packets potentially keeping the database in a crash-and-restart cycle. Ridge Security said the failure can result in lost in-flight writes and loss of visibility for OT (operational technology) and telemetry workloads.
“TDengine’s server component, taosd, speaks a custom binary RPC protocol on TCP port 6030 by default. Every message on that wire begins with a fixed-size header, STransMsgHead, and the header carries a length field — msgLen — that tells the server how large the rest of the message is,” the researchers identified. “Early in connection handling, before any authentication has taken place, the server calls a function named uvConnMayGetUserInfo() to pull the user identity out of the inbound message. To do that, it needs to work out how many bytes of payload follow the header. It does what looks like the obvious thing: it subtracts the header size from the message length. That subtraction is where it falls apart.”
Ridge Security researchers identified a vulnerability with confirmed denial-of-service impact, wherein a single crafted packet to the RPC port reliably crashes taosd. If the service is under a supervisor or systemd restart policy, it comes back, and an attacker can simply send the packet again in a loop, holding the database in a permanent crash cycle. For a time-series database, a crash is not a clean failure: in-flight writes are lost, and for an operational-technology or telemetry workload, lost writes represent lost visibility. A monitoring system that is down is also a monitoring system that is not alerting.
The underlying primitive is memory corruption, which raises a harder question for defenders. The bug is a heap buffer overflow driven by an attacker-influenced length, a class of primitive that has historically sometimes been developed into remote code execution. Ridge Security researchers confirmed unauthenticated remote denial of service with heap corruption as the underlying mechanism, and defenders should size their response to the corruption primitive, not just to the crash.
The primary remediation is to upgrade to TDengine 3.4.1.6 or later, as this is the actual fix and everything else is merely a stopgap measure. If you cannot patch immediately, reduce reachability by ensuring that port 6030 is not exposed to the internet and, in most architectures, should not be broadly reachable inside the network either; restrict it with host firewall rules or network ACLs to the specific application hosts that need to communicate with it.
Since this vulnerability requires network access to the RPC port, removing that access eliminates the exposure regardless of patch status. Before assuming you are unaffected, inventory your environment to check whether TDengine is present in bundled or OEM products, as embedded deployments are the ones most likely to be missed.
While auditing the same code paths, the team noted two areas where TDengine’s cryptographic posture lags current practice. Neither constitutes a vulnerability in the CVE sense, and neither is part of CVE-2026-42542, but both are worth raising with the community. Password hashing defaults to MD5, which has been considered cryptographically broken for years and offers effectively no resistance to offline dictionary or rainbow-table attacks against a captured credential store; modern practice calls for a memory-hard, salted algorithm such as Argon2id or bcrypt. RPC connection signatures use SHA-1, which is deprecated for collision resistance and should be moved to SHA-256.
TDengine’s codebase shows genuinely defensive habits elsewhere, including a disciplined internal tstrncpy() wrapper for string handling, so the weakness is not carelessness across the board but rather concentrated at the network boundary, which is exactly where it hurts most.
Ridge Security has no telemetry indicating in-the-wild exploitation of this vulnerability and is not aware of any public exploit code, so this detection logic is derived from the mechanics of the bug rather than from observed attacks. Because the vulnerability manifests as a crash rather than an implant, the signal is behavioral: unexplained taosd segmentation faults, particularly repeated ones, should prompt checking of dmesg, the kernel journal, and any core-dump collection for taosd crashes, as repeated segfaults on a service that had been stable are the primary indicator. If a supervisor or systemd unit is restarting taosd repeatedly, treat that as a security event until proven otherwise rather than merely a stability issue.
Connection attempts to port 6030 from unexpected sources, especially short-lived connections that send a small amount of data without establishing a session, warrant
investigation, and correlating inbound connections to 6030 against your known client inventory is worth doing regardless of this CVE. Gaps in time-series ingestion represent another clear symptom, as a sudden hole in your own metrics is one of the clearest signs of a downed metrics database. A defender writing a network signature has a reasonably clean anchor: a packet to the RPC port whose declared msgLen is smaller than the fixed header size is never legitimate traffic.
In separate research, the team also identified CVE-2026-44639 in NanoMQ, a widely used lightweight MQTT broker. The broker’s MQTT v5 property decoder walks the entire property linked list for each property appended, producing O(N²) behavior. An unauthenticated attacker who sends PUBLISH or SUBSCRIBE packets carrying a large number of User Properties can drive CPU consumption high enough to make the broker unresponsive.
It is a materially less severe issue with a CVSS score of 3.7 (Low) involving resource exhaustion rather than memory corruption, and it is fixed in NanoMQ 0.24.14. We mention it because it rhymes with the first finding in a way that is worth noticing: both are unauthenticated, both live in the message parsing path, and both are algorithmic or arithmetic mistakes rather than missing security controls. The parsing layer of a network service is where a surprising share of real risk lives.
“The infrastructure that carries machine data is now as security-relevant as the applications that sit on top of it, and it is inspected far less often,” Ridge Security researchers pointed out. “CVE-2026-42542 is a three-line fix guarding a subtraction, in a function that runs before anyone has proven who they are, on a port that in too many networks is reachable from too many places. That is not an exotic failure. It is an ordinary one, in an important place.”
They suggested patching to 3.4.1.6, putting an ACL in front of port 6030, and going to find out how many time-series databases are actually running in your environment. Most organizations are surprised by the answer.
