CVE‑2026‑40981: Spring Cloud Config Secrets Access via Google Secrets Manager – What It Means for Your Business and How to Respond
Introduction
CVE‑2026‑40981 is a high‑severity vulnerability that can leak sensitive configuration secrets stored in Google Cloud across multiple projects, even if those projects were not intended to be visible to every client. For organizations in the United States and Canada that use Spring Cloud Config with Google Secrets Manager, this issue represents a serious risk to credentials, API keys, and other secrets that underpin application security and regulatory compliance. This post explains the business impact, common scenarios, how to determine if you are affected, and concrete next steps, with a separate technical appendix for engineers and pentesters.
S1 — Background & History
CVE‑2026‑40981 was disclosed in early May 2026 as a high‑severity information‑disclosure vulnerability in Spring Cloud Config when it uses Google Secrets Manager as a backend store. The issue allows a client that can reach the Config Server to craft a request that forces the server to return secrets from GCP projects other than the one associated with that client, effectively bypassing intended project‑level isolation. The vulnerability affects multiple maintained branches of Spring Cloud Config, including versions 3.1.x through 3.1.13, 4.1.x through 4.1.9, 4.2.x through 4.2.6, 4.3.x through 4.3.2, and 5.0.x through 5.0.2, with fixes released in corresponding 3.1.14, 4.1.10, 4.2.7, 4.3.3, and 5.0.3 releases. The CVSS v3.1 score is 7.5, classified as High severity, because it enables remote, unauthenticated attackers to obtain sensitive configuration data without user interaction.
S2 — What This Means for Your Business
If your organization runs Spring Cloud Config with Google Secrets Manager in development, staging, or production environments, this vulnerability can expose any project’s secrets that the Config Server has access to, including database credentials, cloud service keys, and internal API tokens. For a business in the U.S. or Canada, that translates into three main risk categories: operational continuity, data protection, and regulatory posture.
Operationally, leaked credentials can enable attackers to pivot into dependent systems such as databases, identity providers, or payment gateways, leading to degraded service, data corruption, or full‑account compromise. From a data‑protection standpoint, many of these secrets are considered sensitive or protected under frameworks like NIST, CIS, and sector‑specific regulations, so their exposure can trigger incident‑notification obligations and reputational damage. In highly regulated sectors such as financial services or healthcare, a breach of this nature can also complicate compliance with frameworks like HIPAA, GLBA, or even Canadian‑specific requirements, depending on the nature and location of the data involved.
S3 — Real‑World Examples
Healthcare platform using cloud‑based Spring services: A regional healthcare SaaS provider in the U.S. uses Spring Cloud Config with Google Secrets Manager to manage environment‑specific credentials for multiple customer environments. If attackers exploit CVE‑2026‑40981, they could access secrets from one tenant’s project, enabling follow‑on access to protected health information stored in that tenant’s environment, which would trigger mandatory reporting under HIPAA and serious brand‑reputation risk.
Mid‑sized fintech company with multi‑project cloud footprint: A Canadian fintech firm operates separate GCP projects for development, staging, and production but relies on a single Config Server that can read from all of them. An attacker who compromises a low‑privilege development environment could use this flaw to retrieve production‑only secrets, such as payment gateway keys or internal banking APIs, increasing the likelihood of direct financial loss or account takeover.
E‑commerce platform using Spring in North America: A U.S. e‑commerce company uses Spring Cloud Config to centralize secrets for its mobile apps, web frontends, and backend microservices, all backed by Google Secrets Manager. Exploitation of this CVE could allow an attacker to harvest API keys for cloud storage, identity providers, or analytics platforms, enabling follow‑on attacks such as data exfiltration, credential stuffing, or disruption of customer‑facing services.
Hybrid cloud environment for a regulated utility: A North American utility company runs a hybrid cloud pattern, using GCP‑hosted Spring Cloud Config for on‑prem microservices. If the Config Server is misconfigured to read from multiple projects, an attacker who gains access to one microservice can retrieve secrets used by other critical services, potentially affecting operational‑technology‑adjacent systems and complicating incident‑response and regulatory reporting timelines.
S4 — Am I Affected?
You are likely affected if any of the following apply:
You are running Spring Cloud Config with Google Secrets Manager as the backend store.
Your Spring Cloud Config version is 3.1.x through 3.1.13, 4.1.x through 4.1.9, 4.2.x through 4.2.6, 4.3.x through 4.3.2, or 5.0.x through 5.0.2.
Your Config Server has permission to read secrets from multiple GCP projects and you do not explicitly restrict client‑level access to project‑specific secrets.
You operate cloud‑native or microservices‑based applications in the United States or Canada that rely on centralized configuration and secrets stored in Google Cloud.
If all of the above are false, or if you already upgraded to the fixed versions (3.1.14+, 4.1.10+, 4.2.7+, 4.3.3+, or 5.0.3+) and do not use Google Secrets Manager as the Config Server backend, you are very likely not affected by this specific CVE. Nonetheless, it is prudent to verify configuration and access controls, because similar misconfigurations can still create unauthorized cross‑project data exposure.
OUTRO
Key Takeaways
CVE‑2026‑40981 enables unauthorized access to cloud secrets stored in Google Secrets Manager when used with affected Spring Cloud Config versions, even across different GCP projects.
For U.S. and Canadian businesses, this flaw can compromise operational integrity, expose sensitive data, and complicate regulatory and contractual obligations.
The risk is highest for organizations that use Spring Cloud Config with Google Secrets Manager and have broad project‑level read permissions without per‑client project isolation.
Immediate patching to the latest supported Spring Cloud Config versions and tightening of GCP IAM roles are the most effective ways to reduce exposure.
Even after patching, reviewing how configuration‑management services are integrated into your cloud architecture helps prevent similar cross‑project‑secrets‑leakage patterns.
Call to Action
If you operate Spring‑based or cloud‑native services in the United States or Canada, contact IntegSec to schedule a targeted penetration test and deep‑dive security review of your configuration and secrets‑management stack. Visit https://integsec.com to book a consultation and align your risk posture with industry‑best practices for cloud‑native and microservices environments.
TECHNICAL APPENDIX (security engineers, pentesters, IT professionals only)
A — Technical Analysis
CVE‑2026‑40981 is an improper access‑control issue in Spring Cloud Config when it uses Google Secrets Manager as its backend store. The root cause is that a client can manipulate configuration‑request parameters to force the Config Server to resolve secrets from any GCP project that the server’s service account is authorized to read, rather than only the project that corresponds to the intended environment or tenant.
The vulnerable component is the Google Secrets Manager integration layer in Spring Cloud Config, which is used to retrieve configuration‑backed secrets from GCP. The attack vector is network‑based, with an attacker sending specially crafted HTTP requests to the Config Server that include project‑level identifiers or labels, which the server then uses without sufficient validation. The attack requires no user interaction and does not require authentication, as long as the attacker can reach the Config Server endpoint; exploit complexity is therefore low. The CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, with a base score of 7.5, indicating High severity and an impact focused solely on confidentiality. The NVD entry classifies this as a CWE‑284: “Improper Access Control” issue.
B — Detection & Verification
From a detection standpoint, security teams can verify exposure by first enumerating the versions of Spring Cloud Config in use across their environment. Practically, this can be done by inspecting application manifests, container images, build artifacts, or dependency‑management files (for example, searching for spring-cloud-config-server and spring-cloud-gcp dependencies and their version tags). Where the service is running on a known host, the following approaches can narrow exposure:
Querying the Maven/Gradle dependency graph to confirm the Spring Cloud Config version.
Inspecting running processes or containers to identify the exact Spring Cloud Config and Spring Cloud GCP versions via packaged JAR metadata.
In terms of scanner signatures and behavioral indicators, the following patterns are useful:
Intrusion‑detection or web‑application firewall rules that flag HTTP requests to the Config Server containing highly unusual or malformed project identifiers, labels, or profiles that do not match expected tenant or environment naming.
Logs on the Config Server or Google Cloud API layer showing repeated, rapid reads from the Google Secrets Manager API for multiple distinct projects in response to a small number of client requests, especially from non‑privileged or external‑facing IP ranges.
Network‑level telemetry indicating anomalous outbound traffic from the Config Server to the GCP Secrets Manager API, with spikes in project‑scoped requests that deviate from normal operational patterns.
Because the vulnerability is information‑only and does not alter data or availability, there are no obvious on‑disk or in‑memory artifacts unique to exploitation; instead, detection depends on API‑level and request‑pattern telemetry.
C — Mitigation & Remediation
Immediate (0–24 hours)
Identify all Spring Cloud Config deployments that use Google Secrets Manager as the backend and confirm their versions using dependency enumeration or manifest inspection.
If the version is within the affected range (e.g., 3.1.x ≤ 3.1.13, 4.1.x ≤ 4.1.9, 4.2.x ≤ 4.2.6, 4.3.x ≤ 4.3.2, or 5.0.x ≤ 5.0.2), apply the official vendor patch or upgrade to the fixed versions (3.1.14+, 4.1.10+, 4.2.7+, 4.3.3+, or 5.0.3+) as quickly as possible, following your normal change‑control and regression‑testing procedures.
Short‑term (1–7 days)
Re‑evaluate the IAM roles assigned to the service account used by the Spring Cloud Config Server, removing any unnecessary read permissions to other GCP projects so that the server only has access to the project or projects it actually needs.
Add or tighten network‑level controls such as firewall rules or API gateways so that only known, trusted internal services or management subnets can reach the Config Server endpoint, reducing the blast radius of any unpatched instances.
Review and rotate any credentials or secrets that may have been exposed if exploitation is suspected, prioritizing production‑only keys and cross‑tenant secrets.
Long‑term (ongoing)
Establish a policy that Spring Cloud Config servers are never granted read access to more GCP projects than strictly required for their operational role, and enforce this via automated IAM‑review tools and continuous configuration‑monitoring.
Integrate secrets‑management and configuration‑management into your asset‑inventory and software‑composition‑analysis pipeline, so that vulnerable versions or misconfigured backends are flagged in CI/CD and pre‑production stages.
Implement centralized logging and correlation of GCP Secrets Manager API calls, with alerts on sudden increases in cross‑project secret reads or unusual client‑IP patterns, as part of your SOC’s playbook for configuration‑server‑related incidents.
For environments where patching cannot occur immediately, interim mitigations include:
Blocking or rate‑limiting external access to the Config Server and allowing only tightly scoped internal IP ranges.
Temporarily removing or restricting the service account’s ability to read from any GCP project other than the one that is strictly necessary, even if this requires some configuration changes in your application.
D — Best Practices
Enforce principle‑of‑least‑privilege for all service accounts that interact with secrets managers, granting read access only to the exact projects and resources required for that workload.
Never allow configuration‑management services to read from multiple tenant or environment projects without explicit, tenant‑aware isolation logic at the application layer.
Integrate configuration‑management components into your software‑composition‑analysis and vulnerability‑scanning pipeline so that outdated or vulnerable versions are detected before deployment.
Implement fine‑grained logging and monitoring of secrets‑manager API calls, with alerts on anomalous cross‑project or cross‑tenant access patterns.
Regularly rotate high‑value credentials and secrets, especially those exposed through configuration‑management systems, and treat those systems with the same security rigor as identity‑and‑access‑management components.