Conjur’s logic flaws show how secrets vault trust can collapse

At a glance

What this is: Cyata found a logic-based pre-authentication exploit chain in CyberArk Conjur that could end in remote code execution through default AWS integration paths.

Why it matters: This matters because secrets vaults sit inside the access path for machine identities, so a single trust failure can turn into enterprise-wide credential and control-plane compromise.

👉 Read CYATA's analysis of the Conjur authentication bypass and RCE chain

Context

Conjur is a secrets management platform for machine and application identities, so its trust decisions sit on a critical path. When an attacker can bypass authentication, abuse resource creation, and reach code execution through default behaviour, the issue is not just a product bug but a breakdown in how NHI governance is being enforced.

The primary identity-security problem here is that Conjur was trusted to validate AWS-backed identity and mediate secrets access, yet attacker-controlled inputs were allowed to influence that trust flow. For teams running CI/CD, Kubernetes, and cloud automation, this is a reminder that secrets vault compromise can become the pivot point for wider workload identity abuse.

Key questions

Q: What breaks when a secrets vault trusts request data for identity verification?

A: When a secrets vault lets request data influence how identity is verified, an attacker can redirect trust to an endpoint they control or shape the identity assertion itself. The result is not just auth bypass, but collapse of the platform’s trust boundary. Teams should assume any caller-controlled verification parameter is part of the attack surface.

Q: Why do machine identities make secrets vault compromise so dangerous?

A: Machine identities often sit inside automation, CI/CD, and cloud control paths, so a compromise can affect many systems at once. If the vault also stores tokens or policy that governs those systems, the attacker gains both secrets and authority. That combination turns one weakness into a broad operational and security incident.

Q: What do security teams get wrong about default secrets-management configurations?

A: They often assume default integrations are safe until customised. In practice, defaults are the most common place for hidden trust assumptions, weak validation, and overbroad compatibility logic. Teams should test the out-of-box paths as aggressively as the custom ones, because attackers usually start where defenders are least likely to have changed anything.

Q: How should organisations respond when a secrets platform can execute policy as code?

A: They should treat policy execution as a privileged runtime surface, not just configuration. The safest pattern is to isolate policy evaluation from executable payloads, constrain template engines, and ensure that no secret or metadata path can be reinterpreted as code. If code execution is possible, the platform needs stricter compartmentalisation.

Technical breakdown

AWS IAM authentication bypass through header-controlled region parsing

Conjur’s AWS authentication flow depends on validating a signed request against AWS STS. The flaw described in the article came from extracting the STS region from attacker-controlled headers without sufficient validation, then constructing the verification endpoint from that value. That let an attacker redirect trust to a domain they controlled and return a forged but well-formed GetCallerIdentity response. The important point is not the specific syntax trick, but the architectural mistake: verification logic trusted request content that should have been treated as untrusted input.

Practical implication: validate every external identity assertion against fixed trust anchors, not user-supplied routing data.

Host Factory abuse and arbitrary resource creation

Conjur’s internal resource model uses account, kind, and identifier values to locate and control objects. The article shows that the Host Factory flow accepted execute permission on the wrong resource kind, allowing a group or layer to be treated like a host factory token source. That kind mismatch turns permission semantics into an attack primitive. Once an attacker can mint a host with a controlled identifier, later authorization and templating steps can be steered into attacker-chosen paths.

Practical implication: enforce resource-kind validation at every authorization boundary, not only at the user interface.

Policy template execution can become code execution

The final stage came from policy templating that rendered ERB dynamically when a policy factory applied a template. Because the earlier flaws let the attacker create a host with a crafted resource path, Conjur later resolved that object as if it were a template and executed the embedded Ruby payload. This is a classic example of secrets infrastructure crossing the line from configuration management into runtime code execution. In identity terms, the problem is that metadata, policy lookup, and executable content were not cleanly separated.

Practical implication: separate secret storage, policy metadata, and executable template processing so one cannot impersonate the other.

Threat narrative

Attacker objective: The attacker’s objective is to move from unauthenticated access to full control of the secrets platform, then use that control to tamper with identities, secrets, and downstream infrastructure.

1. Entry occurred through a pre-authentication AWS IAM bypass that redirected Conjur’s STS verification to an attacker-controlled endpoint.
2. Escalation followed when the attacker abused host factory logic to mint arbitrary resources and shape the authorization path.
3. Impact came when policy templating resolved crafted content as executable ERB, resulting in remote code execution and full control of the Conjur deployment.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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 vault trust is only as strong as the validation logic behind identity binding. This incident shows that a vault can look operationally sound while still accepting attacker-controlled identity assertions at the authentication layer. If the system derives trust from unvalidated request content, the vault becomes a policy interpreter for the attacker rather than a control point for the defender. Practitioners should treat identity binding as a hard security boundary, not an implementation detail.

