CVE-2025-35036: Hibernate Validator may interpolate user-supplied input in a constraint violation message with Expression Language
7.3
Basic Information
Technical Details
Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
---|---|---|---|
org.hibernate.validator:hibernate-validator | maven | < 6.2.0.CR1 | 6.2.0.CR1 |
org.hibernate.validator:hibernate-validator | maven | >= 7.0.0.Alpha1, < 7.0.0.CR1 | 7.0.0.CR1 |
Vulnerability Intelligence
Miggo AI
Root 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:
- EL Evaluation Context: The
ElTermResolver.interpolate
method, which performs the EL evaluation, was modified to use differentELContext
implementations based on a newExpressionLanguageFeatureLevel
. Previously, it used a more permissive context (SimpleELContext
) that allowed potentially dangerous operations like bean method execution by default when EL was active. - EL Enabling for Custom Violations: The mechanism for building custom constraint violations, particularly methods within
ConstraintValidatorContextImpl
and its inner builder classes (likeNodeBuilderBase.addConstraintViolation
), was changed. EL interpolation for custom messages was made opt-in and disabled by default (feature levelNONE
). 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.