Notifications
Clear all
Topic starter
06/06/2026 2:04 am
TL;DR: Aqua’s incomplete rotation after the Trivy compromise left residual access that TeamPCP later used to expand a supply-chain cascade into LiteLLM, Mercor, and thousands of downstream targets, according to Oasis Security. The pattern shows that credential rotation without inventory, dependency mapping, and verification is not containment; it is deferred re-compromise.
NHIMG editorial — based on content published by Oasis Security: When Supply Chain Attacks Meet NHI Sprawl
By the numbers:
- LiteLLM was present in ~36% of cloud environments during the campaign.
- Within days, the campaign expanded to 47 npm packages.
Questions worth separating out
Q: What breaks when a leaked NHI credential is rotated but not fully revoked?
A: The original access path can remain usable if any downstream system still trusts the old secret, cached token, or surviving service account.
Q: Why do NHI credentials increase blast radius in supply-chain attacks?
A: Because a single token or service account often has reach across pipelines, storage, cloud roles, and developer tooling.
Q: How do security teams know if credential rotation actually worked?
A: They need proof that every consumer rejected the old credential, every dependent workflow has moved to the replacement, and no residual access path still functions.
Practitioner guidance
- Build identity-linked credential inventories Map every service account, API key, token, certificate, and CI/CD secret to an owner, consumer, and downstream dependency.
- Verify revocation across all consumers Treat rotation as incomplete until every known system rejects the old credential and replacement access is confirmed active.
- Baseline normal NHI behaviour Track where each identity usually connects from, what it normally queries, and which systems it ordinarily touches.
What's in the full article
Oasis Security's full blog covers the operational detail this post intentionally leaves for the source:
- A step-by-step breakdown of the Trivy to LiteLLM to Mercor attack chain and where residual access remained.
- The specific credential types harvested during the campaign, including cloud keys, Kubernetes tokens, database passwords, VPN configs, and TLS private keys.
- The response workflow used to validate stolen credentials and enumerate cloud environments after compromise.
- Practical examples of how identity-aware secret scanning changes incident triage and revocation decisions.
👉 Read Oasis Security's analysis of supply chain attacks and NHI sprawl →
NHI sprawl in supply chain attacks: what teams need to fix?
Explore further
06/06/2026 3:32 am
Supply-chain compromise is not the root cause when NHI access survives the response. The real breach condition is residual identity trust after the initial incident, because the attacker no longer needs the first foothold if one credential remains valid. This is where NHI governance becomes more important than the original malware or workflow flaw. The practitioner takeaway is that containment must be judged by identity invalidation, not by the number of systems patched.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which helps explain why rotation and revocation often miss surviving access paths.
A question worth separating out:
Q: Who is accountable when a supply-chain breach persists because an NHI credential survived rotation?
A: Accountability sits with the teams that own the credential lifecycle, the systems that consume it, and the incident response process that declared containment too early. Frameworks such as NIST CSF and NHI governance programmes expect identity, access, and recovery responsibilities to be defined before an incident, not improvised during one.
👉 Read our full editorial: Supply chain attacks expose the real blast radius of NHI sprawl
