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