CVE-2026-62349
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedTDengine 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceTDengine's trimString() function in source/libs/parser/src/parUtil.c has an out-of-bounds write vulnerability. The function only checks for one byte of space before processing SQL string escape sequences (\%, \_, or \x), allowing a one-byte write past the end of the stack buffer tmpTokenBuf. This stack-based buffer overflow can cause denial of service and potentially enable remote code execution.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- Low
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- Low
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Confirm TDengine installationCheck for TDengine processes by running 'ps aux | grep -E "(tdengine|taos)"' or look for TDengine installation directories such as /usr/local/taos, /opt/taos, or /var/lib/taosAffected if TDengine is running on the system
-
Identify TDengine versionRun 'taos --version' or 'taosd --version' from the TDengine bin directory, or check the version file typically found at /etc/taos/taos.cfg or within the installation package metadataAffected if The installed version is lower than 3.4.1.14 (vulnerable)
-
Verify the vulnerable code component is presentLocate the TDengine installation and check for the file source/libs/parser/src/parUtil.c or its compiled equivalent in the installed binaries. On Linux, use 'strings' or 'grep' on the libparser.so library if present in the installationAffected if The parUtil.c file exists in the source or the parser library contains the trimString function from a version prior to 3.4.1.14
-
Assess SQL parsing exposureTDengine parses SQL strings automatically when handling queries. This vulnerability is triggered by the trimString function during SQL escape sequence processing. Review any SQL query logs or monitor for queries containing \%, \_, or \x escape sequencesAffected if TDengine is processing SQL queries with escape sequences (\%, \_, or \x) and the version is below 3.4.1.14
The system is affected if TDengine version is below 3.4.1.14 and the software is actively processing SQL queries with escape sequences, as the trimString function in parUtil.c will write one byte past the allocated stack buffer.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedUpgrade TDengine to version 3.4.1.14 or later. If immediate patching is not feasible, restrict network exposure to database services and implement application-layer input validation for SQL escape sequences.
TDengine version 3.4.1.14
- 1. Identify all TDengine installations currently running version 3.4.1.6 or earlier
- 2. Backup all databases and configuration files before upgrading
- 3. Stop the TDengine service on each affected node
- 4. Upgrade TDengine to version 3.4.1.14 or later
- 5. Verify the upgrade by checking the TDengine version (e.g., taos --version)
- 6. Restart the TDengine service
- 7. Test that database operations, especially SQL queries with string escape sequences, function correctly
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation2.0 h
- Implementation4.0 h
- Testing6.0 h
- Review / QA2.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $3,808.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-62349 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-62349 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data