Vault vulnerabilities expose the limits of secrets-centric security

At a glance

What this is: This analysis looks at 14 vulnerabilities in CyberArk Conjur and HashiCorp Vault and finds that authentication bypasses and plugin weaknesses can turn a secrets vault into a central compromise point.

Why it matters: It matters because IAM, PAM, and NHI programmes cannot treat a vault as the end state of governance when distributed workloads and agentic systems need contextual access decisions at runtime.

Context

Vault vulnerabilities matter because the control point that stores and distributes secrets can also become the highest-value target in the environment. When authentication paths or plugin ecosystems are weak, the issue is not only credential storage but the trust model that decides who or what can reach those credentials.

For NHI programmes, the central problem is that secrets-centric security assumes a repository can safely mediate access for static or predictable workloads. That assumption becomes fragile in cloud-native, multi-cloud, and agentic AI environments where access has to be evaluated continuously rather than handed out from a single store.

The article's core claim is that secrets managers still have a role, but they no longer cover the whole identity problem. Typical vault use is the starting point for modern workloads, not a complete operating model.

Key questions

Q: What breaks when a secrets vault has authentication logic flaws?

A: When a secrets vault has authentication logic flaws, attackers can often move from probing accounts to bypassing lockouts, impersonating identities, and escalating privileges inside the trust plane. The result is not just one compromised login, but potential exposure of downstream service accounts, tokens, and certificates that depend on the vault for issuance and control.

Q: Why do vault weaknesses create such a large blast radius?

A: Because vaults concentrate the organisation's keys, tokens, and credentials into one control point. If that repository is compromised, the attacker may gain access to multiple systems at once, and in some cases can even deny the organisation access to its own secrets. Concentration reduces operational sprawl, but it also concentrates failure.

Q: What signs suggest a secrets-management model is too centralised?

A: Look for many workloads depending on the same repository, extensive use of long-lived credentials, and repeated exceptions for custom integrations or plugin-based access. Those are signs that the vault is doing too much trust mediation and that the architecture is leaning on a single failure domain rather than distributed identity checks.

Q: How should teams decide when to complement a vault with workload identity?

A: Use workload identity when access must be contextual, short-lived, and validated at request time rather than issued as a reusable secret. That is especially important for distributed workloads, ephemeral infrastructure, and machine-driven automation where secret custody alone cannot express runtime intent or scope.

Technical breakdown

How authentication flaws turn vaults into compromise points

Secrets managers rely on upstream authentication paths before a credential is ever issued. If those paths can be bypassed, impersonated, or weakened by default integrations, an attacker does not need to steal a secret first. In the article, the researchers showed how authentication flaws in Conjur and Vault could be chained to reach remote code execution, including one unauthenticated API call that exposed full vault control. That is a control-plane failure, not just a bad password problem. The architecture assumes the vault can safely decide who is allowed in, but a broken authentication layer means the gate itself becomes the attack surface.

Practical implication: treat vault authentication paths as part of the attack surface, not as trusted plumbing.

Why plugin ecosystems expand the attack surface of secrets managers

Plugins extend a vault by letting it integrate with additional methods, workflows, and operational needs, but they also create code-execution pathways inside the trust boundary. If plugin loading is weakly controlled, an attacker who reaches that path can move from access to persistence. The article's example of malicious plugins shows why extensibility is not neutral: it can become a privilege escalation mechanism and a foothold for deeper compromise. Once code runs inside the vault context, the attacker is no longer just querying secrets. They are operating inside the system that protects those secrets, which collapses the normal separation between storage and execution.

Practical implication: constrain plugin loading and review every extension path as a privileged code surface.

What happens when a vault becomes the only trust anchor

A secrets-centric model centralises credentials, auditing, and rotation around one repository. That creates operational simplicity, but it also concentrates blast radius if the repository is compromised. The article describes how Vault could be inverted into a ransomware-style lockout, which is a reminder that the repository is not only a storage layer but a dependency for recovery and continuity. When every key, token, and credential lives behind the same control point, compromise does not stay local. The architecture converts a single access path into broad organisational exposure, which is why vault hardening alone cannot solve modern workload identity risk.

