Shai-Hulud, ransomware and offboarding failures expose lateral risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on ColorTokens's blog post: Several September 2025 incidents follow one pattern: lateral risk grows fast when secrets, third-party access and offboarding controls fail.

Why it matters: For IAM, PAM and NHI teams, the article is a reminder that identity lifecycle failures and exposed secrets turn isolated incidents into broader compromise paths.

Context

This article is about a governance gap that sits between identity control, containment and third-party risk. The common failure is not initial compromise alone, but the absence of boundaries that prevent stolen secrets, stale accounts or trusted integrations from turning a single incident into a wider breach. In practice, that makes identity lifecycle discipline and blast-radius reduction inseparable.

The article spans machine identities, human offboarding and supplier exposure, so the identity angle is genuine rather than incidental. That matters because the same failure mode appears in different forms: a compromised npm maintainer, an ex-employee with retained access, and exposed API tokens after a third-party breach all show how access that outlives its intended scope becomes the attacker’s multiplier.

Key questions

Q: What breaks when offboarding is not tightly linked to access control?

A: Access can outlive the employment or role change that justified it, which creates privilege creep and audit gaps. The failure is not only technical. It also undermines accountability, because the organisation can no longer prove that access was removed when the business relationship changed.

Q: Why do exposed secrets create such high operational and supply chain risk?

A: Exposed secrets can unlock production data, production workflows, and third party systems downstream in the software supply chain. Once a credential, token, or key is found, an attacker may move quickly from discovery to access. That is why teams should treat secret leakage as an access problem, not just a code quality issue.

Q: How do security teams know whether containment is actually working?

A: They should test whether the identity can still execute privileged actions after revocation, not just whether the API call succeeded. A working containment model prevents re-escalation, blocks credential regeneration, and remains effective even when the target is polling for state changes. If any of those fail, containment is only partial.

Q: What is the difference between secret leakage and offboarding failure in lateral risk?

A: Secret leakage is the exposure of credentials or tokens that can be reused immediately, while offboarding failure is the persistence of valid access after a person should no longer have it. Both create lateral risk, but they fail in different places. Leakage is about credentials escaping control, while offboarding failure is about identity lifecycle controls not ending reach.

Technical breakdown

How worm-style supply chain compromise turns secrets into propagation fuel

A worm-style supply chain attack becomes especially dangerous when it can harvest secrets from cloud metadata endpoints, local environments and CI/CD contexts, then reuse them to move into package publishing and workflow automation. In the npm case, malicious code did not merely exfiltrate data. It converted stolen secrets into propagation, creating new repositories, modifying package versions and planting workflows that expanded the compromise surface. This is a machine-identity and secrets-governance problem as much as a software supply chain one, because the credentials give the worm authority to act at scale.

Practical implication: Treat package publishing tokens, workflow secrets and metadata credentials as propagation assets, not just authentication material.

Why offboarding failures create delayed insider risk

Offboarding is often treated as an HR completion step, but security impact depends on whether every credential, session and entitlement is actually revoked. The FinWise case shows the risk of retained access after employment ends, where an account that should have been dead remained capable of reaching sensitive data months later. This is a classic lifecycle-control failure: manual disablement, incomplete inventory and weak audit follow-through allow old identities to stay operational long after the business assumes they are gone. The breach was not surprising because the control gap was structural, not exceptional.

Practical implication: Build termination-triggered deprovisioning and verify that no privileged, remote or cloud access survives the exit event.

How third-party compromise widens the blast radius through trusted integrations

When support platforms or vendor-linked services are compromised, the attacker often inherits trust rather than forcing a direct break-in. That is why token exposure in a third-party breach can matter even when passwords are safe and funds remain untouched. API tokens, support case data and configuration details can be enough to drive later phishing, credential stuffing or account takeovers. This is where identity governance intersects with supply chain security: delegated access, vendor-issued tokens and shared case systems need the same scrutiny as internal credentials, because they often sit outside the strongest controls while retaining meaningful privileges.

Practical implication: Inventory third-party tokens and delegated access paths, then revoke or segment them as aggressively as internal credentials.

Threat narrative

Attacker objective: The attacker aims to turn one foothold into repeated access, wider distribution and larger downstream exposure than the initial compromise would allow.

