CVE-2026-22750

NVD entry not available yet.

Vulnerability Details

FieldValueCVE IDCVE-2026-22750PROJECT AFFECTEDSpring Cloud GatewayVERSIONS AFFECTED< NES For Spring v4.2.8FIXED INNES For Spring v4.2.8~ FIX DATEunknownSEVERITYUNKNOWNCATEGORYNot classified

Overview

Spring Cloud Gateway is a library built on top of the Spring ecosystem that provides API gateway functionality for microservices architectures. It handles routing, load balancing, and cross-cutting concerns such as security, monitoring, and resiliency for downstream services. Starting with version 4.2.0, Spring Cloud Gateway added support for Spring Boot's SSL Bundles : a centralized way to configure SSL/TLS trust material (keystores, truststores, and certificates) using the spring.ssl.bundle configuration property.This feature allows administrators to define named bundles of SSL settings and reference them across the application, simplifying mutual TLS (mTLS) setups and custom certificate chain management.

This vulnerability affects applications using Spring Cloud Gateway 4.2.0 that configure SSL bundles via spring.ssl.bundle properties. The problem is that a wrong condition in the auto-configuration logic causes the SSL bundle to be silently ignored. The gateway falls back to the JVM's default SSL context without logging any warning, leaving administrators with a false sense of security.

Details

Module Info

Product: Spring Cloud Gateway
Affected packages: spring-cloud-gateway-server
Affected versions: < NES For Spring v4.2.8
GitHub repository:
Published packages: https://central.sonatype.com/artifact/org.springframework.cloud/spring-cloud-gateway-server
Package manager: Maven
Fixed In: NES For Spring v4.2.8

Vulnerability Info

A vulnerability (CVE-2026-22750) exists in Spring Cloud Gateway's handling of SSL bundle configuration. When configuring SSL bundles using the spring.ssl.bundle configuration property, the gateway silently ignores the configuration and falls back to the default SSL configuration instead. This is an instance of Not Failing Securely (CWE-636), where the application fails to enforce a security-critical configuration and instead reverts to a weaker default without alerting the user.

In this case, an administrator who has explicitly configured custom SSL bundles - for example, to enforce mutual TLS (mTLS), use specific trust stores, or restrict certificate authorities - would unknowingly be operating with the JVM's default SSL configuration. This creates a false sense of security: the configuration appears to be in place, but the gateway is not actually applying it.

The root cause is a wrong condition check in the SSL bundle auto-configuration logic introduced in version 4.2.0. The conditional expression that determines whether to apply the SSL bundle configuration evaluates incorrectly, causing the custom bundle to be skipped entirely. Because the fallback is silent (no warning or error is logged), the issue can go undetected in production environments.

An attacker positioned on the network path between the gateway and downstream services could potentially exploit this to:

Intercept traffic that was intended to be protected by a specific certificate chain
Bypass mutual TLS requirements that were configured but not enforced
Access services that were meant to be restricted to clients presenting specific certificates