Shai-Hulud and Nx attacks expose standing privilege risk in GitHub

At a glance

What this is: This article argues that JIT access can limit the blast radius of GitHub repository, owner, admin, and inherited team privileges exposed by Shai-Hulud and Nx-style attacks.

Why it matters: It matters because CI/CD and developer identities often carry organisation-wide reach, so standing elevation can turn one compromised token into widespread repo and workflow abuse.

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.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Apono's analysis of Shai-Hulud, Nx, and GitHub standing privilege

Context

Shai-Hulud and the Nx S1ngularity attacks are best understood as identity problems inside software delivery, not just malware events. Once a token, workflow, or admin role is exposed, the attacker is no longer limited to one system, because GitHub permissions, package publishing, and inherited team access can move compromise across repositories and organisations.

The governance gap is standing privilege in developer and CI/CD environments. JIT access matters here because elevated permissions are often broader than the task being performed, live too long, and remain available to automation after the original human action is complete. That is exactly the access pattern these attacks exploit.

Key questions

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. The failure is not just credential theft, but the fact that the stolen identity already carries the authority needed to expand the breach before anyone notices. Short-lived elevation sharply reduces that blast radius.

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. That is why team-based elevation should be treated as privileged access, with expiry, logging, and membership review, not as routine collaboration.

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. If repo admin, publishing, or workflow-modifying rights still exist by default, or if temporary grants are never reviewed, the programme is still relying on standing privilege.

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.

Technical breakdown

Token theft turns package maintenance into an access pathway

Shai-Hulud used postinstall code and compromised maintainer accounts to steal cloud and source-control tokens. Nx S1ngularity abused vulnerable GitHub Actions workflows to extract secrets and developer credentials. In both cases, the attacker did not need a new login flow. Existing trust relationships between packages, workflows, and developer identities were enough to move from one compromised foothold to broader access. Practical implication: remove persistent trust from package execution paths and treat workflow-triggered secret access as an elevated event, not a default state.

Practical implication: require explicit approval and short-lived scope before workflows can access sensitive repositories or secrets.

Always-on elevated roles magnify one compromise into many actions

Owner, admin, and broad write permissions create a multiplier effect once an identity is compromised. Those roles can publish new versions, create workflows, alter repository visibility, and exfiltrate secrets without further privilege checks. The issue is not only technical exposure, but permission shape: one standing role can govern many assets at once. Practical implication: separate routine development from privileged repository administration and force elevation to be temporary and task-scoped.

Practical implication: keep org owner and admin access off the steady state path and make it requestable only for named tasks.

Inherited team permissions spread compromise beyond a single identity

When teams inherit admin or write rights, access is no longer tied to one accountable actor. A single compromised member can inherit the team's broader reach, which makes blast radius larger and reviews less meaningful if membership changes are not tightly controlled. This is why inherited access behaves like hidden standing privilege. Practical implication: audit team-based elevation separately from individual grants and treat inherited write or admin rights as high-risk entitlements requiring expiry.

Practical implication: time-box team elevation and review membership changes as privileged events, not routine administration.

Threat narrative

Attacker objective: The objective is to convert one compromised developer or workflow identity into repeatable access for secret theft, repository control, and supply-chain propagation.

1. Entry occurs when attackers gain initial foothold through compromised npm packages, stolen developer tokens, or vulnerable GitHub Actions workflows that expose secrets.
2. Escalation follows when those tokens provide access to owner, admin, or broad write permissions that let attackers publish changes, create workflows, and exfiltrate additional credentials.
3. Impact is cascading compromise across repositories and organisations, including secret exposure, repo manipulation, and wider supply-chain propagation through trusted package maintenance paths.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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 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.

Inherited access is a hidden blast-radius multiplier: team-based permissions, owner roles, and CI/CD automation create privilege that outlives the person or action that requested it. That assumption was designed for stable, human-paced administration. It fails when compromise arrives through machine-triggered workflows and package scripts that can act faster than reviews can respond. The implication is that privilege shape, not just privilege volume, must be rethought.