1. Entry occurs through compromised npm maintainer environments, a misconfigured cloud bucket, or retained post-employment access, depending on the incident pattern described.
2. Credential access follows when attackers steal secrets from metadata services, local environments, API tokens or unattended user accounts.
3. Escalation and lateral movement happen when stolen credentials are reused to publish malicious packages, reach downstream clinics, or access sensitive customer data through trusted integrations.
4. Impact is broad data theft, poisoned software distribution and expanded blast radius across multiple organisations.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• CanisterSprawl npm worm 2026: The CanisterSprawl worm stole npm and PyPI publish tokens from installs of pgserve and Namastex packages and republished victims' packages.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Blast-radius control is now a core identity problem, not only a network problem: the incidents described here all become worse after the first foothold because access is still usable across systems, workflows or third parties. That shifts the centre of gravity from simple prevention to containment by design. Practitioners should treat segmentation, token scope and lifecycle enforcement as a single governance plane.

Offboarding failure is a lifecycle governance issue with incident-level consequences: a former employee retaining access is not merely a process miss, it is an unexpired identity boundary. The FinWise case shows that the control failure is persistence, not detection. For identity teams, the practical lesson is to measure whether termination actually ends reach, especially across VPN, cloud and SaaS estates.

Secret leakage becomes materially more dangerous when it is connected to automation: the npm worm shows how one exposed credential can trigger repository creation, package modification and workflow abuse without additional human effort. That makes NHI governance central to software resilience. Security teams need to assume that stolen machine credentials can behave like propagation keys, not isolated secrets.

Third-party access creates a verification gap that conventional trust models still understate: support integrations and vendor-issued tokens often sit outside the most mature controls while preserving enough privilege to leak data or enable follow-on compromise. This is the same governance weakness seen in many supply chain incidents. The named concept here is delegated trust residue: access that remains useful after the relationship or incident that justified it has changed. Practitioners should reduce that residue before it becomes an attacker pathway.

Microsegmentation remains relevant because it changes attacker economics after compromise: the article's incidents show that damage expands when one system can freely touch many others. Containment is therefore not an abstract architecture choice but a response to real propagation behaviour across cloud, SaaS and package ecosystems. Security leaders should align identity controls and segmentation around reducing reachable trust, not just blocking initial entry.

From our research library:

• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Delegated trust residue: once a token, workflow secret or third-party account remains valid beyond its intended use, it becomes a lateral movement asset rather than a convenience feature. Security teams should watch for any environment where trust survives longer than the business relationship or task that created it.

The practical test is whether a single compromised maintainer, supplier or employee can still reach build systems, support portals or customer data after the first control boundary should have closed. If the answer is yes, the programme has a containment problem, not just an exposure problem.

For practitioners

• Tighten CI/CD and package-publishing secrets Move build and publish credentials out of long-lived environment variables, restrict their scope to the smallest usable action and rotate them after any build-system compromise. Pay special attention to maintainer tokens, GitHub workflow secrets and cloud metadata access paths.
• Automate offboarding across every access path Trigger deprovisioning from the authoritative HR event and verify revocation across VPN, email, cloud consoles, SaaS apps and privileged access tools. Do not rely on manual tickets to confirm that a former employee can no longer reach sensitive data.
• Reassess third-party token exposure Catalogue support tokens, vendor integrations and delegated access paths, then define revocation criteria for each one. Where a supplier breach can expose customer data, treat the token as a live liability until it is rotated or removed.
• Contain package and SaaS trust blast radius Segment build systems, package registries and support portals so that compromise in one zone does not automatically grant lateral movement into others. Pair that with least-privilege access rules for humans, services and maintainer workflows.
• Test for lingering access after exit events Run periodic checks that compare terminated identities against active cloud roles, remote access sessions and privileged entitlements. Any surviving access should be treated as a control failure, not an edge case.

Key takeaways

• The incidents in this article show that lateral risk grows when secrets, tokens and stale identities remain usable after the original trust boundary has changed.
• A compromised maintainer, a breached supplier and a former employee can each become a larger problem when automation and delegated access are not tightly scoped.
• Practitioners should treat identity lifecycle enforcement and containment design as linked controls, because either one can fail to stop blast-radius expansion.

Key terms

• Delegated Trust Residue: Access, tokens or integrations that remain useful after the business relationship or task that justified them has changed. In practice, it describes leftover trust that attackers can exploit after offboarding, supplier compromise or a workflow change.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Supply Chain Propagation: Supply chain propagation is the spread of malicious code or trust abuse from one compromised package, account, or dependency into multiple downstream systems. The key risk is that trusted distribution mechanisms amplify impact faster than traditional endpoint or perimeter controls can respond.
• Offboarding Success Rate: Offboarding success rate is the share of leaver workflows that complete as intended, with access removed across the relevant applications and accounts. It is a governance outcome metric, not a task completion metric. High values indicate that revocation, deprovisioning, and downstream account closure are happening reliably in practice.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners strengthen identity controls across cloud, automation and third-party access paths.