Spring Cloud Config CVE-2026-47894

Exploitation requires that the Spring Cloud Config Server be actively configured to use the native environment repository backend - specifically, that spring.cloud.config.server.native is the active profile and spring.cloud.config.server.native.searchLocations points to a local filesystem path. Deployments using Git, SVN, HashiCorp Vault, or other non-native backends are NOT affected by this flaw. The PR:N CVSS rating applies when the Config Server is deployed without Spring Security authentication (common in internal service-mesh deployments relying on network controls); environments that enforce HTTP Basic, OAuth2, or mTLS authentication require valid credentials, partially mitigating the unauthenticated vector. The flaw is strictly read-only - no file writes, no command execution, and no integrity or availability impact. Exploitation is further bounded by the OS-level filesystem permissions of the Config Server process user.

The CVSS 7.5 score (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) reflects a worst-case scenario where the Config Server is network-reachable without authentication, which is plausible in internal microservices deployments relying on network-layer controls rather than application-level auth. However, the real-world risk picture is more nuanced: EPSS sits at just 0.32% (24th percentile), and SSVC classifies exploitation as 'none' with 'Automatable: no' - meaning exploitation requires non-trivial path knowledge specific to the target server's filesystem layout, preventing opportunistic mass scanning. The SSVC 'Automatable: no' finding creates a tension with the AC:L CVSS metric; this is best resolved by understanding that CVSS AC measures attacker-independent conditions, while SSVC automatability reflects the practical difficulty of building a reliable exploit chain without target-specific knowledge. The SSVC 'Technical Impact: partial' rating appears conservative given that unrestricted filesystem reads could expose private keys, database credentials, or application secrets co-located with configuration data - effectively a 'total' confidentiality breach in many real deployments. The broad version coverage spanning 3.x through 5.x and the architectural role of Config Server as a single point holding secrets for entire microservices estates elevates priority above what the low EPSS score alone would suggest. No active exploitation is confirmed by any intelligence source.

An attacker with HTTP access to a Spring Cloud Config Server using the native filesystem backend sends a request to the configuration endpoint with a crafted application name or label containing path traversal sequences (for example, requesting the profile '../../etc/passwd' or encoding traversal characters to bypass naive filters). The server's native repository resolver follows the traversal, reads the target file from the server's local filesystem, and returns its contents in the HTTP response body. In a typical enterprise deployment where Config Server hosts application secrets, this yields database passwords, API keys, or TLS private keys without requiring any credentials.