CVE-2026-40994 - Spring WS BSP validation disabled by default

Affected Spring Web Services releases initialized Wss4jSecurityInterceptor so inbound WS-Security processing did not enforce WS-I Basic Security Profile rules unless BSP compliance was explicitly turned on. Services relying on the default interceptor setup could accept SOAP messages that violate expected signature and protocol constraints.

This is an exposure issue only where the application actually performs inbound WS-Security validation. If the repository just depends on Spring WS but does not use Wss4jSecurityInterceptor for network-facing SOAP requests, the right outcome may be triage rather than patching.

When to use it

  • A repository builds or deploys Spring Web Services SOAP endpoints with inbound WS-Security validation.
  • Wss4jSecurityInterceptor, XML bean definitions, Java config, or custom interceptors process partner/customer SOAP messages.
  • BSP compliance is not explicitly enabled, or legacy configuration may shadow the fixed Spring WS default.
  • You need a bounded PR or triage note that upgrades Spring WS or forces BSP compliance without replaying sensitive production SOAP traffic.

Inputs

  • Maven/Gradle manifests, locks, Spring WS config, XML bean definitions, Java interceptor wiring, SOAP endpoint code, Dockerfiles, images, SBOMs, and generated dependency reports.
  • Inbound SOAP endpoint inventory, partner reachability, WS-Security policy, certificate/key handling, BSP compliance flags, custom interceptors, and rollout owners.
  • Available dependency resolution, SOAP security tests, container builds, SBOM, and dependency/security scans.

Affected versions

  • Vulnerable package: Spring Web Services 3.1.0-3.1.8, 4.0.0-4.0.18, 4.1.0-4.1.3, 5.0.0-5.0.1
  • Fixed versions: 3.1.9, 4.0.19, 4.1.4, 5.0.2
  • Mitigation if upgrade is blocked: set setBspCompliant(true) on Wss4jSecurityInterceptor

Indicator-of-exposure

  • The repository runs SOAP endpoints using Spring Web Services.
  • Inbound security is enforced with Wss4jSecurityInterceptor or equivalent wiring.
  • The configuration never explicitly enables BSP compliance.
  • SOAP endpoints are reachable from partners, customers, external systems, or less-trusted internal callers.

Quick checks:

rg -n "Wss4jSecurityInterceptor|setBspCompliant|spring-ws|PayloadRoot|EnableWs|WsConfigurerAdapter|XwsSecurityInterceptor" .
mvn -q dependency:tree | rg "spring-ws|spring-ws-core|spring-ws-security"
gradle dependencies --configuration runtimeClasspath | rg "spring-ws"

Windows:

rg -n "Wss4jSecurityInterceptor|setBspCompliant|spring-ws|PayloadRoot|EnableWs|WsConfigurerAdapter|XwsSecurityInterceptor" .
mvn -q dependency:tree | rg "spring-ws|spring-ws-core|spring-ws-security"
gradle dependencies --configuration runtimeClasspath | rg "spring-ws"

Remediation strategy

  • Upgrade Spring Web Services to the fixed version for the supported branch.
  • If a same-day upgrade is not possible, explicitly set BSP compliance to true anywhere Wss4jSecurityInterceptor is constructed or configured.
  • Add regression tests that prove inbound messages violating BSP rules are rejected after the fix.
  • Review whether any custom interceptors or XML bean definitions shadow the safe default and keep them aligned with the fixed behavior.

The prompt

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

You are remediating CVE-2026-40994, where Spring Web Services inbound
`Wss4jSecurityInterceptor` validation may run without WS-I BSP enforcement by
default. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Spring WS or explicitly
  enables BSP compliance, adds safe regression checks, and documents operator
  actions, or
- TRIAGE.md if this repository does not control an affected inbound Spring WS
  security path.

## Rules

- Scope only CVE-2026-40994 and directly related inbound WS-Security
  validation.
- Treat SOAP payloads, certificates, keys, tokens, and partner metadata as
  sensitive.
- Do not weaken WS-Security requirements or accept malformed messages for test
  convenience.
- Do not auto-merge.

## Steps

1. Inventory Spring WS dependencies, SOAP endpoint config, interceptor wiring,
   XML bean definitions, images, lockfiles, and SBOMs.
2. Determine whether `Wss4jSecurityInterceptor` is used for inbound message
   validation and whether BSP compliance is explicitly enabled.
3. Identify all targets resolving vulnerable Spring WS versions.
4. If no affected inbound WS-Security path is controlled here, stop with
   `TRIAGE.md` listing checked files and the external owner if applicable.
5. Upgrade to the fixed release for the maintained branch. Refresh generated
   dependency artifacts.
6. If upgrade is temporarily blocked, set `setBspCompliant(true)` explicitly in
   every affected interceptor configuration and document this as containment.
7. Add or update tests that verify invalid or non-compliant inbound WS-Security
   messages are rejected without exposing real secrets.
8. Add a PR body section named `CVE-2026-40994 operator actions` that states:
   - versions before and after;
   - which SOAP endpoints use inbound WS-Security;
   - whether explicit BSP enforcement was added as containment;
   - which validation commands passed.
9. Run available validation: dependency resolution, SOAP security tests,
   container build, and security scans.
10. Use PR title:
    `fix(sec): remediate CVE-2026-40994 in Spring WS`.

## Stop conditions

- No affected inbound Spring WS security path is controlled here.
- Validation requires replaying sensitive production SOAP traffic or live keys.
- Upgrade needs an out-of-scope framework 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 WS line, or explicit BSP enforcement is present as documented containment.
  • Inbound WS-Security tests fail closed on non-compliant messages.
  • All interceptor construction paths consistently enable the safe behavior.

Output contract

  • Reviewer-ready PR upgrading Spring WS to the fixed branch release or adding explicit setBspCompliant(true) containment everywhere inbound Wss4jSecurityInterceptor is configured.
  • Regression tests proving non-compliant inbound WS-Security messages are rejected without exposing real SOAP payloads, certificates, keys, or tokens.
  • Evidence that Java config, XML beans, custom interceptors, generated reports, SBOMs, images, and deployment artifacts agree on the fixed behavior.
  • TRIAGE.md when no inbound Spring WS security path is present or SOAP runtime ownership is outside this repository.

Watch for

  • Java config fixed while legacy XML bean definitions still instantiate the old unsafe default.
  • Teams assuming outbound SOAP signing matters here; the issue is inbound validation.

References