{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata — refreshed continuously.","feed_url":"https://feed.craftedsignal.io/tags/token-leak/","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-4525"}],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["vault","token-leak","authorization","cve-2026-4525"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eCVE-2026-4525 describes a vulnerability in HashiCorp Vault where an improperly sanitized \u0026ldquo;Authorization\u0026rdquo; header can lead to token exposure. Specifically, if a Vault auth mount is configured to pass through the \u0026ldquo;Authorization\u0026rdquo; 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.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAn attacker identifies a Vault instance with an auth mount configured to pass through the \u0026ldquo;Authorization\u0026rdquo; header.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious request to Vault, including a valid \u0026ldquo;Authorization\u0026rdquo; header for authentication purposes.\u003c/li\u003e\n\u003cli\u003eVault processes the request and, due to the vulnerability, forwards the Vault token contained in the \u0026ldquo;Authorization\u0026rdquo; header to the configured auth plugin backend.\u003c/li\u003e\n\u003cli\u003eThe attacker intercepts the forwarded Vault token, either by compromising the auth plugin backend or through network monitoring.\u003c/li\u003e\n\u003cli\u003eThe attacker uses the stolen Vault token to authenticate directly to Vault, bypassing normal authentication procedures.\u003c/li\u003e\n\u003cli\u003eThe attacker gains unauthorized access to sensitive data and secrets stored within Vault.\u003c/li\u003e\n\u003cli\u003eThe attacker escalates privileges within the Vault environment by leveraging the compromised token\u0026rsquo;s permissions.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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\u0026rsquo;s infrastructure. The vulnerability affects all organizations using vulnerable versions of Vault with auth mounts configured to pass through the \u0026ldquo;Authorization\u0026rdquo; header.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Vault instances to versions 2.0.0, 1.21.5, 1.20.10, or 1.19.16 or later to remediate CVE-2026-4525.\u003c/li\u003e\n\u003cli\u003eReview Vault auth mount configurations to ensure that the \u0026ldquo;Authorization\u0026rdquo; header is not being passed through unnecessarily.\u003c/li\u003e\n\u003cli\u003eMonitor network traffic for unauthorized access attempts using stolen Vault tokens after applying the patch.\u003c/li\u003e\n\u003cli\u003eImplement the provided Sigma rule targeting the usage of specific auth paths after a potential compromise.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-17T04:16:09Z","date_published":"2026-04-17T04:16:09Z","id":"/briefs/2026-04-vault-token-leak/","summary":"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.","title":"Vault Token Leak via Authorization Header Forwarding","url":"https://feed.craftedsignal.io/briefs/2026-04-vault-token-leak/"},{"_cs_actors":[],"_cs_cves":[],"_cs_exploited":false,"_cs_products":[],"_cs_severities":["high"],"_cs_tags":["kyverno","token-leak","cloud"],"_cs_type":"advisory","_cs_vendors":[],"content_html":"\u003cp\u003eA vulnerability exists in Kyverno versions prior to 1.17.0 where the \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e helpers automatically inject the Kyverno controller\u0026rsquo;s service account token into outgoing requests. This occurs when a Kyverno policy does not explicitly define an \u003ccode\u003eAuthorization\u003c/code\u003e header for the request. Because the destination URL for these API calls is policy-controlled via \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e, a malicious actor could create or modify a \u003ccode\u003eClusterPolicy\u003c/code\u003e or \u003ccode\u003eGlobalContextEntry\u003c/code\u003e 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 \u003ccode\u003eClusterPolicy\u003c/code\u003e and global context usage, as namespaced policies are blocked from \u003ccode\u003eservicecall\u003c/code\u003e usage.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker gains the ability to create or modify \u003ccode\u003eClusterPolicy\u003c/code\u003e objects, potentially by compromising a GitOps repository or controller managing Kyverno policies.\u003c/li\u003e\n\u003cli\u003eAttacker crafts a malicious \u003ccode\u003eClusterPolicy\u003c/code\u003e that uses the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e feature.\u003c/li\u003e\n\u003cli\u003eThe policy specifies a URL for the \u003ccode\u003econtext.apiCall.service.url\u003c/code\u003e that points to an attacker-controlled endpoint designed to capture the incoming request.\u003c/li\u003e\n\u003cli\u003eThe crafted policy does not define an explicit \u003ccode\u003eAuthorization\u003c/code\u003e header for the \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eWhen the policy is triggered, Kyverno\u0026rsquo;s \u003ccode\u003eexecutor.addHTTPHeaders\u003c/code\u003e function detects the missing \u003ccode\u003eAuthorization\u003c/code\u003e header.\u003c/li\u003e\n\u003cli\u003eKyverno reads the service account token from \u003ccode\u003e/var/run/secrets/kubernetes.io/serviceaccount/token\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eKyverno injects the service account token into the request header as \u003ccode\u003eAuthorization: Bearer \u0026lt;token\u0026gt;\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eThe request, including the Kyverno service account token, is sent to the attacker-controlled endpoint, allowing the attacker to exfiltrate the token.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpgrade Kyverno to version 1.17.0 or later to patch the vulnerability (go/github.com/kyverno/kyverno).\u003c/li\u003e\n\u003cli\u003eImplement monitoring to detect modifications to \u003ccode\u003eClusterPolicy\u003c/code\u003e resources, especially those utilizing \u003ccode\u003eapiCall\u003c/code\u003e or \u003ccode\u003eserviceCall\u003c/code\u003e to arbitrary URLs, to quickly identify potentially malicious policy changes.\u003c/li\u003e\n\u003cli\u003eDeploy the provided Sigma rule to detect unexpected outbound network connections from the Kyverno pod that may indicate token exfiltration.\u003c/li\u003e\n\u003cli\u003eAs a workaround, set explicit \u003ccode\u003eAuthorization\u003c/code\u003e headers in all \u003ccode\u003eapiCall\u003c/code\u003e and \u003ccode\u003eserviceCall\u003c/code\u003e policies to prevent the implicit token injection (see workarounds).\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-04-14T20:09:00Z","date_published":"2026-04-14T20:09:00Z","id":"/briefs/2026-04-kyverno-token-leak/","summary":"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.","title":"Kyverno Service Account Token Leak via API Call","url":"https://feed.craftedsignal.io/briefs/2026-04-kyverno-token-leak/"}],"language":"en","title":"CraftedSignal Threat Feed — Token-Leak","version":"https://jsonfeed.org/version/1.1"}