Vault vulnerabilities expose the limits of secrets-centric security

At a glance

What this is: The article argues that newly disclosed vault flaws show how secrets-centric security can be turned into full compromise when authentication and plugin controls fail.

Why it matters: For IAM teams, it reinforces that secrets storage, workload identity, and runtime authorisation must be treated as complementary controls rather than interchangeable layers.

👉 Read Aembit's analysis of vault vulnerabilities and workload identity

Context

Secrets management is meant to protect long-lived credentials, centralise storage, and support rotation, but it breaks down when authentication logic and extensibility become attack surfaces. In this case, flaws in CyberArk Conjur and HashiCorp Vault showed that a vault can become the control point that concentrates risk as much as it concentrates protection.

The primary identity question is not whether secrets should exist, but whether a programme still depends on static credentials in places where workload identity and runtime policy evaluation are possible. That tension is now sharper because distributed services and agentic AI reduce the usefulness of assumptions built for predictable, human-paced access patterns.

Key questions

Q: What breaks when a secrets manager is the only control protecting machine access?

A: A secrets manager can fail safely only if the rest of the environment does not assume it is the sole trust anchor. When authentication, plugin handling, or recovery paths are weak, one compromise can expose many credentials at once. That is why teams need workload identity and runtime policy, not storage alone, to constrain damage.

Q: Why do static secrets create higher blast radius in modern cloud environments?

A: Static secrets are reusable, durable, and often shared across systems, so a single leak can unlock multiple services. In cloud environments with distributed workloads, that multiplies risk because one credential often maps to broad operational reach. Short-lived identity decisions reduce that blast radius by making access narrower and more ephemeral.

Q: What do security teams get wrong about vault hardening?

A: They often treat vault hardening as the endpoint rather than one layer in a broader identity model. Hardening is necessary, but it does not solve the problem of how access is granted at runtime or how compromise is contained. A vault is safer when paired with conditional access and workload identity.

Q: Who should own the risk when secrets storage and workload identity both matter?

A: Identity, cloud, and platform teams should share accountability, but the control owner must be clear. Secrets storage owns custody, while workload identity owns runtime access decisions and blast-radius reduction. Governance fails when those responsibilities blur and no team is measuring the handoff between static credentials and ephemeral access.

Technical breakdown

Authentication bypass turns a vault into an execution path

Vaults and secrets managers rely on strong authentication boundaries before they release credentials or accept administrative actions. When a default integration, plugin hook, or authentication flow can be bypassed, the product stops being a passive store and becomes an entry point into the underlying trust plane. In the Conjur case described here, an unauthenticated API call and AWS identity impersonation were enough to move from access control into code execution. That is a structural failure, not just a missing patch, because the vault is supposed to be the place where identity is verified before privilege is granted.

Practical implication: audit every authentication path and default integration as a privileged entry point, not just the login surface.

Plugin extensibility can become a persistence mechanism

Secrets platforms often support plugins to extend authentication methods or operational workflows, but those extension points also expand the attack surface. If a malicious plugin can be loaded, the attacker may inherit the vault's trust context, persist beyond a single session, and alter how secrets are protected or decrypted. In the Vault findings, plugin abuse was serious because it did not merely expose data, it could sustain access and even invert protection logic. That means the security model depends as much on extension governance as on cryptography.

Practical implication: restrict plugin loading, validate code provenance, and treat extension governance as part of secrets platform hardening.

Workload identity reduces dependence on static secret stores

Workload identity shifts access from stored secrets to real-time verification of the calling workload. Instead of retrieving a reusable token from a central vault, the system asserts identity using federated attributes and then issues short-lived access according to policy and context. This architecture does not remove risk, but it narrows the blast radius when compromise happens. The contrast matters because vault-centric designs centralise trust in the repository, while identity-driven models distribute trust across verified workloads and ephemeral credentials.

Practical implication: use workload identity for systems that can authenticate themselves at runtime, and reserve vaults for the secrets that truly must remain static.

Threat narrative

Attacker objective: The attacker aims to turn a trusted secrets repository into a control plane that exposes, modifies, or locks away the organisation's credentials.

