EUVD-2026-44767Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Network-reachable SQL parser needs low-priv authentication (PR:L) and is easy to trigger (AC:L); single-byte overflow yields reliable DoS (A:H) but only speculative, limited C/I impact.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
3DescriptionCVE.org
TDengine is an open source, time-series database optimized for Internet of Things devices. In 3.4.1.6 and earlier, source/libs/parser/src/parUtil.c trimString() checks space for only one byte before processing SQL string escape sequences \%, \_, or \x, allowing a one-byte out-of-bounds write to the stack buffer tmpTokenBuf that can cause denial of service and potentially remote code execution. This issue is fixed in version 3.4.1.14.
AnalysisAI
Stack-based buffer overflow in TDengine (open-source IoT time-series database) versions 3.4.1.6 and earlier allows an authenticated user to trigger a one-byte out-of-bounds write by submitting SQL containing crafted escape sequences (\%, \_, or \x), leading to denial of service and potentially remote code execution. The flaw sits in the SQL parser's trimString() routine, which validates only a single byte of remaining space in the tmpTokenBuf stack buffer before writing escape-processed data. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; it is fixed in version 3.4.1.14.
Technical ContextAI
TDengine is a purpose-built time-series database widely used for IoT and industrial telemetry workloads, exposing a SQL-like query interface. The vulnerability is a classic CWE-121 stack-based buffer overflow located in source/libs/parser/src/parUtil.c, inside trimString(), a helper invoked while the parser normalizes SQL string literals. When the parser encounters the escape sequences \%, \_, or \x, it processes them into the fixed-size stack buffer tmpTokenBuf, but the bounds check only ensures one byte of space remains rather than the full space needed for the expanded sequence, permitting a controlled one-byte write past the end of the buffer. Overwriting adjacent stack memory (such as a saved register, canary byte, or length field) can corrupt program control flow, which is the mechanism behind both the crash (DoS) and the theoretical code-execution outcome.
RemediationAI
Vendor-released patch: upgrade to TDengine 3.4.1.14 or later, which corrects the bounds check in trimString(); this is the primary and recommended fix per the vendor advisory at https://github.com/taosdata/TDengine/security/advisories/GHSA-4v5h-fxjw-vrmq. Where immediate upgrade is not possible, reduce exposure by restricting network access to the TDengine query/service ports so that only trusted application hosts can reach the database (trade-off: may require firewall/allowlist changes and can break ad-hoc client access), and by tightening database account privileges so untrusted or low-trust users cannot submit arbitrary SQL, since exploitation requires an authenticated session (PR:L). Because the trigger is specific escape-sequence handling in SQL string literals, adding input validation or a query proxy that rejects or sanitizes SQL containing \%, \_, or \x escape patterns can serve as a stopgap, though this risks false positives against legitimate LIKE-pattern queries and should be treated as temporary until the patch is applied.
Same weakness CWE-121 – Stack-based Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today