Unauthenticated packet crashes TDengine taosd via integer underflow, fixed in 3.4.1.6

One packet, no credentials, one crashed daemon

Ridge Security has disclosed a high-severity vulnerability in TDengine, tracked as CVE-2026-42542, that lets an attacker crash the database's taosd daemon with a single unauthenticated packet. According to a dev.to summary of the disclosure, the original Ridge Security write-up is dated September 23, 2026, and the flaw affects TDengine versions 3.4.0.0 through 3.4.1.5. The issue is resolved in version 3.4.1.6, and is also covered by TDengine's official security advisory and the identifier GHSA-vg95-j2hf-hvjx.

The bug sits in pre-authentication connection handling. TDengine's custom binary RPC protocol listens on TCP/6030 by default, and before any credentials are checked, the function uvConnMayGetUserInfo() performs a length calculation that subtracts the size of the transport header (STransMsgHead) plus a required user-information offset from msgLen, a signed 32-bit length supplied by the remote client.

From underflow to out-of-bounds memcpy

If a client declares a message too short to contain the header and user information, the subtraction produces a negative number. Because the result is converted to an unsigned type, it wraps around to an enormous value — close to 2^64 on 64-bit builds, according to the dev.to analysis. That value is then passed as the length argument to memcpy, causing an out-of-bounds heap access and a segmentation fault that terminates taosd.

Ridge Security verified the denial of service in a research environment: crafted packets reliably stop the process. Two caveats from the disclosure are worth underlining. First, real-world exploitation has not been confirmed. Second, remote code execution has not been confirmed either; the established impact is availability, not code execution or data theft.

Because the crash occurs before authentication, the only prerequisite is network reachability to TCP/6030. The dev.to summary notes that internet exposure is not required — a compromised internal host on a flat network, including operational technology environments, that can reach the port is sufficient. TDengine is used in industrial data and monitoring contexts, which is what makes the availability impact consequential.

Crash loops and what operators will see

If taosd is managed by systemd and restarts automatically, an attacker can keep sending crafted packets to sustain a restart loop. The consequences described in the write-up include lost uncommitted writes, stopped data collection, halted alerts, and gaps in telemetry — though durably committed data is not lost.

For investigation, the useful signals are taosd segmentation faults, core dumps, unusually frequent service restarts, and ingestion gaps correlated in time with connections to TCP/6030. Standard web proxy and DNS logs cannot inspect the RPC traffic, so network telemetry for that port, including the declared msgLen values, is what matters. Notably, the absence of successful login events proves nothing here, since the attack path never authenticates.

Recommended actions

The dev.to summary lays out a response playbook:

• Determine whether TDengine 3.4.0.0 through 3.4.1.5 is deployed anywhere in the estate.
• Upgrade to 3.4.1.6 or later, accounting for the monitoring outage the update restart itself may cause.
• Restrict inbound access to TCP/6030 to authorized clients only, and keep the port off the internet.
• Preserve taosd logs, core dumps, restart records, and any available RPC captures for retrospective analysis.
• Treat suspicious RPC connections alone as unconfirmed attempts; a successful denial of service requires a matching crash and outage at the same timestamp.

Why it matters

This is a pre-authentication, single-packet crash in software that often underpins data collection and alerting pipelines. The bar for exploitation is low — network reachability to one port — and the fix is a routine version bump, which makes exposure of TCP/6030 the main factor in prioritising patches. The most damaging scenario is not one crash but a sustained loop: the telemetry that would tell operators something is wrong goes dark at the same time. The flaw is also a textbook example of a signed/unsigned length-validation bug surviving into a modern binary protocol parser, and a reminder that pre-auth parsing code deserves the same scrutiny as post-auth logic.