EUVD-2026-44766Severity by source
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Exploited over the network via SQL but requires the high-level 'create udf' privilege (PR:H); native in-process code execution yields full C/I/A impact with no scope change (S:U).
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. Prior to 3.4.1.15, a user with create udf privilege could upload a crafted shared library and install it as a user-defined function, such as eval, then execute arbitrary C code on the TDengine server side through database queries. This issue is fixed in version 3.4.1.15.
AnalysisAI
Server-side arbitrary code execution in TDengine time-series database (versions prior to 3.4.1.15) allows a database user holding the 'create udf' privilege to upload a malicious shared library, register it as a user-defined function (e.g. named 'eval'), and execute attacker-controlled native C code on the server by invoking that function through ordinary SQL queries. This is a privileged-user code injection issue (CWE-94) with high confidentiality, integrity, and availability impact; no public exploit identified at time of analysis and it is not listed in CISA KEV. The flaw is fixed in version 3.4.1.15.
Technical ContextAI
TDengine is an open-source time-series database purpose-built for IoT/IIoT telemetry ingestion and analytics. Like many SQL databases, it supports user-defined functions (UDFs) that can be implemented as native compiled code (C shared libraries) loaded into the server process for performance. The root cause is CWE-94 (Improper Control of Generation of Code / Code Injection): the UDF loading mechanism trusts the uploaded shared library and executes its code in the context of the TDengine server without a safe sandbox, so the 'create udf' capability effectively grants native code execution rather than merely defining a sandboxed function. Because the malicious library runs in-process (S:U - no privilege boundary is crossed into another security scope), the attacker's C code inherits the privileges of the TDengine server process. No CPE strings were supplied in the intelligence; affected components are inferred from the vendor GitHub Security Advisory (GHSA-f7wh-p233-87xv) and the description alone.
RemediationAI
Upgrade to TDengine 3.4.1.15 or later, which remediates the issue - Vendor-released patch: 3.4.1.15 (per GHSA-f7wh-p233-87xv, https://github.com/taosdata/TDengine/security/advisories/GHSA-f7wh-p233-87xv). Until the upgrade is applied, restrict who holds the 'create udf' privilege to a minimal set of fully trusted administrators and revoke it from application/service and multi-tenant accounts, since that privilege is the sole precondition for exploitation; audit existing UDFs (for example any named 'eval' or other unexpected native functions) and remove untrusted ones. Where UDF functionality is not required, disable or block UDF creation entirely - the trade-off is loss of custom-function capability for legitimate workloads. Additionally, run the TDengine server process under a least-privilege OS account and constrain it with filesystem/network controls so that in-process native code execution has reduced blast radius; this does not prevent the code injection itself but limits post-exploitation impact.
Same weakness CWE-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today