Hunting Go for 90 days:
9.3 million module versions, the campaign we missed, and the dependencies that live only in Google's cache

Why Go needs its own playbook

Most supply-chain detection was built for npm and PyPI, where a central registry hosts every package and install scripts are the usual way in. Go works differently, and each difference changes what an attacker does and what a defender has to watch.

Four published campaigns

Socket discovered three of them and Aikido the fourth. The dates are when the OSV records were listed.

How we hunt

Data sources

The four hunting lanes

The static checks

Every scanned module goes through 20 checks over the zip. N1 to N10 are priors we designed in advance. The other ten were added after real campaigns scored zero against them: N11 to N17 after BufferZoneCorp, N18 to N20 after Graphalgo.

Scores add up with an anomaly scanner (capped at 60) and a tier credit. 50 notifies an analyst, 80 makes a promotion candidate, and AI triage reviews grey-zone scores before anything is promoted. New modules have one more rule, the payload gate: they are scored only when N1, N10 or N11 to N20 fires, so a fork cannot score on copied tests and binaries alone.

The 90-day look-back

Lookalikes

15,411 of the 15,447 lookalikes are plain repository-name copies, almost all of them forks: a fork published as a Go module keeps the upstream's repository name. The names copied most are large, much-forked projects, not obvious typosquat targets.

Burst accounts

8,196 owners published three or more new Go repositories within an hour at least once in 90 days. Most are organisations with monorepos split into modules, or developers pushing a batch of projects; 604 published 20 or more in a single hour. Account age is what separates a batch upload from a BufferZoneCorp.

Of the 8,086 owners we could resolve, 65 were 14 days old or younger when they burst, with 448 repositories between them, and 110 accounts no longer exist, with 657 repositories still in the index. We scanned all 1,105: 1,098 had no payload signal, 5 were too large to fetch, and two young accounts were flagged on N12 by the same file. Both were false positives.

The two modules were forks of the sing-box proxy platform, github.com/oixcloud3rd/sing-box (score 95) and github.com/akari-project/sing-box (score 40). The file was cmd/internal/read_tag/main.go, which is identical in upstream sagernet/sing-box v1.14.2:

It is sing-box's own CI helper: a command-line tool that writes the release version into $GITHUB_ENV when its workflow runs it with -ci. It has an init(), opens $GITHUB_ENV for appending, and so matched N12 exactly. What it is not is a library: a dependency's package main never runs when the module is imported, so it cannot be an import-time payload. N12, N16 and N17 now skip package main files. The same code in a library package still fires, and every campaign above put its payload in a library.

The campaign we missed: Graphalgo

On October 2, OSV listed two Go modules as malicious: gocommunity.io/orderedbtree (first published around August 11) and gogets.dev/btreex (around September 8), part of a campaign Aikido calls Graphalgo, which also reached Terraform providers. Both were published inside our window. Neither appears in our results, for two reasons that are both ours.

The module zips show why. The payload is split so no single file looks like much, and the package tells AI coding assistants and security scanners to look away.

The ignore files exclude ordinary build directories, which makes them look like routine project hygiene, and **/deprecated/, which is where the loader lives. We did not see this AI-assistant and scanner evasion described in Aikido's write-up, so we note it here. gocommunity.io/orderedbtree does the same with a 1 MB orderedbtree.so that is not a native binary. OSV marks every version of both modules as affected; in the versions we examined, orderedbtree v1.0.0 carried none of these files.

The CyberXYZ Go proxy has blocked both modules since 07:22 UTC on October 2, when the OSV records entered our data. On October 7, five days after the OSV listing, the public module mirror was still serving all 16 versions of orderedbtree and all 6 of btreex.

Tag drift: the mirror's copy vs the repository

Tag drift is the check for the boltdb-go technique, and a clean baseline is everything: if legitimate modules routinely differ between the mirror and GitHub, the check is useless. They do not. Before going live we compared 36 popular libraries by hand, including aws-sdk-go (2,871 files) and the major-version modules golang-jwt/jwt/v5, go-redis/redis/v8, redis/go-redis/v9 and jackc/pgx/v5. All 36 matched file for file.

The check now cycles through the popular list about every three hours. A drift alert goes to an analyst with the changed, proxy-only and tag-only file lists and a link to the tag. A maintainer moving a tag after release is the likeliest benign cause, and worth knowing about in its own right: the mirror keeps serving the old bytes to everyone.

What lives only in Google's cache

The source-status sweep asked a simple question of the 4,260 GitHub repositories with three or more dependents among the Go modules we watch: does the repository still exist? 4,068 answered normally.

A rename is mostly harmless: GitHub redirects the old URL, so go get keeps working. It becomes a risk when the old owner name is free, because whoever registers it can create a repository at the old path and publish new versions to anyone who runs go get -u. GitHub retires the namespace of any open-source project that had more than 100 clones in the week before its owner was renamed or deleted, so popular projects are usually protected. From the outside there is no way to tell which are, short of trying to register the name, which we did not do.

Thirteen repositories are gone. Twelve of their owners still exist, so the path cannot be reclaimed by someone else, but no fixes will ever ship from it.

github.com/tyler-smith/go-bip39

go-bip39 is a BIP-39 implementation: it turns entropy into the mnemonic seed phrases that cryptocurrency wallets are restored from. Both the repository and the tyler-smith account have been deleted. The module mirror still serves its tagged versions (latest v1.1.0, October 2020) and a pseudo-version for the last commit, made on 2024-08-17. Projects that resolve modules without the mirror have already hit the deletion: the Prysm Ethereum client's issue #15997 is titled "github.com/tyler-smith/go-bip39 is gone", and others have moved to github.com/cosmos/go-bip39, a fork used by the Cosmos SDK. It is not a drop-in: its v1.0.0 lacks SetWordList, GetWordList, GetWordIndex and EntropyFromMnemonic, and its last commit was in December 2020. Code that only creates and validates English mnemonics and derives seeds can switch; anything else needs a closer look, or a vendored copy of the original.

We checked the cached code before writing about it. The 2024 commit is a normal maintainer update: entropy comes from crypto/rand, there are no network or exec imports, and our scanner finds nothing. Nothing indicates the module has been compromised. The exposure is forward-looking: the owner name is unclaimed, so if GitHub did not retire the namespace, someone could recreate the repository and publish new versions of a library that generates wallet keys. Given how widely it was used, retirement is the likely outcome, but it cannot be confirmed from the outside.

Since October 2, CyberXYZ flags it at install time. The check never blocks; it tells the developer what happened and what to use instead:

What we got wrong

A report that only lists hits hides how much tuning a detector needs. These are the misses and false positives from building and running this pipeline, all between September 30 and October 2.

Indicators and hunting signatures

From the published campaigns above: Socket's and Aikido's discoveries, BufferZoneCorp details from our teardown, Graphalgo file details from the module zips. Defanged.

Hunting the index yourself

Everything in this report can be reproduced from public endpoints. Three starting points:

Recommendations for Go teams

What CyberXYZ runs, and what it does not

Supply-chain risk analysis

Mapped to MITRE ATT&CK: