https://feed.craftedsignal.io/tags/token-leak/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 17 Apr 2026 04:16:09 +0000https://feed.craftedsignal.io/briefs/2026-04-vault-token-leak/Fri, 17 Apr 2026 04:16:09 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-vault-token-leak/Vault instances configured to pass through the 'Authorization' header may forward Vault tokens to auth plugin backends when the header is used for authentication, potentially leading to token compromise; this vulnerability is tracked as CVE-2026-4525 and patched in versions 2.0.0, 1.21.5, 1.20.10, and 1.19.16.CVE-2026-4525 describes a vulnerability in HashiCorp Vault where an improperly sanitized “Authorization” header can lead to token exposure. Specifically, if a Vault auth mount is configured to pass through the “Authorization” header, and that header is used to authenticate with Vault, the Vault token itself is inadvertently forwarded to the auth plugin backend. This unintended token forwarding could allow malicious actors to gain unauthorized access if they can intercept or control the auth plugin backend. This issue affects Vault versions prior to 2.0.0, 1.21.5, 1.20.10, and 1.19.16 and was reported by HashiCorp. The vulnerability was patched in the aforementioned versions. Exploitation would require specific Vault configuration and the ability to influence the authentication process via the Authorization header.

Attack Chain

1. An attacker identifies a Vault instance with an auth mount configured to pass through the “Authorization” header.
2. The attacker crafts a malicious request to Vault, including a valid “Authorization” header for authentication purposes.
3. Vault processes the request and, due to the vulnerability, forwards the Vault token contained in the “Authorization” header to the configured auth plugin backend.
4. The attacker intercepts the forwarded Vault token, either by compromising the auth plugin backend or through network monitoring.
5. The attacker uses the stolen Vault token to authenticate directly to Vault, bypassing normal authentication procedures.
6. The attacker gains unauthorized access to sensitive data and secrets stored within Vault.
7. The attacker escalates privileges within the Vault environment by leveraging the compromised token’s permissions.

Impact

Successful exploitation of CVE-2026-4525 allows an attacker to steal Vault tokens, potentially granting them complete control over the Vault instance and access to all stored secrets. The severity is high due to the potential for complete compromise of sensitive data. The impact depends on the scope of secrets managed by the compromised Vault instance; in some cases, this could lead to a complete breach of the affected organization’s infrastructure. The vulnerability affects all organizations using vulnerable versions of Vault with auth mounts configured to pass through the “Authorization” header.

Recommendation

• Upgrade Vault instances to versions 2.0.0, 1.21.5, 1.20.10, or 1.19.16 or later to remediate CVE-2026-4525.
• Review Vault auth mount configurations to ensure that the “Authorization” header is not being passed through unnecessarily.
• Monitor network traffic for unauthorized access attempts using stolen Vault tokens after applying the patch.
• Implement the provided Sigma rule targeting the usage of specific auth paths after a potential compromise.

]]>highadvisoryvaulttoken-leakauthorizationcve-2026-4525https://feed.craftedsignal.io/briefs/2026-04-kyverno-token-leak/Tue, 14 Apr 2026 20:09:00 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-kyverno-token-leak/Kyverno's apiCall serviceCall helper implicitly injects the Kyverno controller service account token into requests when policies lack an explicit Authorization header, allowing exfiltration to attacker-controlled endpoints and unauthorized actions.A vulnerability exists in Kyverno versions prior to 1.17.0 where the apiCall and serviceCall helpers automatically inject the Kyverno controller’s service account token into outgoing requests. This occurs when a Kyverno policy does not explicitly define an Authorization header for the request. Because the destination URL for these API calls is policy-controlled via context.apiCall.service.url, a malicious actor could create or modify a ClusterPolicy or GlobalContextEntry to direct these requests—and thus the service account token—to an attacker-controlled endpoint. This vulnerability allows for token exfiltration and subsequent unauthorized actions, depending on the RBAC permissions granted to the Kyverno service account. This issue is limited to ClusterPolicy and global context usage, as namespaced policies are blocked from servicecall usage.

Attack Chain

1. Attacker gains the ability to create or modify ClusterPolicy objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.
2. Attacker crafts a malicious ClusterPolicy that uses the apiCall or serviceCall feature.
3. The policy specifies a URL for the context.apiCall.service.url that points to an attacker-controlled endpoint designed to capture the incoming request.
4. The crafted policy does not define an explicit Authorization header for the apiCall or serviceCall.
5. When the policy is triggered, Kyverno’s executor.addHTTPHeaders function detects the missing Authorization header.
6. Kyverno reads the service account token from /var/run/secrets/kubernetes.io/serviceaccount/token.
7. Kyverno injects the service account token into the request header as Authorization: Bearer <token>.
8. The request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.

Impact

Successful exploitation of this vulnerability results in the exfiltration of the Kyverno controller service account token. The severity of the impact depends on the RBAC roles and permissions assigned to the Kyverno service account within the Kubernetes cluster. With the stolen token, an attacker can perform any action that the Kyverno service account is authorized to perform, potentially leading to cluster-wide compromise, data breaches, or denial-of-service conditions. The number of affected clusters would depend on the number of Kyverno deployments using vulnerable versions.

Recommendation

• Upgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).
• Implement monitoring to detect modifications to ClusterPolicy resources, especially those utilizing apiCall or serviceCall to arbitrary URLs, to quickly identify potentially malicious policy changes.
• Deploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.
• As a workaround, set explicit Authorization headers in all apiCall and serviceCall policies to prevent the implicit token injection (see workarounds).

]]>highadvisorykyvernotoken-leakcloud