JIT access is the correct control pattern because it converts permanent authority into conditional authority: in GitHub-centric environments, that means repository admin, publishing, and workflow-modifying rights should exist only for the task window that requires them. This is a classic OWASP-NHI problem of access duration and scope, and it maps cleanly to zero standing privilege. Practitioners should stop treating elevated developer access as a convenience and start treating it as a high-risk event.

Workflow abuse and token theft demonstrate that CI/CD identity is part of the attack surface: build systems are no longer just automation tooling, they are privileged actors with access to secrets, registries, and release channels. That changes governance from periodic review to runtime control, logging, and expiry enforcement. The practical conclusion is that GitHub Actions, package scripts, and inherited permissions need identity controls that match their privilege level.

Access review alone is insufficient when abuse happens inside short-lived operational windows: the control gap is not lack of review intent, it is that the privileged state can be created, used, and abused before a recertification cycle ever sees it. NIST CSF and OWASP NHI both point toward stronger protection and continuous governance. Practitioners should move from static permission inventories to enforced temporal constraints and event-based elevation.

From our research:

• 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.
• For a broader breach lens on credential exposure and propagation, see 52 NHI Breaches Analysis for the recurring control failures behind secret-driven compromise.

What this signals

Identity blast radius is becoming the deciding metric in developer security: when package maintainers, workflows, and team inheritance can all activate the same broad permissions, the question is no longer whether a secret leaks but how far that secret can move before expiry. Teams should measure privileged access by task scope and duration, not by who can technically log in.

The practical signal for programmes is whether elevation has become an exception that leaves an auditable trace. If owner roles, admin rights, and workflow-modifying access remain routine, then the environment is still organised around convenience rather than containment. That is where JIT access, approval logging, and expiring grants become operational controls rather than policy language.

With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, the governance problem is clearly bigger than any one incident. Practitioners should expect more supply-chain abuse of developer identities and should align GitHub controls with OWASP Non-Human Identity Top 10 guidance on secret exposure and privilege scope.

For practitioners

• Make repository admin and publish rights requestable Require explicit justification, approval, and automatic expiry before anyone can modify repositories, create workflows, or publish packages. Keep the standing state read-only wherever possible so compromised tokens have nothing persistent to abuse.
• Separate workflow execution from secret access Prevent GitHub Actions and similar automation from inheriting broad secret access by default. Use narrow scopes, isolated service identities, and short-lived credentials for release tasks so workflow compromise does not expose the full environment.
• Audit inherited team rights as privileged access Review team membership, owner assignment, and inherited admin rights on a fixed schedule and whenever membership changes. Treat changes to team-based elevation as security events and require logging, alerts, and expiry for temporary assignments.
• Block unreviewed package and postinstall execution paths Restrict package installation behaviour that can inject code during build or publish steps. Require code review for workflow and package script changes, and quarantine high-risk maintainers until the exposed path is fully validated.

Key takeaways

• Shai-Hulud and Nx-style attacks show that a stolen token becomes far more dangerous when it already carries repo, admin, or workflow authority.
• The scale of secret leakage and CI/CD abuse means standing privilege is not a theoretical weakness, it is a repeatable supply-chain attack path.
• JIT access limits blast radius by making elevated GitHub permissions temporary, auditable, and task-scoped instead of always available.

Key terms

• Standing privilege: Standing privilege is access that remains active until someone explicitly removes it. In developer and CI/CD environments, that means admin, publish, or workflow-modifying rights can be reused by an attacker after a token is stolen, making the compromise broader and harder to contain.
• Inherited permissions: Inherited permissions are rights a user receives through group or team membership rather than a direct grant. They simplify administration, but they also spread risk, because one compromised member can gain access to every system the team controls if those rights are broad or permanent.
• Just-in-time access: Just-in-time access is temporary elevation granted only when a task requires it, then removed automatically. For non-human and developer identities, it turns privilege into a controlled event with scope and expiry, which reduces the value of stolen tokens and limits blast radius.
• CI/CD identity: CI/CD identity is the set of credentials, service accounts, and automation permissions used by build and release systems. It is part of the attack surface, because those identities can read secrets, publish artefacts, and trigger workflows even when no human is actively logged in.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws 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. Read the original.