May security beat: keys, access control and supply chain abuse

At a glance

What this is: Quantstamp's May 2026 security beat shows crypto losses concentrated in access control, bridge validation and key compromise, while an npm worm expanded across the broader software supply chain.

Why it matters: For IAM, PAM and NHI practitioners, the month illustrates how standing trust in keys, tokens and publish pipelines becomes a systemic attack path when lifecycle controls are weak.

By the numbers:

• $59.52M was lost across 29 crypto incidents in May 2026.
• The category of access control losses accounted for about $20.6M across 9 incidents.
• Mini Shai-Hulud ultimately spread across more than 1,000 malicious package versions.

👉 Read Quantstamp's May 2026 Security Beat on crypto losses and npm supply chain abuse

Context

Crypto and software supply chain incidents keep exposing the same governance gap: organisations trust credentials, publish paths and cross-system messages for longer than the controls justify. In this month’s beat, Quantstamp shows that the issue was not a single novel exploit but repeated abuse of access control, private keys and validation logic. That pattern matters well beyond Web3 because the same failure modes apply to IAM, PAM and non-human identity lifecycle controls.

Mini Shai-Hulud also shows how a supply chain compromise becomes an identity problem the moment it steals developer and CI/CD credentials. Once an attacker can reuse GitHub, npm, cloud and Vault material, the worm can propagate itself as a trusted actor rather than a noisy intruder. That is a familiar failure mode in enterprise NHI programmes: the environment is treated as authenticated because the workload or pipeline is authenticated, even when the credential has already been abused.

Key questions

Q: What breaks when build pipelines are treated as trusted identities?

A: When build pipelines are treated as trusted identities, attackers can use them to mint, reuse and distribute credentials faster than normal review processes can react. The result is recursive compromise: the pipeline becomes both the victim and the propagation mechanism. Governance has to cover token scope, token lifetime and revocation across the entire release path.

Q: Why do standing owner roles increase risk in smart contract operations?

A: Standing owner roles increase risk because they preserve privileged paths long after the original operational need has passed. If an attacker obtains that role, or if the role is too broad, they can invoke trusted functions without needing to exploit the code itself. That is why privileged access must be time-bound and auditable.

Q: How do security teams know if secret rotation is actually working?

A: Secret rotation is working only when teams can prove that each credential has an owner, an expiry path, and a tested revocation process. If rotation causes outages, leaves unknown dependencies behind, or cannot be completed quickly after exposure, the control is not operationally mature. Effective rotation reduces usable lifetime without breaking legitimate workloads.

Q: Who is accountable when a supply chain compromise spreads through trusted credentials?

A: Accountability usually spans release engineering, platform security, and identity governance because the incident crosses multiple trust domains. The practical question is which team owns credential scope, publish rights, and offboarding for automation identities. Frameworks such as NIST CSF and NHI governance models help assign control ownership where a single compromise can affect many systems.

Technical breakdown

Cross-chain message validation failures

Cross-chain bridges depend on message authenticity, replay resistance and state consistency between separate ledgers. If a bridge accepts an import payload without validating the source state, an attacker can forge a transfer that appears legitimate to the destination chain. In practice, the bridge becomes a trust translator, so one weak validation step can move value across systems faster than defenders can intervene. This is a protocol-integrity problem first and a fraud problem second.

Practical implication: validate bridge messages against authoritative state and treat message acceptance as a high-risk control point.

Access control collapse in contract ownership

Smart contracts often encode privileged functions behind owner roles, admin keys or upgrade authorities. If those privileges are exposed, misrouted or recoverable through weak operational controls, the attacker does not need to break the code. They simply invoke the same privileged paths the system already trusts. That is why ownership and admin lifecycle management are security controls, not just deployment details. In identity terms, this is standing privilege applied to software assets.

Practical implication: reduce standing admin paths and require explicit lifecycle controls for every privileged contract role.

Supply chain worms that steal and reuse identities

A self-propagating npm worm uses installation time execution to harvest developer, CI/CD and cloud credentials, then republishes itself with valid provenance into more packages. The dangerous part is not only malware execution, but the conversion of trusted publishing into an identity theft loop. Short-lived tokens, OIDC federation and package provenance all matter, but they fail if the compromised runtime can still mint or reuse trusted credentials before detection. The threat is recursive trust abuse.

Practical implication: isolate build identities, limit token scope and assume any compromised pipeline can republish into the ecosystem.

Threat narrative

Attacker objective: The attacker objective was to turn trusted development and release infrastructure into a self-amplifying distribution channel for credential theft and downstream compromise.

1. Entry began with malicious package installation and supply chain exposure through npm dependencies that executed at install time.
2. Credential access followed when the worm stole GitHub, npm, OIDC, AWS, Kubernetes, Vault and SSH material from developer and CI environments.
3. Escalation occurred as stolen identities were reused to republish the worm into additional packages and expand its reach across the ecosystem.
4. Impact was broad propagation of malicious versions and increased risk to downstream developers, pipelines and secret-bearing hosts.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing trust is the month’s defining failure mode. May’s incidents did not rely on one exotic exploit path. They repeatedly succeeded because systems continued to trust keys, owner roles and validated-looking messages after the underlying identity had already become unsafe. For practitioners, the lesson is that lifecycle control, not just authentication strength, determines whether trust remains valid.

