External risk intelligence

Vault Secrets Webhook Service Account Token Leakage Vulnerability.

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2026-54725

This vulnerability exists within a Kubernetes mutating webhook, which is an internal cluster component used for pod admission and configuration. It is not designed to be exposed to the public internet and operates strictly within the infrastructure layer to manage internal secret injection.

Server-Side Request Forgery

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a critical vulnerability in the vault-secrets-webhook, a tool used within Kubernetes environments to inject secrets into pods. The issue could allow a low-privileged attacker to potentially send sensitive ServiceAccount information to an unintended Vault address, which may have significant security implications for organizations using this technology.

  • Secrets can be misdirected to unintended addresses.
  • Affects how secrets are managed in Kubernetes.
  • Confirm relevance and review affected systems.

Attack Path

How an attacker could exploit the issue

An attacker could trick the vault-secrets-webhook into sending a ServiceAccount JWT to a server they control. This happens when the webhook is configured with a malicious annotation pointing to an attacker-controlled Vault address, allowing it to send the JWT to that address instead of a legitimate Vault server. This could lead to sensitive information exposure and unauthorized access.

  • Attacker controls Vault server address.
  • Webhook configured with malicious annotation.
  • ServiceAccount JWT sent to attacker.

Live Threat

Current exploitation, exposure, and threat context

When supported by the advisory, this vulnerability could allow a malicious actor to intercept ServiceAccount JWTs intended for Vault. This could occur when the `vault-secrets-webhook` incorrectly processes annotations, leading to the ServiceAccount token being sent to an unauthorized Vault address.

  • ServiceAccount JWTs
  • Incorrect annotation processing
  • Unauthorized token exfiltration

Operational Fix

Recommended remediation, mitigation, and detection steps

This vulnerability impacts the vault-secrets-webhook, a Kubernetes component for secret injection. Infrastructure and platform teams managing Kubernetes environments are likely responsible for this component. The first step is to identify all instances of the affected webhook, determine their reachability and criticality, and then confirm ownership to plan remediation.

  • Platform/Infrastructure teams own this issue.
  • Verify webhook instances and their reachability.
  • Plan remediation based on verified exposure.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is the vault-secrets-webhook component?

It is a specialized Kubernetes tool that automatically injects secrets into your applications' Pods. By using custom annotations, it bridges the gap between your Vault instance and your containerized workloads, ensuring that sensitive credentials are available exactly when and where your containers need them to function.

How does CVE-2026-54725 work?

This vulnerability is classified as Server-Side Request Forgery (CWE-918). It occurs because the webhook fails to properly validate destination addresses provided in annotations. Consequently, the component can be manipulated into sending sensitive Kubernetes ServiceAccount tokens to an arbitrary, attacker-controlled server instead of your legitimate Vault.

Can this vulnerability be triggered by any user?

An attacker needs the ability to define or influence the specific annotations used by the webhook for a Pod. It is not triggered by normal application traffic or standard requests that do not involve these specific, maliciously crafted configuration annotations.

Is my cluster at risk if it is not internet-facing?

According to Halo Surface Signal, this component is an internal cluster utility not designed for public exposure. While being internal reduces your attack surface, anyone with the capability to submit Pod configurations to your cluster could potentially exploit this, regardless of whether the cluster is connected to the internet.

What are the first steps to address this issue?

Start by identifying every instance of vault-secrets-webhook running in your environment. Confirm which versions are currently deployed, and prioritize upgrading all instances to version 1.23.1 or later to implement the necessary validation fixes and prevent token misdirection.

References