CVE-2026-62349 in TDengine
Summary
by MITRE • 07/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/15/2026
The vulnerability resides in TDengine's SQL parser implementation where the trimString() function in source/libs/parser/src/parUtil.c fails to properly validate buffer boundaries before processing escape sequences. This flaw represents a classic out-of-bounds write condition that occurs when the function processes string literals containing backslash escape characters such as \%, \_, or \x. The vulnerability specifically affects versions 3.4.1.6 and earlier, where the code does not adequately check for sufficient buffer space before writing to the stack buffer tmpTokenBuf. When processing SQL input containing these escape sequences, the function advances through the string without proper boundary validation, leading to a one-byte write beyond the allocated buffer limits.
The technical exploitation of this vulnerability involves crafting malicious SQL input that triggers the specific parsing path where trimString() processes escape sequences. The flaw stems from inadequate bounds checking in the parser logic that handles string literals, particularly when encountering backslash-escaped characters. This type of vulnerability maps to CWE-121 Stack-based Buffer Overflow and aligns with ATT&CK technique T1059.008 Command and Scripting Interpreter: Python, as it involves manipulation of input processing that can lead to arbitrary code execution. The out-of-bounds write occurs at the stack buffer tmpTokenBuf which is allocated on the program's stack, making it susceptible to memory corruption that can be leveraged for privilege escalation or denial of service attacks.
The operational impact of this vulnerability extends beyond simple denial of service to potentially enabling remote code execution in certain conditions. When an attacker successfully exploits this out-of-bounds write, they can corrupt adjacent stack memory, potentially overwriting return addresses or other critical program state information. This corruption can cause the application to crash or, in more sophisticated exploitation scenarios, redirect execution flow to malicious code. The vulnerability affects TDengine's core SQL parsing functionality, meaning any application that processes user-provided SQL input through this database system could be compromised. Given that TDengine is designed for Internet of Things applications, this vulnerability could impact embedded devices and systems where memory corruption might lead to complete system compromise.
Mitigation strategies should focus on immediate patching to version 3.4.1.14 or later where the bounds checking has been properly implemented. Organizations should also implement input validation at multiple layers including application-level filtering of SQL input, network-level intrusion detection systems monitoring for suspicious SQL patterns, and regular security assessments of database interfaces. The fix involves strengthening the boundary checks in trimString() to ensure that all escape sequence processing operations verify sufficient buffer space before writing to tmpTokenBuf. Additional defensive measures include implementing stack canaries, address space layout randomization, and controlling write permissions on critical memory regions. System administrators should also monitor for unusual application behavior or crashes that might indicate exploitation attempts, while following secure coding practices such as those recommended in the CERT C Secure Coding Standard for buffer overflow prevention.