Audit log

Every state-changing event for Injective (npm SDK supply-chain attack): moderation decisions on community submissions, plus corrections and updates from the news pipeline. URL-based decisions are designed to carry three independent witnesses — the original source, an Internet Archive snapshot, and a Solana memo signed by our publicly-disclosed publisher key. Archive coverage is still being backfilled, so each decision below reports its own snapshot status rather than assuming one exists.

1. #1publishby system:backfill

   2026-07-22 01:53:39Z
   Score: ? → ? (no score change)
   anchoranchored

   chain

   ●mainnet-betaslot 443,500,949

   sig

   63749bA2KsK8…JW1NWT8pcopyexplorer ↗

   hash

   FZBVgLvR6Zxf…ZzjftSYPcopysha256 → base58

   verifying row…full verify ↗

   canonical bytes (12037 B) ▸

   {"actor":"system:backfill","investigation_id":"7fcf4c4e-798e-4496-9187-53a8ab811cf1","kind":"publish","page_slug":"injective-npm-sdk-supply-chain-attack","published_at":"2026-07-22T01:53:38.976Z","sequence_num":1,"snapshot":{"content_type":"investigation","entity_name":"Injective (npm SDK supply-chain attack)","sections":[{"content":"This incident involved the compromise of a developer's npm/GitHub maintainer account used to publish packages for the Injective blockchain's official TypeScript SDK (@injectivelabs/sdk-ts) and 17 dependent packages. The attacker did not exploit the Injective blockchain, its consensus mechanism, or its smart contracts. Reporting from StepSecurity and The Hacker News characterizes the event specifically as a software supply-chain attack against npm-distributed developer tooling, analogous to other npm account-takeover incidents affecting unrelated projects. Framing this as a flaw in the Injective protocol itself would be inaccurate; the attack surface was the npm publishing pipeline and a single maintainer's compromised credentials.","heading":"Distinction: npm supply-chain attack, not a protocol exploit","severity":"low","sources":[{"credibility":2,"name":"Injective npm Supply Chain Attack: 18 Packages Backdoored to Steal Crypto Wallet Keys — StepSecurity","type":"research","url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"credibility":2,"name":"Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages — The Hacker News","type":"news_article","url":"https://thehackernews.com/2026/07/injective-labs-github-compromise-pushes.html"}]},{"content":"According to StepSecurity's technical analysis, an attacker gained control of a maintainer account (identified in commit history as \"thomasRalee\") and pushed malicious code directly to the master branch of the sdk-ts repository, bypassing standard pull-request review. The payload was disguised as \"key derivation telemetry for SDK usage analytics\" and was injected into wallet-construction functions, including PrivateKey.fromMnemonic() and PrivateKey.fromHex(). When a wallet was created or loaded using the affected SDK version, the code allegedly captured BIP-39 seed phrases and private keys, base64-encoded them, and exfiltrated them via the X-Request-Id header of POST requests spoofed to resemble legitimate Injective gRPC-web traffic — using a lookalike domain (testnet.archival.chain.grpc-web.injective.network) obfuscated as a character-code array to evade static analysis. Bleeping Computer and Socket similarly reported that the malware avoided install-time detection by only activating when key-generation functions were actually called, and batched stolen data over a two-second window before transmission to reduce network-traffic anomalies.","heading":"Attack mechanism and payload","severity":"critical","sources":[{"credibility":2,"name":"Injective npm Supply Chain Attack: 18 Packages Backdoored to Steal Crypto Wallet Keys — StepSecurity","type":"research","url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"credibility":2,"name":"Injective SDK on npm infected with cryptocurrency wallet stealer — Bleeping Computer","type":"news_article","url":"https://www.bleepingcomputer.com/news/security/injective-sdk-on-npm-infected-with-cryptocurrency-wallet-stealer/"}]},{"content":"The malicious payload was published as version 1.20.21 of @injectivelabs/sdk-ts and, because the repository used a monorepo release train with pinned exact-version dependencies, automated CI publishing propagated the same tainted release to 17 additional @injectivelabs-scoped npm packages within minutes — 18 packages in total. Reporting indicates the sdk-ts package normally receives roughly 50,000 weekly downloads and has 87 downstream npm dependents, whose cumulative download volume was cited at just over 112,000 per week, meaning the theoretical blast radius extended well beyond direct installers of the SDK to any project depending on it transitively.","heading":"Scope of propagation","severity":"high","sources":[{"credibility":2,"name":"Injective SDK on npm infected with cryptocurrency wallet stealer — Bleeping Computer","type":"news_article","url":"https://www.bleepingcomputer.com/news/security/injective-sdk-on-npm-infected-with-cryptocurrency-wallet-stealer/"},{"credibility":2,"name":"Injective npm Package Attack: 18 Packages Compromised, No Funds Lost — Sourcetrail","type":"news_article","url":"https://www.sourcetrail.com/javascript/npm/injective-npm-package-supply-chain-attack-what-developers-need-to-know/"}]},{"content":"Per StepSecurity's incident reconstruction, the malicious commit was added at 20:24 UTC on July 8, 2026; a version bump triggered automated publishing at 20:54 UTC; all 18 packages went live with the backdoored code between 20:59 and 21:00 UTC. A revert commit removing the payload followed at 21:16 UTC, and clean version 1.20.23 was published across all affected packages between 21:47 and 21:49 UTC — roughly 49 minutes after the compromised version first went live. Security firms Socket, Ox Security, and StepSecurity are credited with identifying the malicious release and prompting the response. Injective Labs deprecated version 1.20.21 on the npm registry and revoked the compromised account's access. CEO Eric Chen stated that \"no funds on the network are at risk.\" The compromised version was downloaded approximately 300–310 times before removal, a small fraction of the package's typical weekly volume, and reporting attributes many of those downloads to automated bots, mirrors, or security scanners rather than active developer integrations. No confirmed user fund losses have been reported in connection with this incident as of the most recent coverage reviewed.","heading":"Detection, response, and remediation timeline","severity":"medium","sources":[{"credibility":2,"name":"Injective npm Supply Chain Attack: 18 Packages Backdoored to Steal Crypto Wallet Keys — StepSecurity","type":"research","url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"credibility":2,"name":"Injective resolves npm package compromise in under an hour with zero user impact — CryptoBriefing","type":"news_article","url":"https://cryptobriefing.com/injective-npm-package-security-fix/"},{"credibility":2,"name":"Hackers attempt to backdoor Injective npm package to steal wallet keys — CryptoBriefing","type":"news_article","url":"https://cryptobriefing.com/injective-npm-backdoor-wallet-key-attack/"}]},{"content":"Security researchers advised that any credentials, mnemonics, or private keys processed by an application using @injectivelabs packages during the roughly 49-minute exposure window (July 8, 2026, approximately 20:59–21:49 UTC) should be treated as compromised and rotated, since the malicious code was designed specifically to intercept wallet secrets at the point of key generation or import. Developers who installed the affected 1.20.21 release, or applications with dependency ranges that could have resolved to it, were advised to upgrade to version 1.20.23 or later. This guidance applies to a narrow population of developers and downstream users who happened to install or run wallet-key-generation code during the exposure window; it does not indicate ongoing risk to the Injective network or to holders of INJ tokens generally.","heading":"Residual risk for developers and end users","severity":"medium","sources":[{"credibility":2,"name":"Injective npm Supply Chain Attack: 18 Packages Backdoored to Steal Crypto Wallet Keys — StepSecurity","type":"research","url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"credibility":2,"name":"Injective npm Package Attack: 18 Packages Compromised, No Funds Lost — Sourcetrail","type":"news_article","url":"https://www.sourcetrail.com/javascript/npm/injective-npm-package-supply-chain-attack-what-developers-need-to-know/"}]}],"sources_used":[{"credibility":2,"name":"Injective npm Supply Chain Attack: 18 Packages Backdoored to Steal Crypto Wallet Keys — StepSecurity","type":"research","url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"credibility":2,"name":"Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages — The Hacker News","type":"news_article","url":"https://thehackernews.com/2026/07/injective-labs-github-compromise-pushes.html"},{"credibility":2,"name":"Injective SDK on npm infected with cryptocurrency wallet stealer — Bleeping Computer","type":"news_article","url":"https://www.bleepingcomputer.com/news/security/injective-sdk-on-npm-infected-with-cryptocurrency-wallet-stealer/"},{"credibility":2,"name":"Injective resolves npm package compromise in under an hour with zero user impact — CryptoBriefing","type":"news_article","url":"https://cryptobriefing.com/injective-npm-package-security-fix/"},{"credibility":2,"name":"Hackers attempt to backdoor Injective npm package to steal wallet keys — CryptoBriefing","type":"news_article","url":"https://cryptobriefing.com/injective-npm-backdoor-wallet-key-attack/"},{"credibility":2,"name":"Injective npm Package Attack: 18 Packages Compromised, No Funds Lost — Sourcetrail","type":"news_article","url":"https://www.sourcetrail.com/javascript/npm/injective-npm-package-supply-chain-attack-what-developers-need-to-know/"}],"summary":"On July 8, 2026, a compromised maintainer GitHub account was used to publish a backdoored version of @injectivelabs/sdk-ts and 17 related npm packages, disguising a wallet-key-stealing payload as SDK usage telemetry. The malicious code was live for approximately 49 minutes before being reverted; Injective Labs stated no funds on the network were at risk and no user losses were confirmed. This incident is a software supply-chain compromise affecting an official npm SDK maintained by Injective Labs — it did not involve a vulnerability or exploit of the Injective blockchain protocol itself.","timeline":[{"date":"2026-07-08","event":"Malicious commit adding the wallet-key-exfiltration payload, disguised as SDK usage-analytics telemetry, is pushed directly to the master branch of @injectivelabs/sdk-ts using a compromised maintainer account (approx. 20:24 UTC).","source":"StepSecurity","source_url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"date":"2026-07-08","event":"A version bump triggers automated CI publishing of version 1.20.21, which propagates the backdoor to 18 @injectivelabs-scoped npm packages within minutes (approx. 20:54–21:00 UTC).","source":"StepSecurity","source_url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"date":"2026-07-08","event":"A revert commit removes the malicious payload from the repository (approx. 21:16 UTC).","source":"StepSecurity","source_url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"date":"2026-07-08","event":"Clean version 1.20.23 is published across all 18 affected packages and version 1.20.21 is deprecated on the npm registry, ending the exposure window at roughly 49 minutes (approx. 21:47–21:49 UTC).","source":"StepSecurity","source_url":"https://www.stepsecurity.io/blog/injective-npm-supply-chain-attack-18-packages-backdoored-to-steal-crypto-wallet-keys"},{"date":"2026-07-09","event":"Security researchers and outlets including Socket, Ox Security, The Hacker News, and Bleeping Computer publish analyses of the attack; Injective Labs CEO Eric Chen states no network funds are at risk.","source":"CryptoBriefing","source_url":"https://cryptobriefing.com/injective-npm-package-security-fix/"}]},"v":1}

   Verify offline (run on your own machine)

   python -m src.verify_decision abb1d605-490f-4832-8d93-28d8c8014478copy
2. #2reviewby reviewerreviewer

   2026-08-27 06:05:37Z
   Score: 62 → 62 (no score change)
   The page's core factual account -- date, mechanism (compromised maintainer account pushing directly to master, not a protocol exploit), affected package/version numbers, the ~49-minute exposure window, detection by Socket/Ox Security/StepSecurity, the Eric Chen 'no funds at risk' quote, and the absence of confirmed fund losses -- is consistently corroborated by primary vendor technical writeups (StepSecurity, Datadog) and independent secondary reporting, and all six cited URLs resolve without link rot. Three granular claims are only partially supported: a cumulative all-time download figure (~112,000) is mischaracterized as a weekly rate, an unsupported claim attributes the ~300-310 downloads to 'bots, mirrors, or scanners,' and the specific detail that Injective Labs 'revoked the compromised account's access' was not found in the primary technical source cited for that section. No disputed or unverifiable claims were found, and no evidence of self-propagating/worm behavior or unsupported threat-actor attribution was present in the page.
   anchoranchored

   chain

   ●mainnet-betaslot 443,524,214

   sig

   2aeWz5Qx4Ez3…bbsSwm5ocopyexplorer ↗

   hash

   AiiHgUNjL7kN…QyFdCxw3copysha256 → base58

   verifying row…full verify ↗

   canonical bytes (1426 B) ▸

   {"actor":"reviewer","decided_at":"2026-08-27T06:05:37.378Z","decision":"review","investigation_id":"7fcf4c4e-798e-4496-9187-53a8ab811cf1","new_score":62,"page_slug":"injective-npm-sdk-supply-chain-attack","prev_score":62,"reason":"The page's core factual account -- date, mechanism (compromised maintainer account pushing directly to master, not a protocol exploit), affected package/version numbers, the ~49-minute exposure window, detection by Socket/Ox Security/StepSecurity, the Eric Chen 'no funds at risk' quote, and the absence of confirmed fund losses -- is consistently corroborated by primary vendor technical writeups (StepSecurity, Datadog) and independent secondary reporting, and all six cited URLs resolve without link rot. Three granular claims are only partially supported: a cumulative all-time download figure (~112,000) is mischaracterized as a weekly rate, an unsupported claim attributes the ~300-310 downloads to 'bots, mirrors, or scanners,' and the specific detail that Injective Labs 'revoked the compromised account's access' was not found in the primary technical source cited for that section. No disputed or unverifiable claims were found, and no evidence of self-propagating/worm behavior or unsupported threat-actor attribution was present in the page.","score_delta":0,"sequence_num":2,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}

   Verify offline (run on your own machine)

   python -m src.verify_decision 13b4b98a-e0d3-49be-9501-3ae479f8f77bcopy
3. #3review approveby judgejudge

   2026-08-27 06:05:37Z
   Score: 62 → 62 (no score change)
   The review found no disputed or unverifiable claims among 28 tested (disputed_pct = 0/28 = 0.0%), and this was independently recomputed rather than taken on faith. The reviewer specifically tested, and confirmed with named primary sources, the things most likely to be wrong on a page of this type: that the incident is correctly classified as a compromised-maintainer npm publish rather than a protocol-level exploit (claim_findings[4], [5]), that the propagation to 17 additional packages is correctly attributed to pinned-dependency mechanics rather than a self-propagating worm (claim_findings[11]), that no unsupported threat-actor attribution appears on the page, and that the core account -- date, package/version numbers, the ~49-minute exposure window, detection credited to Socket/Ox Security/StepSecurity, the Eric Chen 'no funds at risk' quote, and the absence of confirmed losses -- is verbatim-corroborated against primary vendor writeups such as StepSecurity and Datadog (claim_findings[0], [2], [3], [14]-[16], [18], [20]). All six cited URLs were confirmed live. Three claims were only partially supported (claim_findings[13], [17], [19]), and notably all three imprecisions run in the same direction, making the incident look smaller or better-handled than sources establish: a cumulative all-time download total is presented as a weekly rate and used as the denominator for a reassuring 'small fraction' comparison, an account-access revocation is asserted beyond what the cited primary source states, and an unsourced claim attributes suspicious downloads to bots or scanners. Even treating the weekly-rate mischaracterization as a disputed claim rather than partially supported -- which is arguably the more defensible read, since it is load-bearing for a minimizing conclusion rather than merely incomplete -- the disputed_pct rises only to 3.6% (1/28), still comfortably inside the 0-10% approve band. Coverage gaps are medium (no GHSA/npm advisory or Injective-authored post-mortem) and low priority only, so the high-priority escalation rule is not engaged, and a clean accepted_submissions result reflects a successful empty query rather than an inaccessible database. The page is approved as published; the reassuring-imprecision pattern should be corrected editorially but does not meet the bar for a score penalty or status change.
   anchoranchored

   chain

   ●mainnet-betaslot 443,524,220

   sig

   ygtPmRiPGB6j…NkTpAUsNcopyexplorer ↗

   hash

   G1QW7eWav238…jomsZrQzcopysha256 → base58

   verifying row…full verify ↗

   canonical bytes (2738 B) ▸

   {"actor":"judge","decided_at":"2026-08-27T06:05:37.378Z","decision":"review_approve","investigation_id":"7fcf4c4e-798e-4496-9187-53a8ab811cf1","new_score":62,"page_slug":"injective-npm-sdk-supply-chain-attack","prev_score":62,"reason":"The review found no disputed or unverifiable claims among 28 tested (disputed_pct = 0/28 = 0.0%), and this was independently recomputed rather than taken on faith. The reviewer specifically tested, and confirmed with named primary sources, the things most likely to be wrong on a page of this type: that the incident is correctly classified as a compromised-maintainer npm publish rather than a protocol-level exploit (claim_findings[4], [5]), that the propagation to 17 additional packages is correctly attributed to pinned-dependency mechanics rather than a self-propagating worm (claim_findings[11]), that no unsupported threat-actor attribution appears on the page, and that the core account -- date, package/version numbers, the ~49-minute exposure window, detection credited to Socket/Ox Security/StepSecurity, the Eric Chen 'no funds at risk' quote, and the absence of confirmed losses -- is verbatim-corroborated against primary vendor writeups such as StepSecurity and Datadog (claim_findings[0], [2], [3], [14]-[16], [18], [20]). All six cited URLs were confirmed live. Three claims were only partially supported (claim_findings[13], [17], [19]), and notably all three imprecisions run in the same direction, making the incident look smaller or better-handled than sources establish: a cumulative all-time download total is presented as a weekly rate and used as the denominator for a reassuring 'small fraction' comparison, an account-access revocation is asserted beyond what the cited primary source states, and an unsourced claim attributes suspicious downloads to bots or scanners. Even treating the weekly-rate mischaracterization as a disputed claim rather than partially supported -- which is arguably the more defensible read, since it is load-bearing for a minimizing conclusion rather than merely incomplete -- the disputed_pct rises only to 3.6% (1/28), still comfortably inside the 0-10% approve band. Coverage gaps are medium (no GHSA/npm advisory or Injective-authored post-mortem) and low priority only, so the high-priority escalation rule is not engaged, and a clean accepted_submissions result reflects a successful empty query rather than an inaccessible database. The page is approved as published; the reassuring-imprecision pattern should be corrected editorially but does not meet the bar for a score penalty or status change.","score_delta":0,"sequence_num":3,"submission_content_hash":null,"submission_id":null,"submission_kind":null,"submission_valence":null,"v":1}

   Verify offline (run on your own machine)

   python -m src.verify_decision f77ca724-6c14-4f5c-9b3e-dee44e0d25a5copy