Notifications
Clear all
Topic starter
25/06/2026 3:13 pm
TL;DR: A recent disclosure of 14 vulnerabilities in CyberArk Conjur and HashiCorp Vault showed that flaws in authentication and plugin design can be chained into remote code execution and even vault lockout, according to Aembit. The episode shows why secrets management remains necessary but insufficient when distributed workloads and agentic AI demand identity-driven access decisions at runtime.
NHIMG editorial — based on content published by Aembit: the recent disclosure of 14 vulnerabilities in CyberArk Conjur and HashiCorp Vault
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Audit default authentication paths Review every default integration, API endpoint, and authentication method in secrets platforms as if it were an external attack surface.
- Lock down plugin and extension governance Inventory all plugins, custom auth methods, and third-party extensions attached to vault infrastructure.
- Reduce dependence on reusable secrets Move workloads that can authenticate themselves to short-lived, policy-driven access using workload identity.
What's in the full article
Aembit's full article covers the operational detail this post intentionally leaves for the source:
- Specific vulnerability breakdowns across CyberArk Conjur and HashiCorp Vault that show how each flaw chain worked in practice.
- The authentication methods and plugin behaviours the researchers examined, including where the bypass conditions emerged.
- The direct comparison between secrets managers and workload IAM in cloud and AI environments, including the access model differences.
- The practical hardening implications for organisations that still depend on long-lived credentials and central vault repositories.
👉 Read Aembit's analysis of vault vulnerabilities and workload identity →
Vault vulnerabilities and secrets managers: where do controls fall short?
Explore further
25/06/2026 4:36 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vault vulnerabilities expose the limits of secrets-centric security