Resource-kind confusion is a governance failure, not just a coding bug. Conjur’s flow allowed permissions on one object type to masquerade as permissions on another, which breaks the premise that authorization decisions are scoped to a stable identity class. That assumption matters in NHI environments because service accounts, groups, hosts, and templates often coexist in the same control plane. The practical consequence is that role, resource, and execution boundaries must be enforced independently.

Secrets platforms can become execution platforms when policy and payload are not separated. The RCE chain depended on policy machinery rendering content that could be shaped into executable code. That is exactly the kind of hidden coupling that creates identity blast radius in automation-heavy environments. The implication is broader than Conjur: any system that stores secrets, evaluates policy, and executes templates in the same trust domain needs stricter compartmentalisation.

Default configurations are not neutral in NHI governance. The article’s chain used standard requests and default integration behaviour, which means the risk is not confined to unusual deployments. In machine identity systems, default trust paths often become the most attractive attack surface because they are widely enabled and lightly reviewed. Practitioners should assume that baseline configuration is part of the attack model, not the safe starting point.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• A separate finding from the same research shows that 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits.
• For a broader view of how identity failures compound across machine and autonomous systems, see the 52 NHI Breaches Analysis.

What this signals

Ephemeral credential trust debt: vaults that depend on caller-supplied routing or object-kind inference accumulate hidden trust assumptions faster than teams can review them. In practice, that means the control plane becomes harder to reason about just as automation density increases, which is exactly when identity governance needs to be simplest.

With 44% of NHI tokens exposed in the wild, the operational lesson is clear: secrets exposure and trust-boundary confusion often coexist rather than arrive separately. Teams should expect attackers to chain exposed credentials, default integrations, and validation flaws into one compromise path.

This is also a reminder to align vault governance with broader identity controls such as least privilege, lifecycle management, and policy separation. If a secrets platform can be tricked into acting as a verifier, a resource factory, and an execution engine, the programme has an identity architecture problem, not just a hardening problem.

For practitioners

• Audit trust-anchor selection in all NHI authentication flows Review any workflow where the platform chooses a verification endpoint, region, issuer, or account from request data. Replace caller-controlled routing with fixed allowlists and explicit validation of every identity assertion before it reaches STS, OIDC, or token exchange logic.
• Verify resource-kind checks at every permission boundary Test whether token issuance, ownership checks, and resource lookup logic can be confused by passing a valid identifier of the wrong kind. Block cross-kind reuse so a group cannot behave like a host factory, and a host cannot be treated as a template container.
• Separate executable templates from secret records Ensure secrets, policy metadata, and template rendering paths are isolated so stored content cannot be reinterpreted as code. If a policy engine can render ERB, Jinja, or similar logic, constrain the renderer and remove any path where secret content can influence execution.
• Treat default integrations as high-risk attack paths Inventory every default AWS, Kubernetes, and CI/CD integration that the vault accepts without extra hardening. Prioritise external review of those flows, because attackers routinely target the paths that appear easiest to trust and hardest to notice.

Key takeaways

• This research shows that a secrets vault can be taken from unauthenticated access to remote code execution when identity validation, resource typing, and policy execution are weakly separated.
• The scale of the risk is operational, not theoretical, because the exploit chain uses standard requests and default behaviour rather than obscure memory corruption.
• Teams should harden trust anchoring, validate resource kinds, and isolate policy rendering from executable content before a vault becomes a control-plane pivot.

Key terms

• Secrets Vault: A secrets vault is a system that stores and brokers credentials such as tokens, API keys, and certificates. In NHI programmes it is part of the trust boundary, so its validation, authorization, and retrieval logic can directly affect workload identity and downstream access control.
• Trust Boundary: A trust boundary is the point where one system decides whether to accept data, identity, or requests from another. In this article, the boundary matters because request data was able to influence verification and resource handling, which turns a control point into an attack surface.
• Resource Kind Confusion: Resource kind confusion happens when a system accepts one object type as if it were another, such as treating a group like a host factory. That breaks authorization assumptions and can let attackers reuse permissions in ways the platform was never meant to allow.
• Policy Templating: Policy templating is the process of generating or applying access policy from reusable templates. It becomes risky when template rendering can process executable content, because identity metadata can then cross into code execution rather than remaining a declarative control.

What's in the full article

CYATA's full post covers the exploit mechanics this analysis intentionally leaves at a governance level:

• Header parsing details behind the AWS IAM authentication bypass and the exact request-shaping behaviour
• Step-by-step reproduction of the Host Factory kind mismatch and arbitrary host creation path
• The policy-template abuse sequence that turns crafted identity objects into code execution
• Disclosure timeline and vendor remediation notes for the affected Conjur behaviour

👉 The full CYATA post walks through the exploit stages, proof-of-concept logic, and remediation context.

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 or secrets governance programme, it is worth exploring.