Malicious npm infostealer exposed its own GitHub token

At a glance

What this is: OXSecurity identified a malicious npm package that acted as an infostealer and exposed its own GitHub token, making the theft path observable.

Why it matters: For IAM and NHI practitioners, the incident shows how a single exposed token can enable hidden exfiltration, rapid abuse, and weak offboarding of compromised identities.

By the numbers:

• 676 downloads
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read OXSecurity's analysis of the malicious npm infostealer and exposed GitHub token

Context

Malicious npm packages increasingly function as delivery vehicles for credential theft and file exfiltration, especially when attackers can hide behind normal package installation behavior. In this case, the primary security issue is not only malware in a software supply chain, but the abuse of a private GitHub token that enabled remote collection and staging of stolen files.

For identity and access teams, this is an NHI governance problem as much as a supply chain problem. A leaked token, a fallback credential, or an over-trusted automation account can give malware enough access to create repositories, upload data, and mask theft as routine synchronization. The pattern is typical of modern secrets abuse rather than an unusual one-off.

Key questions

Q: What breaks when a malicious package can use a GitHub token to exfiltrate files?

A: The main failure is that package installation becomes an authenticated data-transfer path. If the token can create repositories or write content, the attacker can move stolen files through ordinary API traffic, hide behind legitimate tooling, and retain access until the credential is revoked. That is why token scope and revocation speed matter as much as malware detection.

Q: Why do exposed GitHub tokens increase risk beyond the initial malware infection?

A: Because the token is a reusable non-human identity credential, not a one-time exploit. Once leaked, it can be replayed from anywhere, often with privileges that outlive the infected host. The risk extends to repository creation, content upload, and covert persistence across multiple sessions until the credential is rotated or disabled.

Q: How do security teams detect package-based data exfiltration in practice?

A: Look for linked signals across process, file, and network telemetry. Unexpected Python child processes, local archive creation, and outbound POST uploads from a workload that should not be moving bulk data are stronger indicators together than any one event alone. The goal is to reconstruct the sequence, not just flag a single command.

Q: Who is accountable when a compromised token is used to move across multiple systems?

A: Accountability usually spans identity owners, platform owners and security operations because the failure is distributed across issuance, scope, monitoring and revocation. In practice, frameworks such as Zero Trust and NHI governance require named ownership for each trust path, not just for the initial login event.

Technical breakdown

How the malicious npm package performed file exfiltration

The package behaved like a post-install malware loader. After installation, it authenticated to GitHub using either an environment token or a hardcoded fallback, checked whether a target repository existed, created one if necessary, then recursively walked a local directory and uploaded files through the GitHub Contents API. This is a common exfiltration pattern because it converts trusted developer tooling into an outbound data channel. The use of a random per-run folder name also helps separate theft sessions and complicates simple detection logic.

Practical implication: treat package-install execution paths as privileged data-transfer routes and restrict where tokens can be used.

Why exposed GitHub tokens turn into NHI abuse

A GitHub token is a non-human identity credential when it grants machine-mediated access to repositories and content APIs. Once exposed, it can be used without user interaction, often with broader reach than the original context intended. In this case, the token enabled repository creation, file upload, and concealment of the operator’s actions inside legitimate API traffic. That makes lifecycle controls, scope limitation, and revocation speed the decisive defenses, not just malware scanning after the fact.

Practical implication: inventory all GitHub tokens, constrain scope tightly, and revoke any token that could support repository write access.

How the malware disguised theft as diagnostics

The script wrote fake network status logs and used bland comments and commit messages to look like an internal utility rather than an infostealer. That matters because defenders often key on obvious malicious strings, while operators increasingly blend theft into plausible DevOps workflows. The result is a mismatch between what the code claims to do and what the runtime behavior actually does. Behavioural inspection and egress monitoring are therefore more reliable than filename or comment-based triage alone.

Practical implication: detect what code does at runtime, not just how it is labeled in source or package metadata.

Threat narrative

Attacker objective: The attacker aimed to harvest local files and move them into attacker-controlled GitHub storage while avoiding obvious detection.

1. Entry occurred when a malicious npm package was installed into a developer or workstation environment and executed its post-install logic.
2. Credential access happened when the malware used a hardcoded or environment-supplied GitHub token to authenticate to GitHub APIs.
3. Escalation and impact followed when the token was used to create repositories, upload stolen files from local storage, and exfiltrate data in disguised sessions.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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

NHI Mgmt Group analysis

