CVE-2026-41850 - Spring SpEL algorithmic DoS

Applications that evaluate user-supplied Spring Expression Language expressions can be driven into algorithmic resource exhaustion in affected Spring Framework releases. Fixed releases track the number of operations during expression evaluation and enforce a default maxOperations threshold.

Unlike CVE-2026-41849, this issue affects multiple maintained framework lines. The repo is only exposed if attackers can influence evaluated SpEL input.

When to use it

  • A Spring application resolves an affected Spring Framework line and evaluates SpEL from user, tenant, admin, workflow, message, or template input.
  • Rule builders, filters, automation logic, or expression editors can compile or evaluate attacker-influenced expressions.
  • You need to preserve or verify the fixed maxOperations bound instead of treating the issue as only a dependency bump.
  • You need a bounded PR or triage note that upgrades Spring and proves expression evaluation is patched and constrained.

Inputs

  • Maven/Gradle manifests, lockfiles, BOMs, container files, SBOMs, platform BOMs, and generated dependency reports.
  • SpEL parser/evaluation call sites, rule engines, workflow config, template integrations, admin expression editors, and message processors.
  • Current or proposed SpelParserConfiguration and maxOperations settings.
  • Available dependency resolution, unit/expression tests, container build, SBOM, and dependency/security scan commands.

Affected versions

  • Vulnerable package: Spring Framework 5.3.0-5.3.48, 6.1.0-6.1.27, 6.2.0-6.2.18, 7.0.0-7.0.7
  • Fixed versions: 5.3.49, 6.1.28, 6.2.19, 7.0.8
  • Mitigation detail in fixed builds: SpEL enforces maxOperations (default 10000) and throws SpelEvaluationException EL1085E when exceeded

Indicator-of-exposure

  • The repository evaluates untrusted or user-controlled SpEL expressions.
  • The application exposes rule builders, filters, templates, automation logic, or admin fields that compile/evaluate SpEL.
  • The runtime resolves a vulnerable Spring Framework version.
  • No application-level expression complexity limits exist.

Quick checks:

rg -n "SpelExpressionParser|ExpressionParser|parseExpression|StandardEvaluationContext|SimpleEvaluationContext|spring\\.expression|maxOperations|SpelParserConfiguration" .
mvn -q dependency:tree | rg "spring-expression|spring-core"
gradle dependencies --configuration runtimeClasspath | rg "spring-expression"

Windows:

rg -n "SpelExpressionParser|ExpressionParser|parseExpression|StandardEvaluationContext|SimpleEvaluationContext|spring\\.expression|maxOperations|SpelParserConfiguration" .
mvn -q dependency:tree | rg "spring-expression|spring-core"
gradle dependencies --configuration runtimeClasspath | rg "spring-expression"

Remediation strategy

  • Upgrade Spring Framework to the fixed line for the supported branch.
  • Keep the default maxOperations threshold unless there is a measured need to raise it; higher values reduce the mitigation’s effectiveness.
  • Remove or constrain untrusted SpEL evaluation where feasible.
  • Add regression tests that confirm complex hostile expressions fail with the patched bounded behavior rather than consuming unbounded resources.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-41850, a Spring SpEL algorithmic denial-of-service
issue for untrusted expression evaluation. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Spring Framework, keeps safe
  expression bounds in place, adds safe regression checks, and documents
  operator actions, or
- TRIAGE.md if this repository does not control an affected untrusted SpEL
  evaluation path.

## Rules

- Scope only CVE-2026-41850 and directly related SpEL evaluation limits.
- Treat expressions, context objects, secrets, and business data as sensitive.
- Do not run unbounded evaluation tests against shared systems.
- Do not raise `maxOperations` casually; justify any deviation from the default.
- Do not auto-merge.

## Steps

1. Inventory Spring Framework dependencies, SpEL usage sites, rule engines,
   images, lockfiles, and SBOMs.
2. Determine whether any code path evaluates user-controlled SpEL.
3. Identify all targets resolving vulnerable Spring Framework versions.
4. If no affected path is controlled here, stop with `TRIAGE.md` listing
   checked files and the runtime owner if external.
5. Upgrade all controlled Spring Framework references to the fixed release.
6. Preserve the default SpEL `maxOperations` bound unless there is a documented
   and tested need to change it.
7. Remove or reduce untrusted expression evaluation where feasible.
8. Add safe regression tests that confirm hostile expressions terminate with the
   expected bounded failure rather than exhausting resources.
9. Add a PR body section named `CVE-2026-41850 operator actions` that states:
   - versions before and after;
   - which SpEL entry points were reviewed;
   - whether `maxOperations` remains default or was tuned;
   - which validation commands passed.
10. Run available validation: dependency resolution, unit tests, expression
    tests, container build, and security scans.
11. Use PR title:
    `fix(sec): remediate CVE-2026-41850 in Spring Framework`.

## Stop conditions

- No affected untrusted SpEL path is controlled here.
- Verification would require live resource exhaustion.
- Upgrade requires an out-of-scope platform migration.
- Validation fails for unrelated pre-existing reasons; document them instead of
  broadening scope.

Verification - what the reviewer looks for

  • No controlled build resolves a vulnerable Spring Framework line.
  • Untrusted SpEL paths are patched and bounded.
  • Tests cover the new bounded failure behavior.
  • Any maxOperations override is documented and justified.

Output contract

  • Reviewer-ready PR upgrading Spring Framework to the fixed release for every controlled branch and refreshing lockfiles, BOMs, images, SBOMs, and reports.
  • Evidence identifying untrusted SpEL entry points and whether the default maxOperations bound remains intact.
  • Safe regression tests that assert bounded failure for hostile expressions without unbounded resource-exhaustion runs.
  • TRIAGE.md when no affected untrusted SpEL path is controlled here or a platform migration is required.

Watch for

  • Raising maxOperations high enough to negate the fix.
  • Treating all SpEL usage as exposed when only user-controlled input matters.

References