Miggo Logo

CVE-2025-35036: Hibernate Validator may interpolate user-supplied input in a constraint violation message with Expression Language

7.3

CVSS Score
3.1

Basic Information

EPSS Score
0.25988%
Published
6/3/2025
Updated
6/5/2025
KEV Status
No
Technology
TechnologyJava

Technical Details

CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Package NameEcosystemVulnerable VersionsFirst Patched Version
org.hibernate.validator:hibernate-validatormaven< 6.2.0.CR16.2.0.CR1
org.hibernate.validator:hibernate-validatormaven>= 7.0.0.Alpha1, < 7.0.0.CR17.0.0.CR1

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The vulnerability CVE-2025-35036 in Hibernate Validator allows for Expression Language (EL) injection when user-supplied input is part of a constraint violation message that gets interpolated. This occurs because, prior to the patches, the EL engine could evaluate these messages with overly permissive settings.

The analysis of the commits (primarily e076293b0ee1bfa97b6e67d05ad9eee1ad77e893 and 05f795bb7cf18856004f40e5042709e550ed0d6e/d2db40b9e7d22c7a0b44d7665242dfc7b4d14d78) reveals two key areas of change:

  1. EL Evaluation Context: The ElTermResolver.interpolate method, which performs the EL evaluation, was modified to use different ELContext implementations based on a new ExpressionLanguageFeatureLevel. Previously, it used a more permissive context (SimpleELContext) that allowed potentially dangerous operations like bean method execution by default when EL was active.
  2. EL Enabling for Custom Violations: The mechanism for building custom constraint violations, particularly methods within ConstraintValidatorContextImpl and its inner builder classes (like NodeBuilderBase.addConstraintViolation), was changed. EL interpolation for custom messages was made opt-in and disabled by default (feature level NONE). Before, it was enabled with fewer restrictions.

Therefore, org.hibernate.validator.internal.engine.messageinterpolation.ElTermResolver.interpolate is identified as a vulnerable function because it's where the EL execution happens with a previously permissive context. org.hibernate.validator.internal.engine.constraintvalidation.ConstraintValidatorContextImpl$NodeBuilderBase.addConstraintViolation (representing the culmination of the custom violation building process) is also identified because it's where a user-supplied template would be configured for this unsafe EL evaluation.

An attacker could exploit this by crafting input that, when included in a constraint violation message, forms a malicious EL expression. When Hibernate Validator attempts to interpolate this message, the malicious EL would be executed, potentially leading to information disclosure or arbitrary code execution, depending on the EL features available and the application's context.

Vulnerable functions

Only Mi**o us*rs **n s** t*is s**tion

WAF Protection Rules

WAF Rule

*i**rn*t* V*li**tor ***or* *.*.* *n* *.*.*, *y ****ult *n* **p*n*in* *ow it is us**, m*y int*rpol*t* us*r-suppli** input in * *onstr*int viol*tion m*ss*** wit* *xpr*ssion L*n*u***. T*is *oul* *llow *n *tt**k*r to ****ss s*nsitiv* in*orm*tion or *x**u

Reasoning

T** vuln*r**ility *V*-****-***** in *i**rn*t* V*li**tor *llows *or *xpr*ssion L*n*u*** (*L) inj**tion w**n us*r-suppli** input is p*rt o* * *onstr*int viol*tion m*ss*** t**t **ts int*rpol*t**. T*is o**urs ****us*, prior to t** p*t***s, t** *L *n*in*