CVE-2025-22233

What it actually does

This is a Spring Framework data-binding authorization bypass in applications that rely on WebDataBinder disallowedFields denylist rules to prevent request parameters from being bound to sensitive object properties. Certain request parameter name forms can bypass the disallowedFields check, allowing a network-accessible, authenticated attacker to set fields the application intended to block. The impact is primarily unauthorized modification of server-side model state, with scope and severity depending on which protected properties are present on bound objects. It does not inherently provide code execution, data disclosure, or denial of service.

Why it matters to the business

Affected applications may allow users to change values they should not control, such as workflow state, ownership fields, administrative flags, pricing-related fields, approval attributes, or other sensitive business properties if those fields are present in bindable model objects. The CVSS and EPSS are low, it is not in CISA KEV, and no public exploit maturity is indicated, but the issue has been public for a long time and is most relevant for applications that use denylist-based Spring data binding on security-sensitive fields. The supplied package metadata references Ubuntu qemu packages, while the vulnerability description is for Spring Framework; teams should verify advisory-to-asset mapping before treating qemu package updates as remediation for this issue.

How an attack unfolds

An attacker first identifies an endpoint implemented with Spring MVC or related Spring data binding where request parameters are automatically bound onto an object. The attacker needs an account or other valid application access, consistent with the low-privilege requirement. They then infer or discover sensitive object property names that the application attempted to protect using disallowedFields, such as fields controlling role, state, ownership, or approval. By crafting HTTP form, query, or JSON-style parameter names in a representation that bypasses the disallowedFields comparison, the attacker submits a request that includes otherwise-blocked fields. If the endpoint performs setter binding and later trusts the mutated object, the application may persist or act on unauthorized values, resulting in limited integrity compromise.

How to fix it

Upgrade affected Spring Framework versions to the fixed release for the active line: Spring Framework 6.2.x to 6.2.7 or later, 6.1.x to 6.1.20 or later, 6.0.x to 6.0.28 or later where commercially available, and 5.3.x to 5.3.43 or later where commercially available. Older unsupported Spring Framework versions should be upgraded to a supported fixed line. In addition to patching, prefer dedicated request/data-transfer objects that contain only fields intended for client binding, use constructor binding where appropriate, and disable setter binding through declarativeBinding when possible. For setter binding, use allowedFields allowlists rather than disallowedFields denylists. The input also lists Ubuntu qemu fixed packages, but those do not align with the Spring Framework vulnerability description; validate package applicability against vendor advisories before using them as the corrective action for this CVE.

How to confirm the fix worked

Confirm dependency resolution shows a fixed Spring Framework version in every deployed artifact, including transitive dependencies and shaded or bundled libraries. Review build outputs such as Maven dependency trees, Gradle dependency reports, container image SBOMs, and runtime classpaths for org.springframework:spring-web, spring-webmvc, spring-context, and related Spring Framework modules. Test representative endpoints that use data binding by attempting to submit fields that are supposed to be blocked and verify they are rejected or ignored after upgrade. Review code for WebDataBinder, @InitBinder, setDisallowedFields, declarativeBinding, allowedFields, and broad model objects exposed to request binding. Where the supplied asset inventory identifies qemu rather than Spring, reconcile the vulnerability record with the authoritative vendor advisory before closing remediation.

Typical attack path

1. Find a Spring-based endpoint that accepts user-controlled parameters and binds them to a model object.
2. Authenticate or obtain low-privilege access required to call the endpoint.
3. Identify fields that should not be user-controlled but may exist on the bound object.
4. Craft request parameters using bypassable field-name variants that evade disallowedFields checks.
5. Submit the request and observe whether the protected property is accepted, reflected, persisted, or changes application behavior.
6. Use the unauthorized field modification to alter business state, permissions, ownership, approval status, or other sensitive attributes.

How to detect it

Detection is application-specific because exploitation depends on which endpoints use Spring data binding and which fields are protected by disallowedFields. Review HTTP access logs, WAF logs, reverse proxy logs, application audit logs, and application debug/error logs for requests containing unusual parameter names aimed at internal object properties or Spring binding internals. Focus on state-changing methods such as POST, PUT, PATCH, and multipart/form submissions. Look for successful requests where protected attributes changed shortly after parameters with case variants, nested property paths, bracket notation, or class-loader-style property paths were submitted. Review application logs for BindingResult, bind exception, type mismatch, suppressed field, or validation anomalies around the same timestamps. If business audit logs exist, correlate suspicious requests with unexpected changes to roles, ownership, approval state, account status, prices, limits, workflow transitions, or other sensitive fields. No universal indicator proves exploitation; confirmation usually requires correlating malicious-looking parameters with unauthorized persisted state changes.

• class.module.classLoader
• class.classLoader
• module.classLoader
• Class.Module.ClassLoader
• class["module"]["classLoader"]
• class['module']['classLoader']
• getClass.classLoader
• setDisallowedFields
• disallowedFields
• BindingResult
• BindException
• NotWritablePropertyException
• Invalid property
• Suppressed field
• Field error in object

What your security team should do

• Prioritize patching internet-facing or user-facing Spring applications that use WebDataBinder disallowedFields or broad setter binding on domain objects.
• Upgrade Spring Framework to 6.2.7, 6.1.20, 6.0.28, 5.3.43, or a later fixed version appropriate for the product line.
• Perform targeted code review for @InitBinder, setDisallowedFields, and model objects that contain sensitive fields not intended for user input.
• Replace denylist-based binding controls with explicit allowlists or dedicated DTOs that expose only permitted client-controlled properties.
• Add regression tests that submit protected field names and verify they cannot be bound or persisted.
• Search application and access logs for suspicious parameter names associated with Spring binding abuse, especially on endpoints that modify account, workflow, authorization, or ownership state.
• Reconcile asset inventory inconsistencies where this CVE is mapped to non-Spring packages, and correct SBOM or vulnerability scanner mappings if necessary.