TL;DR: On July 8, 2026, at 20:24 UTC, an attacker who had hijacked a trusted Injective Labs GitHub maintainer account pushed three commits directly to the master branch of the official TypeScript SDK, adding a file called key-derivation-telemetry.ts. When the repository's automated trusted-publisher pipeline (GitHub OIDC to npm) triggered, it published @injectivelabs/sdk-ts version 1.20.21 to npm with a backdoor that exfiltrated cryptocurrency private keys and mnemonic seed phrases via a look-alike endpoint. The malicious release was live for approximately 49 minutes before detection, replacement by version 1.20.23, and public disclosure. Eighteen dependent packages were affected. For North Carolina SMBs that run any custom-software team, use ChatGPT/Cursor/Copilot to accelerate a devs' branch, or accept open-source dependencies in their own products, this incident is the operational blueprint for the next attack against your supply chain.
Key takeaway: The attacker did not steal an npm token. They did not phish a maintainer for a password. They hijacked a GitHub account with
master-branch push rights, and then let the trusted-publisher OIDC pipeline sign and publish the backdoor with legitimate credentials the maintainer never saw. Every NC SMB that leverages GitHub-to-npm, GitHub-to-PyPI, GitHub-to-Docker Hub, or GitHub-to-any registry with OIDC is one compromised contributor account away from the same outcome.
Need to lock down your custom-software supply chain before your OIDC pipeline ships a backdoor? Contact Preferred Data Corporation - BBB A+ rated, 37+ years of NC IT expertise, on-site within 200 miles of High Point. Call (336) 886-3282.
What Happened in the July 8, 2026 Injective Labs npm Compromise?
The Injective incident is the most compact, best-documented supply-chain-attack case study of Q3 2026. Three data points frame the risk for NC SMBs.
- Attack primitive: hijacked maintainer GitHub account. The attacker gained write access to the
InjectiveLabs/injective-tsGitHub repository via the account of an established contributor. No npm token was stolen; the attacker never touched npm credentials directly. - Publish primitive: legitimate OIDC trusted-publisher pipeline. Instead of a stolen npm token, the attacker rode the repository's own GitHub Actions to npm OIDC trusted-publisher pipeline. The pipeline signed and published
@injectivelabs/sdk-ts1.20.21 as if a normal release had been requested. - Payload: private-key and seed-phrase exfiltration to a look-alike domain. The backdoor file (
key-derivation-telemetry.ts) captured wallet private keys and mnemonic seed phrases from any application using the SDK, then exfiltrated them totestnet.archival.chain.grpc-web.injective.network, a domain crafted to blend into Injective's own infrastructure naming pattern.
The malicious release was live for approximately 49 minutes. Eighteen packages that depend on @injectivelabs/sdk-ts inherited the backdoor. Weekly downloads of the parent package sit around 50,000. The legitimate maintainer detected the intrusion, reverted the changes, and published version 1.20.23 as the safe upgrade.
Why Is This a Case Study for NC SMBs, Not Just Crypto Startups?
The instinctive reaction, "we don't do crypto, so this doesn't affect us," is wrong for three reasons that apply to any NC SMB with a custom-software footprint.
- The attack pattern is registry-agnostic. GitHub-to-npm OIDC trusted-publisher pipelines are a common pattern; the same OIDC-to-registry model is used by PyPI, Docker Hub, Maven Central, NuGet, Terraform Registry, and Helm chart repositories. Any NC SMB whose custom-software team uses this pattern is exposed to the same primitive.
- Any developer machine that pulled the bad version is compromised. During the 49-minute window, any developer whose CI/CD or local
npm installfetched 1.20.21 executed the backdoor. If that developer had wallet credentials, VPN certificates, SSH keys, or Microsoft 365 refresh tokens in memory or~/.config, they are all now exposure candidates for cleanup. - SMB customers inherit your supply-chain risk. If your NC SMB ships software to customers, distributors, or downstream integrators, a compromised dependency in your build turns into a downstream incident-response obligation. That is exactly the pattern MOVEit / CL0P demonstrated in 2023 and 3CX + SolarWinds demonstrated in 2020-2023, at a scale small enough to hit any NC SMB.
Even NC SMBs with no in-house developers face the same class of risk through their vendors: the SaaS platforms, marketing agencies, and MSPs that ship code into your environment are downstream of the same supply chain.
Key takeaway: If your NC SMB's engineering team cannot answer "which dependencies did we install between July 8 20:24 UTC and 21:13 UTC on Wednesday?" you do not have the audit-trail infrastructure to survive the next supply-chain attack. That baseline is achievable in one week with lockfile enforcement, signed-commit policy, and a dependency-inventory tool.
How Does the OIDC Trusted-Publisher Attack Actually Work?
The end-to-end chain has five stages, all executed under legitimate credentials.
- Attacker compromises a maintainer's GitHub account. Phishing kits like Kali365, EvilTokens, and the Vidar infostealer log market all deliver GitHub session cookies for pennies. The attacker does not need to know the maintainer's password.
- Attacker pushes directly to a privileged branch. In the Injective incident, the attacker pushed three commits directly to
masterwithout a pull request. That is the single control that would have stopped the attack: mandatory pull request + required review formasterand any release-triggering branch. - Repository's OIDC pipeline signs and publishes. GitHub Actions requests a short-lived npm token from the registry's OIDC endpoint. npm validates the request against its trusted-publisher configuration and issues the token. The pipeline publishes the new version signed as if by a normal release.
- Downstream developers install the malicious version. Any developer with
~/.npmrcset to auto-update, any CI/CD job with no lockfile enforcement, and any dependency-management bot (Renovate, Dependabot) that auto-updates without review will pull the backdoor. - Payload executes in the developer's environment. In Injective's case, wallet keys and seed phrases were exfiltrated. In an equivalent attack against a common analytics or React helper library, the payload could exfiltrate Microsoft 365 refresh tokens, GitHub personal access tokens, SSH keys, or AWS credentials from developer machines.
The Injective operators lost the race in this instance because a human maintainer noticed the anomaly inside an hour. Most SMB engineering teams do not have a human watching npm publications at 20:30 UTC on a Wednesday.
What Are the Immediate Actions for NC SMBs to Neutralize This Class of Risk?
Emergency hardening runs in three parallel workstreams over 30 to 60 days.
Workstream 1: GitHub source-of-truth hardening (Days 0-14).
- Enforce branch protection on every
main/masterbranch and every release-tag branch. Require pull requests, require at least one review from a non-author, and disallow force-pushes and direct pushes. - Enforce signed commits (GPG or Sigstore keyless via
gitsign). An attacker with only a hijacked web session cannot forge a valid commit signature. - Enforce hardware-key MFA (WebAuthn passkey) for every contributor with write access to any repository that triggers a publish pipeline. SMS-code and TOTP MFA is bypassable by session-cookie theft (Vidar, EvilTokens); WebAuthn is not.
Workstream 2: Publish-pipeline governance (Days 0-30).
- Convert every registry publish (npm, PyPI, Docker Hub, NuGet, Maven, Helm) to require a manual reviewer approval step in the GitHub Actions workflow, not just OIDC trust plus repo push.
- Pin the OIDC subject claim to a specific workflow file and branch. GitHub Actions supports a
job_workflow_refclaim that npm's trusted-publisher config can validate against, so a pushed workflow-file swap is caught. - Publish under a dedicated CI-only npm/PyPI identity, not under a developer's personal maintainer account. That way an account compromise on a human maintainer cannot swap out the publish identity.
Workstream 3: Consumer-side dependency governance (Days 0-60).
- Enforce lockfiles (
package-lock.json,pnpm-lock.yaml,yarn.lock,poetry.lock,go.sum,Cargo.lock) in every repository; block merges that regress lockfile-only changes without justification. - Use a dependency-scanning tool with time-window alerting: Renovate + a hold-for-N-days policy, Snyk, GitHub Dependabot with alerting to Slack/email, or Socket.dev. A 24-72 hour "hold" delay catches near-real-time compromise incidents like Injective.
- Instrument developer laptops with EDR/MDR and enforce OS credential vaulting (macOS Keychain with automatic lock on idle, Windows Credential Manager with DPAPI, Linux
libsecretwith a passphrase). Wallet keys and cloud credentials belong in an OS keychain, not a plaintext.envfile.
Explore Preferred Data's cybersecurity services
Trusted-Publisher OIDC vs Long-Lived Token: How Do the SMB Risks Differ?
Both patterns can go wrong; the failure modes and the durable controls are different.
| Publish Auth Pattern | Attack Primitive | Durable Control | Typical SMB Fit |
|---|---|---|---|
| Long-lived npm token in secrets | Token theft via CI log leak, secrets scan bypass | Rotate quarterly, restrict to CI IPs | Legacy small teams |
| GitHub OIDC trusted publisher | Hijacked GitHub account with main push rights | Branch protection + signed commits + manual approval | Modern teams with SSO |
| Manual publish from maintainer laptop | Maintainer laptop malware (Vidar, MFT, etc.) | Hardware-key MFA + EDR + short-lived tokens | Single-developer projects |
For most NC SMBs, GitHub OIDC trusted-publisher is materially safer than long-lived tokens because it eliminates a static secret that can be stolen. The failure mode that Injective demonstrates, hijacked contributor account with direct-push rights, is fully mitigated by branch protection plus signed commits plus a manual publish approval step.
Explore Preferred Data's software development services
How Does Preferred Data Help NC SMBs Govern the Custom-Software Supply Chain?
Preferred Data Corporation delivers software supply-chain governance, developer-laptop hardening, and 24/7 SOC monitoring for NC manufacturers, healthcare providers, financial institutions, professional services firms, and any NC SMB with a custom-software footprint. With 37+ years of NC IT expertise, an average client retention of 20+ years, and an on-site radius of 200 miles from High Point, we can close the supply-chain exposure this quarter.
- 72-hour supply-chain audit. Discovery of publish pipelines, OIDC trust configurations, branch-protection gaps, and lockfile-enforcement blind spots across your engineering repos.
- Branch-protection and signed-commit rollout. Structured deployment of GitHub branch protection, GPG or Sigstore signing, and hardware-key MFA enforcement across your contributor population.
- Publish-pipeline hardening engagement. Migration of npm/PyPI/Docker/NuGet publishes to manual-approval-gated OIDC with
job_workflow_refclaim pinning. - Developer-laptop MDR + credential-vault deployment. EDR/MDR on developer endpoints, forced OS keychain use, and browser-token protection to close the "malware on the maintainer's laptop" vector.
Ready to lock down your custom-software supply chain before your next OIDC publish ships a surprise? Call (336) 886-3282 or contact our team.
Frequently Asked Questions
We don't build cryptocurrency software. Does this attack apply to us?
Yes. The Injective incident is a case study for the OIDC-to-registry attack pattern, not the cryptocurrency payload. Any NC SMB engineering team with a GitHub-to-npm, GitHub-to-PyPI, GitHub-to-Docker Hub, or GitHub-to-any-registry publish pipeline is exposed to the same primitive. Substitute the wallet-key payload for an M365 refresh-token exfiltrator and the risk profile is your risk profile.
We use Dependabot / Renovate to auto-update dependencies. Are we safer or riskier?
Both, depending on configuration. Bot-driven auto-updates make patching timely, which is good; they also broaden the window during which a briefly-malicious version can reach production, which is bad. The durable configuration is: bot proposes update, human review required, minimum "quarantine" delay (24-72 hours) before merge, and merge blocked if any dependency-scanner alert fires against the version.
Are private repositories safer than public ones for this attack?
Marginally. The Injective repository is public; the attack primitive (hijacked contributor with push rights) applies identically to private repositories. Branch protection, signed commits, and hardware-key MFA are the durable controls; repository visibility is a minor factor.
Is npm's trusted-publisher OIDC feature the problem?
No; the underlying architecture is materially safer than long-lived tokens. The failure in the Injective incident was branch-protection and commit-signing hygiene, not OIDC itself. Well-configured OIDC with job_workflow_ref pinning and a manual approval step is the durable answer.
How do we know if one of our developers pulled the bad Injective version?
Grep every package-lock.json, yarn.lock, and pnpm-lock.yaml in your repos for @injectivelabs/sdk-ts entries at version 1.20.21 or 1.20.22. If any developer machine or CI job installed that version, treat the developer's environment and any secrets it touched as compromised: rotate npm tokens, GitHub PATs, SSH keys, cloud CLI credentials, and any wallet material.
How fast can Preferred Data audit our supply-chain posture?
For an active NC SMB inside our 200-mile service radius, a GitHub/npm supply-chain audit begins within one week and the written report lands inside three weeks. Call (336) 886-3282 to schedule.