Practical implication: reduce single-repository dependence by distributing access control across identity and session-based checks.

Threat narrative

Attacker objective: The attacker objective is to take control of the secrets repository, extract or weaponise stored credentials, and potentially lock the organisation out of its own vault.

1. Entry occurred through authentication bypasses and an unauthenticated API path that let researchers reach vault functions without valid credentials.
2. Escalation followed when vulnerable authentication methods and malicious plugin loading enabled broader control over the vault and persistent access.
3. Impact included remote code execution, exposure of stored secrets, and in the worst case a vault lockout that could deny the organisation access to its own credentials.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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 necessary, but it is not a complete identity model for distributed systems. The article shows that vaults do what they were designed to do: store and rotate static credentials with auditability. The problem is that modern workloads increasingly need access decisions that are contextual, short-lived, and runtime driven, which makes a repository-centric trust model incomplete. For practitioners, the lesson is that vaults are a control point, not a full governance architecture.

Vault compromise is a blast-radius problem, not just a patching problem. When a single repository concentrates every key, token, and credential, failure at that point becomes systemic. The article's ransomware-style lockout example illustrates that the repository is now both a protection layer and a dependency for recovery. Practitioners should treat vault governance as part of resilience planning, because compromise can affect access continuity, not just confidentiality.

Identity-driven access is the right complement when workloads no longer fit a static secret workflow. The article makes clear that federated workload identity and policy-based access narrow the exposure window because they authenticate the workload at request time rather than distributing reusable secrets everywhere. That does not remove risk, but it changes the failure mode from repository-wide compromise to scoped session risk. For identity teams, that is the governance boundary shift worth tracking.

Traditional secrets architecture assumes trust is assigned once and reused many times. That assumption was designed for environments where access patterns were stable enough for static issuance and periodic rotation. It fails when distributed workloads, ephemeral infrastructure, and agentic AI need access decisions at runtime because trust has to be re-evaluated continuously. The implication is that access governance must move from secret custody to session-conditioned authorisation.

Runtime context is becoming a first-class control requirement for non-human identities. The article's comparison between vault-centric security and workload IAM shows that credentials alone do not express who or what should act at a given moment. That matters across NHI, automated systems, and agentic workflows because identity intent cannot be inferred from a stored secret. Practitioners should treat runtime policy evaluation as a core governance requirement, not an optimisation.

From our research library:

• Enterprises manage far more machine secrets than human ones: 20 times as many according to Enterprise Strategy Group, and 45 times according to GitGuardian.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret-centric governance has a ceiling: when the control point is also the concentration point, compromise becomes structurally expensive. Programmes that still treat the vault as the primary identity boundary should expect pressure to move policy enforcement closer to workload identity and runtime context.

The practical shift is from storing more secrets safely to issuing fewer reusable secrets at all. That change will reshape IAM, PAM, and NHI operating models because the decisive control moves from repository hardening to session-level authorisation.

For practitioners

• Harden vault authentication paths Review every authentication method, default integration, and API path that can reach the vault, then remove or isolate any route that can be used without strong identity proof.
• Restrict vault plugin execution Treat plugin loading as privileged code execution, with allowlisting, code review, and change control for every extension that runs inside the vault boundary.
• Reduce dependence on a single secrets repository Map workloads that still rely on long-lived secrets and shift the highest-risk ones toward workload identity and just-in-time access patterns where feasible.
• Separate vault recovery from vault trust Design backup, break-glass, and disaster recovery processes so that one compromised vault does not become the only path to restoring access.

Key takeaways

• The article shows that vault authentication and plugin weaknesses can turn a secrets manager into a full compromise point rather than a narrow storage control.
• The risk is amplified by centralisation because a single vault can hold the keys, tokens, and credentials that unlock much of the environment.
• The control lesson is to pair vaults with identity-driven, runtime access checks so that secrets storage is not the only line of defence.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.