Source: golang-github-antonmedv-expr Version: 1.8.9-2 Severity: important Tags: security upstream Forwarded: https://github.com/expr-lang/expr/pull/762 X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerability was published for golang-github-antonmedv-expr. CVE-2025-29786[0]: | Expr is an expression language and expression evaluation for Go. | Prior to version 1.17.0, if the Expr expression parser is given an | unbounded input string, it will attempt to compile the entire string | and generate an Abstract Syntax Tree (AST) node for each part of the | expression. In scenarios where input size isn’t limited, a malicious | or inadvertent extremely large expression can consume excessive | memory as the parser builds a huge AST. This can ultimately lead | to*excessive memory usage and an Out-Of-Memory (OOM) crash of the | process. This issue is relatively uncommon and will only manifest | when there are no restrictions on the input size, i.e. the | expression length is allowed to grow arbitrarily large. In typical | use cases where inputs are bounded or validated, this problem would | not occur. The problem has been patched in the latest versions of | the Expr library. The fix introduces compile-time limits on the | number of AST nodes and memory usage during parsing, preventing any | single expression from exhausting resources. Users should upgrade to | Expr version 1.17.0 or later, as this release includes the new node | budget and memory limit safeguards. Upgrading to v1.17.0 ensures | that extremely deep or large expressions are detected and safely | aborted during compilation, avoiding the OOM condition. For users | who cannot immediately upgrade, the recommended workaround is to | impose an input size restriction before parsing. In practice, this | means validating or limiting the length of expression strings that | your application will accept. For example, set a maximum allowable | number of characters (or nodes) for any expression and reject or | truncate inputs that exceed this limit. By ensuring no unbounded- | length expression is ever fed into the parser, one can prevent the | parser from constructing a pathologically large AST and avoid | potential memory exhaustion. In short, pre-validate and cap input | size as a safeguard in the absence of the patch. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2025-29786 https://www.cve.org/CVERecord?id=CVE-2025-29786 [1] https://github.com/expr-lang/expr/pull/762 [2] https://github.com/advisories/GHSA-93mq-9ffx-83m2 [3] https://github.com/expr-lang/expr/commit/0d19441454426d2f58edb22c31f3ba5f99c7a26e Please adjust the affected versions in the BTS as needed. Regards, Salvatore
