Notifications
Clear all
Topic starter
09/07/2026 3:28 pm
TL;DR: A pre-authentication RCE chain built from logic flaws in AWS IAM authentication, host factory handling, and policy templating was found in CyberArk Conjur, letting an attacker move from zero access to full control using default behaviour and standard requests, according to CYATA research.
NHIMG editorial — based on content published by CYATA: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
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.
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.
Q: What do security teams get wrong about default secrets-management configurations?
A: They often assume default integrations are safe until customised.
Practitioner guidance
- 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.
- 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.
- Separate executable templates from secret records Ensure secrets, policy metadata, and template rendering paths are isolated so stored content cannot be reinterpreted as code.
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
👉 Read CYATA's analysis of the Conjur authentication bypass and RCE chain →
Conjur authentication bypass and RCE: what IAM teams missed?
Explore further
09/07/2026 3:49 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Conjur’s logic flaws show how secrets vault trust can collapse
