Brief Summary: CVE-2026-40994 Spring Web Services BSP Enforcement Bypass via Insecure Default Initialization

Introduction

A silently disabled security control in one of the most widely deployed Java frameworks just exposed enterprise SOAP services to message integrity bypass. Spring Web Services' Wss4jSecurityInterceptor initialized its WS-I Basic Security Profile (BSP) compliance flag in a way that turned off BSP enforcement for inbound messages, contradicting the secure default built into the underlying Apache WSS4J library and leaving services open to accepting non-compliant WS-Security messages over the network.

With Spring powering applications at more than half of the Fortune 500, and SOAP based web services remaining a backbone of financial services, healthcare, and government integrations, the blast radius of this insecure default (scored CVSS 8.2) is significant. The vulnerability was disclosed on June 10, 2026 as part of what Broadcom described as the largest Spring security update in the framework's 23 year history.

Technical Information

Root Cause: Insecure Default Initialization (CWE-1188)

The vulnerability resides in the Wss4jSecurityInterceptor class within Spring Web Services. This component is responsible for enforcing WS-Security standards on SOAP messages by delegating cryptographic processing to Apache WSS4J. As part of its initialization, the interceptor configures a RequestData object that governs WSS4J's validation behavior for inbound messages.

The core flaw is straightforward: Wss4jSecurityInterceptor initialized its BSP compliance flag so that inbound validation disabled WSS4J BSP enforcement on RequestData. This directly contradicts the secure default established by Apache WSS4J itself. In WSS4J 1.6.x and later, the wsiBSPCompliant flag in WSSConfig defaults to true, meaning BSP checks are active unless explicitly turned off. The Spring WS interceptor's initialization logic overrode this secure default, effectively stripping BSP validation from any application using the interceptor without having explicitly called setBspCompliant(true).

This is classified under CWE-1188 ("Initialization of a Resource with an Insecure Default"), which describes weaknesses where "the product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure." The CWE documentation notes that "developers often choose default values that leave the product as open and easy to use as possible out of the box," which is precisely what occurred here.

What BSP Enforcement Actually Does

The WS-I Basic Security Profile (BSP) 1.1 specification provides an industry standard way of ensuring interoperability between different WS-Security stacks by clarifying and narrowing the scope of the various WS-Security standards. When BSP enforcement is active, WSS4J validates that inbound messages conform to strict rules regarding:

• Security element ordering
• Algorithm strength requirements
• Signature and timestamp profiles
• Token profile conformance

When BSP enforcement is disabled, these conformance checks are skipped entirely. Messages that violate BSP rules pass validation as if the rules did not exist.

Attack Flow

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N tells us the exploitation profile:

An attacker exploits this vulnerability through the following sequence:

1. Identify a target service that uses Wss4jSecurityInterceptor for inbound WS-Security validation. These are SOAP endpoints, commonly found in enterprise and government environments.
2. Craft SOAP messages that violate BSP rules. Because BSP enforcement is silently disabled by default, the service will accept these non-compliant messages.
3. The preconditions are: (a) the application uses Wss4jSecurityInterceptor or equivalent wiring for inbound WS-Security validation, and (b) BSP compliance has not been explicitly enabled via the setBspCompliant setter.

The insecure default is applied automatically, meaning most deployments using the interceptor would be vulnerable without any misconfiguration by the operator. The application appears to function normally; there is no error, no warning, and no indication that an entire class of validation has been silently disabled.

Distinction from Other CVEs in the Same Release

This vulnerability differs from the other six CVEs patched in the same release in an important way. While CVE-2026-40995 (disabled account bypass), CVE-2026-40996 (weak RSA algorithm), CVE-2026-40998 (XXE), and CVE-2026-40999 (SSRF) represent distinct implementation flaws, CVE-2026-40994 is a configuration default flaw. It does not require a logic error in the processing of a specific message construct; rather, it silently disables an entire class of validation. This makes it simultaneously harder to detect (the application appears to function normally) and broader in impact (all BSP defined checks are skipped).

The full set of CVEs addressed in the June 10, 2026 release:

Affected Systems and Versions

Four major version branches of Spring Web Services are affected:

Any application using Wss4jSecurityInterceptor for inbound WS-Security validation is vulnerable unless BSP compliance has been explicitly enabled via the setBspCompliant(true) setter. The 4.0.x and 3.1.x branches are no longer under active open source support and do not have public patches; fixes for these branches are available exclusively through VMware's Enterprise Support offering.

It is worth noting that Spring Framework 6.2 and Spring Boot 3.5 reach end of life on June 30, 2026, just weeks after this disclosure. Organizations on those versions face compounding pressure to upgrade both their Spring versions and their support contracts to maintain security coverage.

Vendor Security History

The Spring ecosystem has experienced a notable cadence of security advisories throughout 2026:

• CVE-2026-41842 and CVE-2026-41849: Spring Framework Denial of Service vulnerabilities
• CVE-2026-22732: Spring Security HTTP caching issues under certain conditions
• CVE-2026-40976: Spring Boot default web security bypass

The pattern of insecure default configurations has been a recurring theme in Spring security advisories. CVE-2026-40994 fits squarely into this pattern as another instance where a framework component shipped with a default that weakened security rather than enforcing it.

Broadcom's June 2026 coordinated release addressed seven security vulnerabilities simultaneously across Spring Web Services, described as the largest Spring security update in the framework's 23 year history. The scale was reportedly driven by a 1,700% monthly increase in AI discovered advisories affecting the Java and Spring ecosystem.

VulnCheck's analysis of routinely targeted vulnerabilities in 2026 documented cases where Spring adjacent vulnerabilities that were not exploited at time of disclosure were later used in the wild, underscoring the importance of prompt patching even in the absence of confirmed exploitation.

References

• Spring Security Advisory: CVE-2026-40994
• NVD Entry: CVE-2026-40994
• Spring Web Services 5.0.2 and 4.1.4 Release Announcement
• CWE-1188: Initialization of a Resource with an Insecure Default
• Apache WSS4J User Guide
• WS-I Basic Security Profile Version 1.0
• WSSConfig API Documentation (Apache WSS4J 1.6.12)
• WSS4J 1.6 Basic Security Profile 1.1 Compliance
• Wss4jSecurityInterceptor API Documentation
• Broadcom Bolsters Spring Security with Largest Update Ever
• Spring Security Advisories
• Spring Web Services Project Page
• VulnCheck: Quantifying 2026 Routinely Targeted Vulnerabilities
• CISA KEV Catalog Update (June 8, 2026)