Mini Shai-Hulud is a recursive identity abuse pattern, not just a malware story. The worm converts developer and CI/CD identities into propagation machinery, which is exactly why NHI governance and secrets hygiene belong in the same control conversation. OWASP Non-Human Identity Top 10 concerns around credential sprawl and lifecycle abuse apply directly here. The practitioner conclusion is simple: build and release identities need shorter-lived trust than the software they move.

Cross-chain validation and admin ownership are governance controls, not only engineering details. Bridge verification failures and ownership override attacks show what happens when privileged paths are left too broad or too durable. This is the same control logic that underpins least privilege, separation of duties and privileged access management in enterprise identity programmes. The practitioner conclusion is to treat every privileged automation path as an identity with scope, expiry and revocation.

Machine identity risk now spans code, infrastructure and distribution. The same month that crypto incidents exposed key and access control failures, an npm worm showed how machine identities can be weaponised across the software supply chain. That creates a named concept worth tracking: recursive trust abuse, where stolen identities are used to create more trusted identities. Practitioners should assume the next compromise may arrive through a trusted runtime, not a direct intrusion.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to 2024 ESG Report: Managing Non-Human Identities.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, and a quarter encountered multiple attacks, according to the same report.
• The related control question is no longer whether machine identities can be governed, but whether teams can inventory and offboard them before trust is abused, as discussed in NHI Lifecycle Management Guide.

What this signals

May’s pattern suggests that security teams should stop treating secrets and release credentials as isolated operational assets. Once a credential can authenticate a build, a package publish or an owner action, it behaves like a non-human identity with lifecycle, scope and revocation requirements. That makes the control problem closer to identity governance than to simple secret storage.

Recursive trust abuse: this month’s supply chain worm shows how a compromised runtime can turn trusted publishing into a propagation loop. The programme impact is clear: teams need stronger separation between build identity, release identity and downstream consumer trust, supported by controls such as the OWASP Non-Human Identity Top 10 and lifecycle discipline from the NHI Lifecycle Management Guide.

For crypto and software supply chain owners, the practical signal is that private keys, owner roles and CI tokens now deserve the same monitoring mindset as high-value human privileged accounts. If a credential can move value, publish code or alter state, it needs expiry, revocation and alerting pathways that are tested before an incident forces the issue.

For practitioners

• Audit standing privilege in release and admin paths Identify every owner role, deploy key and signing credential that can still push code, move funds or change contract state without a fresh approval step. Prioritise paths where the same identity can both mint trust and exercise it. A privilege that can persist across releases is a standing risk, not an operational convenience.
• Treat build pipelines as NHI estates Inventory GitHub tokens, npm tokens, OIDC federation, cloud access keys, Vault tokens and SSH material used by CI/CD. Apply rotation, scoping and revocation to the pipeline itself, not only to the application it produces. If a build host is compromised, rotate every credential reachable from that host.
• Verify bridge messages against authoritative state Require destination-side validation that checks source chain state, replay conditions and expected token flows before any value transfer is accepted. Do not rely on a single proof or import payload as sufficient evidence of legitimacy. Cross-chain acceptance is a trust decision that needs layered validation.
• Pin package versions and inspect provenance manually Block automatic dependency drift in environments that can execute install-time scripts or fetch transitive packages from public registries. Review package updates by hand when they touch build systems, wallet tooling or secret-bearing workloads. Provenance is useful only when the consuming environment is prepared to reject poisoned trust.

Key takeaways

• May’s losses came from recurring trust failures, not a single unusual exploit class.
• The most dangerous pattern was credential reuse across developers, CI/CD pipelines and package publishing systems.
• Teams should govern build and release identities with the same lifecycle discipline they apply to privileged human access.

Key terms

• Cross-Chain Message Validation: The process a bridge uses to prove that a message from one blockchain is authentic and should be accepted on another. It must verify source state, ordering and replay protection, or attackers can forge transfers that look legitimate to the destination chain.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Recursive Trust Abuse: A failure pattern where a stolen identity is used to create more trusted identities or actions, causing compromise to spread through legitimate systems. In supply chains, this can mean a compromised build or publish path repeatedly issuing new valid artefacts.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.

What's in the full report

Quantstamp's full May security beat covers the incident-by-incident operational detail this post intentionally leaves for the source:

• Per-incident loss breakdowns for each bridge, access control and key compromise case, useful when validating your own exposure model.
• Technical descriptions of the Verus-Ethereum, THORChain and DxSale failure modes, including how each exploit path unfolded.
• The Mini Shai-Hulud propagation timeline across npm packages and release waves, which helps teams map dependency risk to their own build pipelines.
• Source-linked references to DeFiLlama, TRM Labs, Aikido and Socket for practitioners who need to verify the underlying reporting.

👉 Quantstamp's full May security beat adds incident detail, chain-by-chain loss context and the Mini Shai-Hulud propagation timeline.

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 security and identity practitioners translate lifecycle control into practical programme decisions.