CVE-2025-68156 Overview
CVE-2025-68156 is a denial of service vulnerability in Expr, an expression language and expression evaluation library for Go. Prior to version 1.17.7, several builtin functions in Expr, including flatten, min, max, mean, and median, perform recursive traversal over user-provided data structures without enforcing a maximum recursion depth. If the evaluation environment contains deeply nested or cyclic data structures, these functions may recurse indefinitely until exceeding the Go runtime stack limit, resulting in a stack overflow panic that causes the host application to crash.
Critical Impact
Attackers can crash applications using Expr by providing deeply nested or cyclic data structures to builtin functions, causing stack exhaustion and denial of service without the ability to recover gracefully.
Affected Products
- Expr-lang Expr versions prior to 1.17.7
- Go applications using the expr-lang/expr library with vulnerable builtin functions
- Systems evaluating expressions against externally supplied or dynamically constructed environments
Discovery Timeline
- 2025-12-16 - CVE CVE-2025-68156 published to NVD
- 2026-03-05 - Last updated in NVD database
Technical Details for CVE-2025-68156
Vulnerability Analysis
This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The core issue stems from several builtin functions within the Expr library performing unbounded recursive operations on user-controlled data structures. When these functions encounter deeply nested arrays, maps, or structs—or data structures containing cyclic references—they continue recursing without any depth limitations until the Go runtime's stack is exhausted.
The affected builtin functions (flatten, min, max, mean, and median) are commonly used for data manipulation and aggregation operations. Each of these functions traverses input data structures recursively to perform their operations, making them susceptible to stack exhaustion attacks when processing maliciously crafted inputs.
Root Cause
The root cause is the absence of recursion depth limits in the affected builtin functions. When these functions process data structures, they recursively descend into nested elements without tracking or limiting the recursion depth. Go's runtime has a finite stack size, and when this limit is exceeded through deep recursion, the runtime triggers a stack overflow panic. Unlike recoverable errors, this panic terminates the process unless caught by panic recovery mechanisms higher in the call stack.
Attack Vector
The attack vector is network-accessible, requiring no authentication or user interaction. An attacker can exploit this vulnerability by injecting or influencing the data structures that are passed to Expr for expression evaluation. The attack is particularly relevant in scenarios where:
- Expr evaluates expressions against externally supplied or dynamically constructed environments
- Cyclic references can be introduced into arrays, maps, or structs (directly or indirectly)
- No application-level safeguards prevent deeply nested input data
The attacker constructs a deeply nested or cyclic data structure and triggers evaluation of an expression that invokes one of the vulnerable builtin functions (such as flatten(malicious_data) or max(nested_array)). When the function attempts to traverse this structure, the unbounded recursion exhausts the stack, causing a process-level crash.
Detection Methods for CVE-2025-68156
Indicators of Compromise
- Application crashes with Go runtime stack overflow panics during expression evaluation
- Unexpected process terminations in services using the Expr library
- Error logs showing panic messages related to stack exhaustion in flatten, min, max, mean, or median functions
- Unusually deep or cyclic data structures appearing in input data streams
Detection Strategies
- Monitor application logs for stack overflow panic messages originating from Expr library functions
- Implement application-level monitoring to detect sudden process terminations during expression evaluation
- Review input validation logs for deeply nested JSON or data structures being submitted to expression evaluation endpoints
- Audit dependencies to identify applications using expr-lang/expr versions prior to 1.17.7
Monitoring Recommendations
- Set up alerting for repeated application crashes or restarts in services utilizing Expr
- Implement structured logging around expression evaluation calls to capture input characteristics
- Monitor memory and CPU usage patterns that may indicate recursive processing of malicious inputs
- Deploy application health checks that detect and report stack overflow conditions
How to Mitigate CVE-2025-68156
Immediate Actions Required
- Upgrade to Expr version 1.17.7 or later, which includes recursion depth limits for affected builtin functions
- Audit applications using Expr to identify expression evaluation endpoints that accept external input
- Implement input validation to reject data structures with excessive nesting depth before passing to Expr
- Wrap expression evaluation calls with panic recovery as a defensive measure to prevent full process crashes
Patch Information
The vulnerability has been fixed in Expr version 1.17.7. The patch introduces a maximum recursion depth limit for the affected builtin functions (flatten, min, max, mean, and median). When this limit is exceeded, evaluation aborts gracefully and returns a descriptive error instead of panicking. Additionally, the maximum depth can be customized by users via builtin.MaxDepth, allowing applications with legitimate deep structures to raise the limit in a controlled manner.
For detailed patch information, refer to the GitHub Pull Request #870 and the GitHub Security Advisory GHSA-cfpf-hrx2-8rv6.
Workarounds
- Ensure that evaluation environments cannot contain cyclic references by implementing cycle detection before evaluation
- Validate or sanitize externally supplied data structures before passing them to Expr, enforcing maximum nesting depth limits
- Wrap expression evaluation with panic recovery using Go's recover() mechanism to prevent full process crashes (as a last-resort defensive measure)
- Implement rate limiting and request size limits on endpoints that accept data for expression evaluation
# Example: Update expr-lang/expr dependency to patched version
go get github.com/expr-lang/expr@v1.17.7
go mod tidy
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