Exposed developer tokens are now a software supply chain problem, not just a secrets hygiene issue. The package did not need sophisticated exploitation once a usable GitHub token was available. It converted ordinary package installation into authenticated data theft, which means token scope, token storage, and revocation speed are now part of software supply chain governance. Practitioners should treat developer tokens as high-value NHIs that need lifecycle control, not informal convenience credentials.

Hardcoded fallback credentials create a standing privilege window that malware can reuse at scale. If the malware can authenticate with either an environment token or an embedded backup token, defenders lose the assumption that one credential path can be removed independently. That failure mode is especially dangerous in automation-heavy environments where secrets are copied across build systems, local workstations, and test repositories. Practitioners should assume that any fallback credential broadens blast radius unless it is eliminated entirely.

Behavioural disguise is now part of the threat model for package-based infostealers. The code’s fake diagnostics, bland comments, and repository-sync language were designed to look administrative rather than malicious. That matters because static review alone will miss many cases where a package’s runtime behavior, not its naming, is the real threat. Practitioners need policy, telemetry, and detection that focus on outbound file movement and unexpected API writes.

Identity governance must now extend to AI-assisted malware creation and sloppy attacker opsec. The article’s final point is not that AI created a new class of threat, but that it lowered the bar for producing workable malware. In practice, that means more low-skill attackers will misuse tokens, repositories, and package infrastructure in ways that still produce real harm. NHI governance should therefore assume higher event volume, not just more sophisticated adversaries.

GitHub token misuse here shows why NHI governance must include repository write privileges and data egress controls. The core failure was not only malware execution but an identity credential that could create repositories and push data outward. In OWASP-NHI terms, this maps directly to secret exposure and excessive privilege. Practitioners should treat repository write access as a monitored control plane, not a routine developer convenience.

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.
• 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 control view: the Guide to the Secret Sprawl Challenge explains how hardcoded credentials and CI/CD exposure turn into persistent access risk.

What this signals

Secret sprawl is now a runtime risk, not a storage problem. Packages, scripts, and build systems are increasingly able to move credentials and data in ways that bypass traditional review. For identity teams, the practical shift is toward revocation latency, token scoping, and egress telemetry rather than simply asking where secrets are stored.

Machine identity sprawl will keep colliding with software delivery. The more tokens, API keys, and service credentials are embedded into developer workflows, the more often malware can turn them into exfiltration channels. This is why the Secret Sprawl Challenge matters to IAM and PAM teams as much as to appsec teams.

The operational signal for practitioners is clear: if a token can create, write, or sync repository content, it should be treated as a monitored privileged identity. Pair that with external guidance such as the NIST SP 800-53 Rev 5 Security and Privacy Controls to anchor auditability, credential management, and access restriction in one programme.

For practitioners

• Revoke exposed GitHub tokens immediately Inventory all GitHub tokens used by developers, CI jobs, and automation, then revoke any credential that could create repositories or write content. Replace broad tokens with narrowly scoped credentials and keep a short revocation path for suspected compromise.
• Scan package-install workflows for unexpected file egress Monitor post-install hooks, recursive file reads, and API writes to GitHub or other remote services. Treat outbound uploads from directories such as /mnt/user-data, workspace folders, and temp paths as high-risk telemetry.
• Restrict token fallback paths in build and developer tooling Remove hardcoded fallback tokens from scripts, package metadata, and internal utilities. If a credential can still authenticate after the primary secret is removed, the control is incomplete.
• Classify GitHub tokens as governed NHIs Assign ownership, purpose, expiry, and rotation rules to every machine token that can access code or content APIs. Include repository creation, content upload, and workflow automation tokens in the same lifecycle inventory.

Key takeaways

• This incident shows that a malicious package can turn an exposed GitHub token into a full exfiltration path.
• The scale signal is not just 676 downloads, but the fact that exposed secrets remain exploitable long after discovery unless they are revoked.
• Teams should govern developer tokens as NHIs, with tight scope, fast revocation, and runtime monitoring for unexpected repository writes.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Post-install Malware: Post-install malware is code that executes after a package is installed, rather than waiting for a user to run a separate payload. This matters in software supply chains because installation itself becomes the attack window, often with access to local files, environment variables, and developer credentials.

What's in the full analysis

OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• Step-by-step tracing of the malicious npm package’s post-install behaviour and GitHub API use
• Repository artifacts, commit timing, and exfiltration observations that support incident reconstruction
• Immediate response actions for anyone who may have installed the package, including token revocation and file checks
• The threat actor’s infrastructure and testing pattern before the package was taken down

👉 The full OXSecurity post covers the exfiltration path, token behaviour, and response steps in more detail.

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 is designed for practitioners who need to turn identity risk into operational control across modern environments.