1. Entry occurred through authentication flaws and default integrations that let researchers bypass normal trust checks and impersonate AWS identities.
2. Escalation followed when those flaws chained into remote code execution, malicious plugin loading, and persistent control of the vault environment.
3. Impact included vault compromise, potential secret theft, and in the worst case ransomware-style lockout from the organisation's own secrets.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets management is a control for storage, not a complete identity model. Vaults are designed to safeguard static credentials, automate rotation, and centralise access to secrets. That design still matters, but it does not answer the runtime question of who or what should receive access in a distributed environment. The implication is that identity programmes must separate secret custody from access decisioning instead of treating one as a substitute for the other.

Centralising every key in one repository creates identity blast radius. The more an organisation depends on a single secrets store, the more attractive that store becomes as a target and the more severe the failure when it is compromised. This is not a vendor-specific problem. It is a governance pattern in which concentration of trust outruns the compensating controls around it. Practitioners should treat repository concentration as a structural exposure, not an implementation detail.

Static credentials are increasingly misaligned with ephemeral workloads and agentic automation. Vault-centric governance was designed for predictable access patterns and human-paced administration. That assumption weakens when workloads spin up and down quickly or when AI-driven automation acts across changing contexts. The implication is that access governance must evolve from secret distribution to conditional, runtime identity verification across machine and autonomous actors.

Runtime trust should be measured by how little a compromise can reveal, not by how much a vault can store. If a secrets platform can be turned into a full compromise through one authentication flaw or one plugin path, the programme has concentrated too much authority in one layer. The field should read these disclosures as evidence that vault hardening alone cannot carry the entire burden of NHI governance. Practitioners need layered identity controls that reduce the value of any single failure.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The 2024 State of Secrets Management Survey shows 54% of organisations are dissatisfied with their current secrets management solution, a reminder to compare centralised vaulting with workload identity governance.
• signals_placeholder

What this signals

Identity blast radius: the practical question is no longer whether a vault can store secrets, but how much of the environment fails if that vault is bypassed or locked. Teams that still rely on static credentials should treat secrets inventory, plugin control, and runtime access decisions as one governance chain rather than separate projects.

With 6 distinct secrets manager instances on average, fragmentation is already undermining centralised control in many programmes. That fragmentation becomes more dangerous when applications, cloud workloads, and AI automation move faster than manual rotation or review cycles.

If your programme is moving toward workload identity, anchor it to established guidance such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10, then use those references to decide where vault custody ends and runtime authorisation begins.

For practitioners

• Audit default authentication paths Review every default integration, API endpoint, and authentication method in secrets platforms as if it were an external attack surface. Prioritise paths that can impersonate cloud identities or bypass normal validation, then verify that only explicit, monitored trust relationships are allowed. This includes checking for hidden fallback behaviour in cloud identity bindings and MFA flows.
• Lock down plugin and extension governance Inventory all plugins, custom auth methods, and third-party extensions attached to vault infrastructure. Enforce provenance checks, restrict who can load code, and separate extension approval from operational administration so a vault operator cannot silently introduce a persistence mechanism.
• Reduce dependence on reusable secrets Move workloads that can authenticate themselves to short-lived, policy-driven access using workload identity. Keep the central vault for the secrets that must remain static, but stop using it as the default transport for every machine-to-machine interaction.
• Test lockout and blast-radius scenarios Simulate the failure of the central secrets repository and measure how many systems lose access at once. The goal is to know whether one vault compromise would expose the whole environment or whether identity segmentation actually limits the damage.

Key takeaways

• The disclosure shows that secrets managers can become single points of failure when authentication and extensibility are not tightly governed.
• The scale of the problem is measured in long remediation windows, high confidence that outpaces reality, and central repositories that magnify blast radius.
• Teams should keep vaults for custody but pair them with workload identity and runtime policy so compromise does not automatically become environment-wide exposure.

Key terms

• Secrets Manager: A secrets manager is a system for storing, distributing, and rotating credentials such as API keys, tokens, and certificates. In practice, it reduces manual handling of long-lived secrets, but it also becomes a high-value trust anchor when too many systems depend on it for access decisions.
• Workload Identity: Workload identity is the verified identity of a service, container, workload, or machine that authenticates itself at runtime. It replaces the need to distribute reusable secrets to every system, allowing access to be issued conditionally and with a narrower blast radius.
• Blast Radius: Blast radius is the amount of damage that can result when one identity control fails or is compromised. For non-human identity programmes, it describes how much access, data, or infrastructure a single leaked secret, misconfiguration, or vault compromise can expose.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Aembit: the recent disclosure of 14 vulnerabilities in CyberArk Conjur and HashiCorp Vault. Read the original.