tinyexpr EUVD-2026-86286

Two concrete conditions must hold. (1) The embedding application must pass attacker-influenced expression strings into tinyexpr's parser (new_expr) - tinyexpr is a library with no network surface of its own, so reachability is inherited from the host app. (2) Critically, the binary must be compiled with UndefinedBehaviorSanitizer (UBSan) for the 'deterministic process termination' to occur; this is a non-default, typically development/CI-only build mode. The trigger itself is trivial - any arity-0 node (a constant, a variable, or a zero-argument function) causes the undersized allocation. Primary LIMITING factor: in standard production (non-UBSan) builds the flaw is undefined behavior with no guaranteed crash, sharply reducing real-world availability impact; secondary limit is that untrusted expressions must actually reach the parser.

Signals conflict sharply and net out to LOW real-world risk despite the 7.5/High CVSS. The input vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H claims a network-reachable, unauthenticated, no-interaction availability impact, but the description constrains the only observable effect to 'deterministic process termination in UBSan-instrumented builds' - a non-default compile-time configuration. In ordinary (non-UBSan) production builds the undersized arity-0 allocation is undefined behavior that typically produces no crash, so the A:H rating is overstated for realistic deployments. Exploitation-probability signals agree this is not a priority: EPSS is 0.15% (4th percentile), there is no CISA KEV listing, and no public exploit was provided. No SSVC decision data was supplied. tinyexpr is also a library, not a service, so 'AV:N' only holds when the embedding application feeds attacker-controlled expression strings to the parser - the network vector is inherited from the host application, not intrinsic. Bottom line: this is a legitimate correctness/memory-sizing defect (CWE-131) but a high-CVSS-but-low-real-risk issue for most consumers; prioritize only if you ship UBSan/hardened builds that process untrusted expressions.

An application embeds tinyexpr to evaluate user- or network-supplied math expressions and is compiled with UndefinedBehaviorSanitizer. An attacker submits any arity-0 expression - a bare constant like '1', a variable, or a zero-argument function - causing new_expr() to allocate less than sizeof(te_expr) while the code treats the buffer as a full te_expr, which UBSan detects and aborts, denying service. No public exploit code was identified; triggering requires only a trivially simple expression but depends on the UBSan-instrumented build to produce the deterministic crash.