FinWiki
日EN中

Module path confusion + LICENSE strip = the three-hit combo of a supply-chain attack

Confidence: Likely Updated 2026-05-26 Review by 2026-09-22 Sources 3 Machine-translated Original (JA)
#security/supply-chain#security/dependency#security/dd
On this page

Wiki route

This entry sits under FinWiki index. Read it with fork-and-rebrand audit framework for peer context and systems index for the broader dependency boundary.

[!info] TL;DR A combination of 3 independent operations forms a supply-chain attack: (1) spoof the upstream (e.g., github.com/cosmos/…) in the module path of go.mod / package.json; (2) hijack the spoofed path to one’s own fork with a replace directive; (3) delete the LICENSE of the main repository. When a downstream user imports the “legitimate” path, what actually executes is the fork. On the regulated VASP route, this kind of attack surface is partially covered by the Domestic VASP security / audit / ISMS certification landscape system.

1. Module path confusion

  • Go: module github.com/cosmos/cosmos-sdk, but the actual repository is github.com//x
  • npm: name @cosmos/sdk, but the scope is not owned by the company itself
  • When a user runs go get github.com/cosmos/cosmos-sdk, they may obtain the spoofed fork via GOPROXY

2. Replace hijack

  • go.mod contains replace github.com/cosmos/cosmos-sdk => ./fork
  • When an upstream user pulls in the project, the replace passes through transparently and they are forced to use the fork
  • Combined with the module path, this constitutes a double spoof

3. LICENSE strip

  • No LICENSE file is placed in the main repository
  • Even if the original project is a fork of Apache 2.0, downstream users are, legally, using it without a license
  • This step is easily overlooked, yet it markedly expands the legal surface

Identification checklist

  • Does the module path on line 1行 of go.mod match the GitHub URL?
  • Is there a replace directive in go.mod?
  • Is there a LICENSE / LICENSE.md / LICENSE.txt at the root of the main repository?
  • Does the name field of package.json match the actual scope on the npm registry?
  • Has the original fork name slipped into a commit message (e.g., a self-incriminating string like “for ”)?

When to Use

  • Cases where a project claims to be “fully developed in-house” but the repository structure closely resembles a fork
  • Cases where a downstream user riding on this dependency conducts a supply-chain risk audit — in major incidents like Bybit Lazarus hack, the real risk of social-engineering / build-toolchain attacks on the third-party-dependency side is fully exposed
  • Cases where the legal side evaluates “which OSS this company uses / whether the licensing is appropriate”

When NOT to Use

  • A project that explicitly states “fork of X” and retains the original LICENSE — this qualifies as a legitimate fork
  • A purely application-layer project with no module-path concept
  • A closed-source, un-auditable project (which must be addressed via another route) — for example, a case like Canton on a permissioned chain must follow a governance + auditor route rather than source diff

Provenance

  • Case study (vaporware audit): a case where most of the code was directly copied from an upstream public-chain project, the upstream module path was spoofed in go.mod, it was hijacked to a local fork with replace, the LICENSE of the main repository was deleted, and the upstream project name leaked into a commit message, self-incriminating the project