Researchers have found 14 logic flaws in various components of HashiCorp Vault and CyberArk Conjur, two open-source credential management systems, allowing attacks that could bypass authentication checks, access secrets, impersonate identities and execute arbitrary code.
In enterprise environments, non-human identities, such as those used by applications and machines, are estimated to outnumber human identities 150 to 1. This makes credential management systems, which often hold what can be considered the “keys to the kingdom,” a critical component of IT infrastructure.
Recognizing this, researchers from cybersecurity firm Cyata analyzed two widely used open-source secrets management solutions: HashiCorp Vault and CyberArk Conjur. Their findings, which include 14 vulnerabilities that enable remote code execution (RCE) attack chains in both products, were presented today at the Black Hat USA security conference in Las Vegas.
“Secrets vaults are the backbone of digital infrastructure,” the researchers wrote in their report. “They store the credentials, tokens, and certificates that govern access to systems, services, APIs, and data. They’re not just part of the trust model — they are the trust model. In other words, if your vault is compromised, your infrastructure is already lost.”
HashiCorp Vault and CyberArk Conjur do more than just store secrets. They allow organizations to define policies for accessing and using those secrets, offering role-based access controls, automated secrets rotation, auditing, and more. Designed for integration with DevOps tools, these systems are often part of CI/CD pipelines.
The attack chains discovered by Cyata, responsibly disclosed to HashiCorp and CyberArk and now patched, stemmed from subtle logic flaws in authentication, validation, and policy enforcement mechanisms. The flaws enabled lockout bypasses, policy check evasion and account impersonation.
Missing validation checks enable Conjur compromise
Cyata’s attack chain against CyberArk Conjur began with a simple error in the code used to validate AWS IAM identities. Conjur supports authentication for AWS instances via AWS’s Security Token Service (STS), allowing workflows to authenticate without hardcoded credentials.
To authenticate, an AWS instance generates a signed header, which Conjur forwards to AWS STS. STS validates the signature and returns the instance’s identity. However, STS servers are region-specific. For example, instances in us-east-1 must use sts.us-east-1.amazonaws.com and Conjur determines the correct STS region based on the instance’s hostname included in the signed header.
The issue is that the hostname in the header can be controlled by the attacker. And while this wouldn’t be a problem because a fake signature would normally fail validation by a legitimate STS instance, Conjur’s code failed to sanitize special characters like ‘?’ in the hostname.
This allowed researchers to craft a request with a hostname such as sts.cyata.ai?, which the Conjur code transformed into sts.cyata.ai?.amazonaws.com, appending the correct domain. However, in practice, the portion after the added question mark gets ignored in URLs so the requests get sent to sts.cyata.ai, a rogue STS server under the researchers’ control, passing validation.
“This was the first step in the chain, where a completely unauthenticated attacker could now enter the system, appearing to be a legitimate AWS identity,” the researchers explained.
From identity forgery to full RCE
An AWS instance identity typically corresponds to a hostname. But the researchers explored how this could be abused within Conjur’s resource model, which uses three parameters: Account (Conjur account name), Kind (resource type — host, user, variable, policy, etc.), and Identifier (unique resource name). These parameters are also used in API queries.
They discovered that Conjur’s authentication logic didn’t validate the “kind” part of an identity. This meant they could use their spoofed AWS identity to authenticate as a user or policy in the system instead of a host, significantly expanding the attack surface.
“This step changed the game,” they said. “It bridged the gap between unauthenticated access and a meaningful attack surface in Conjur. By combining a forged STS response, a policy identity instead of a host, and flaws in the Host Factory flow, we gained the ability to mint new hosts with names and ownership entirely under our control.”
Next, they examined Conjur’s Policy Factory, a mechanism that allows admins to apply reusable policy templates to new resources. These templates can contain Embedded Ruby (ERB) code that gets executed when applied.
Their goal was creating a template with arbitrary ERB code to achieve arbitrary code execution, but since Conjur doesn’t include built-in templates by default, they couldn’t abuse an existing one.
The researchers determined that policy templates were stored in Conjur’s secrets table and secrets were only intended to be assigned to resources of type variable, not hosts. However, in practice Conjur’s code didn’t enforce this restriction.
Further inspection revealed additional validation gaps. For example, a query like {Account}:variable:conjur/factories/{kind} didn’t validate the Account field. By specifying an account name like MyAccount:host, they transformed the resource ID into MyAccount:host:variable:conjur/factories/{kind}.
“This was the final step, and the one that delivered full remote code execution,” the researchers said. “The code ran because: We tricked Conjur into fetching a host as if it were a variable. We assigned ERB as a secret and Conjur executed it, exactly as it was designed to. This vulnerability turned arbitrary host creation into arbitrary command execution. It was a seamless, start-to-finish exploit chain that went from unauthenticated access to root.”
CyberArk addressed these issues in June, issuing five distinct CVEs. However, the full technical details of the vulnerabilites are now being disclosed publicly for the first time.
First public remote code execution flaw in HashiCorp Vault
HashiCorp Vault is an open-source credentials management system, also available in an enterprise edition, that serves a similar purpose to CyberArk Conjur: storing and controlling access to secrets such as API keys, database passwords, certificates, and encryption keys used for authentication across distributed systems in multi-cloud and hybrid environments. It is commonly deployed in DevSecOps pipelines.
As with Conjur, Cyata researchers conducted manual code reviews of Vault, focusing on logic flaws in components responsible for authentication and policy enforcement, rather than memory corruption or race conditions typically detected by automated tools. This approach led to the discovery of nine vulnerabilities, including the first remote code execution (RCE) exploit in Vault’s 10-year history. Because these were deep logic issues rather than surface-level bugs, many had remained hidden in the codebase for years.
The researchers began by examining Vault’s most commonly used authentication methods: traditional username and password (userpass); LDAP, which relies on directory services like Active Directory or OpenLDAP; and TLS certificate-based authentication, often used for machine-to-machine communication.
In the userpass method, they found a flaw that allowed attackers to determine whether a username exists (username enumeration), as well as a way to bypass brute-force protections that should lock out users after multiple failed login attempts. In the LDAP method, they discovered similar lockout bypasses and a way to circumvent multi-factor authentication (MFA) enforcement.
For the Ttme-based one-time password (TOTP) MFA method, which is enabled across many deployments, they identified bugs that allowed brute-force protection bypasses, enabling attackers to attempt guessing MFA codes without triggering lockouts.
In certificate-based authentication (non-CA mode), the researchers uncovered a logic flaw where Vault verified only that the TLS client certificate’s public key matched the pinned certificate but failed to check that the certificate name (CN) matched as well. Since Vault uses the CN value to map to an internal EntityID, an attacker with access to a certificate’s private key could generate a certificate with a valid public key but a forged CN, impersonating another identity in the system.
Another vulnerability allowed privilege escalation from an admin account to root, the highest level of access in the system. By design, Vault prevents the root policy from being assigned to any user identity, including admins, to mitigate the risk of full system compromise. However, the researchers found a way to bypass this security barrier.
The most critical flaw involved leveraging Vault’s logging system to achieve arbitrary code execution through plug-ins, third-party binaries that extend Vault’s functionality. To exploit the plug-ins system, the researchers needed to write arbitrary code to a file in the plug-ins directory and set executable permissions. They achieved this by manipulating the audit component to insert malicious code into logs using a custom prefix, then writing those logs into the plug-ins’ directory.
This vulnerability, now tracked as CVE-2025-6000, is the result of multiple logic flaws and has existed since the early days of the Vault project. With this exploit, attackers could delete a critical file containing the keys needed to decrypt all stored secrets, potentially causing ransomware-like disruption, among other things.
Cyata reported the vulnerabilities to HashiCorp, which has since patched them in the latest software versions. Security bulletins detailing the issues were also released today.
“This research reinforces a critical truth — even memory-safe software can fail at the logic level — and when it does, the consequences can be just as severe,” the researchers said. “Vault is designed to be the ultimate protector of secrets and infrastructure access. But this work shows how subtle logic bugs in authentication flows, identity resolution, and policy enforcement can quietly break trust.”
No Responses