Notifications
Clear all
Topic starter
25/06/2026 12:49 am
TL;DR: Shai-Hulud and the Nx S1ngularity attacks showed how token theft, vulnerable GitHub Actions workflows, and always-on elevated permissions can combine into cascading compromise across repositories and organisations, according to Apono. The deeper issue is that access review and least-privilege controls fail when elevated access is inherited, static, and available long enough to be abused.
NHIMG editorial — based on content published by Apono covering the Shai-Hulud worm and Nx S1ngularity attacks: Shai-Hulud worm and the Nx / S1ngularity attacks: How-to use JIT Access to Stop the Chain Reaction
By the numbers:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations.
Questions worth separating out
Q: What breaks when GitHub admin and publish permissions are left standing in CI/CD environments?
A: Standing admin and publish permissions let one compromised token alter repositories, create workflows, and expose secrets at scale.
Q: Why do inherited team permissions increase supply chain compromise risk?
A: Inherited team permissions turn one compromised member into access to many repositories and actions, which makes the blast radius larger than any individual grant suggests.
Q: How do security teams know whether JIT access is working in GitHub governance?
A: JIT access is working when elevated permissions are rare, time-boxed, and consistently logged, with automatic removal after the task ends.
Practitioner guidance
- Make repository admin and publish rights requestable Require explicit justification, approval, and automatic expiry before anyone can modify repositories, create workflows, or publish packages.
- Separate workflow execution from secret access Prevent GitHub Actions and similar automation from inheriting broad secret access by default.
- Audit inherited team rights as privileged access Review team membership, owner assignment, and inherited admin rights on a fixed schedule and whenever membership changes.
What's in the full article
Apono's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for applying JIT access to repository, organisation owner, and admin roles in GitHub.
- Specific policy patterns for temporary team assignments, dual approval, and expiry handling in elevated access workflows.
- A practical breakdown of which GitHub permissions should be requestable versus permanently assigned in developer environments.
- Implementation framing for monitoring workflow changes, postinstall scripts, and privileged repository actions.
👉 Read Apono's analysis of Shai-Hulud, Nx, and GitHub standing privilege →
GitHub standing privilege risk: what Shai-Hulud changed for IAM teams?
Explore further
25/06/2026 9:50 am
Standing privilege in developer identity is the real failure mode here: these attacks work because repository, workflow, and org-admin access are left available long enough to be stolen and reused. The problem is not simply that secrets exist, but that elevated permissions remain active across maintenance, publishing, and automation tasks. Practitioners should recognise that a single exposed token can behave like organisational reach when it inherits broad rights.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- GitGuardian also found that AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
A question worth separating out:
Q: Who is accountable when a compromised workflow publishes secrets or malicious changes?
A: Accountability sits with the teams that own repository policy, workflow controls, and privileged access governance, not just the developer whose token was stolen. Organisations should map owner, admin, and automation rights to named control owners so incident response can trace both the compromise path and the permission decisions that enabled it.
👉 Read our full editorial: Shai-Hulud and Nx attacks expose standing privilege risk in GitHub
