BufferZoneCorp:
Go modules and Ruby gems that hijack your CI, still live on GitHub five months after takedown

What happened

On April 20, 2026 at 12:06 UTC a GitHub account called BufferZoneCorp was created. Between 12:28 and 13:26 UTC, about 80 minutes, it published fifteen repositories: Go libraries with ordinary names (go-retryablehttp, grpc-client, net-helper, go-metrics-sdk, log-core) and Ruby gems dressed as Rails tooling (activesupport-logger, devise-jwt-helper, rack-session-store, rails-assets-pipeline). config-loader followed on April 21 and go-stdlog on April 24. Each one has a tidy README and working library code. Most of them also carry a payload.

Socket found the campaign and published a detailed analysis on May 1, 2026, covering the credential theft, the SSH key, the Go proxy and logrus swap, the fake go binary and the HTTPS_PROXY redirect. On May 13 the packages were listed in OSV. Today proxy.golang.org returns no versions for any of the ten modules, and all seven knot-* gems are gone from rubygems.org.

The source code is a different story. When we checked on October 2, 2026, all seventeen repositories were still public on GitHub, with every payload intact. A Go module can be fetched directly from its repository with GOPROXY=direct or GOPRIVATE, and anyone can copy the code into a new module. We reported the account to GitHub the same day, and read every repository in full. This post describes the whole campaign and marks what we found that had not been reported before.

The registries took the packages down in May. The code that steals your keys stayed one git clone away.

Timeline

• Apr 20, 2026 12:06 UTCGitHub account BufferZoneCorp created.
• Apr 20, 12:28 to 13:26 UTCFifteen repositories created in about 80 minutes: the Go modules first, the Ruby gems last.
• Apr 20, 12:28 and 12:40 UTClog-core is published with a full credential stealer in its first commit. Twelve minutes later a commit titled "v0.2.0: remove telemetry" strips it out, leaving a clean decoy.
• Apr 21 to 23, 2026config-loader added; payload revisions pushed to the Go and Ruby repositories.
• Apr 24, 2026 08:21 UTCgo-stdlog, a CI and container reconnaissance module, added.
• May 1, 2026Socket publishes its analysis of the campaign.
• May 13, 2026 03:09 UTCAll 17 packages listed in OSV (MAL-2026-3620 to 3636), referencing Socket's analysis.
• May 14, 2026The ten Go modules enter CyberXYZ's malicious-package data; the CyberXYZ Go proxy, CLI and IDE extension block them from then on.
• Sep 29, 2026The seven knot-* gems enter CyberXYZ's data through an OSV backfill.
• Oct 2, 2026CyberXYZ confirms the modules are gone from proxy.golang.org and the gems from rubygems.org, but all 17 source repositories are still live on GitHub. Reported to GitHub.

The packages

The Go modules split into roles. Some steal, some rewire the build, one does reconnaissance, and a few are clean decoys that make the account look like a real publisher.

How the main stealer works

go-stdlib-ext carries the most complete payload. Importing any package from it is enough; nothing has to be called.

The CI attacks are the interesting part

Stealing files from a home directory is common. What sets this campaign apart is how much effort goes into GitHub Actions, where two files decide what every later step sees: $GITHUB_ENV sets environment variables for the rest of the job, and $GITHUB_PATH puts directories in front of PATH. A dependency that writes to them during one step controls the steps that follow.

Swapping a dependency through the Go proxy

go-metrics-sdk and go-weather-sdk write GOPROXY=<collector>|direct, GOSUMDB=off, GONOSUMDB=*, GOFLAGS=-mod=mod and a fresh GOMODCACHE to $GITHUB_ENV. Then they delete every github.com/sirupsen/logrus line from the project's go.sum. The effect: the next go command in the job has no recorded hash for logrus, no checksum database to ask, an empty module cache and an attacker-controlled proxy. It fetches logrus from the attacker. These two modules contain no stealer at all; their job is to make the build pull something else. The collector here is a webhook[.]site URL, which cannot serve modules, so as published this step would fail the build rather than swap anything. The mechanism is complete; only the server is missing.

The collector address is written as a list of what look like IP addresses, "104.116.116.112", "115.58.47.47", .... They are not addresses: each number is a character code, and the list decodes to the same webhook[.]site URL.

Tokens through a proxy header

go-retryablehttp takes a different route. It writes HTTPS_PROXY and HTTP_PROXY pointing at the collector into $GITHUB_ENV, so outbound traffic from later steps is directed there, and drops a fake go into the Go build cache that runs curl with X-Token: ${GH_TOKEN}, X-Run-Id and X-Repo sent as proxy headers before handing off to the real toolchain. The URL it requests belongs to a second module path, github[.]com/hashitools/go-retryablehttp, a HashiCorp lookalike that does not exist.

Git hooks and a fake kubectl

grpc-client, net-helper and config-loader walk up from the working directory to the nearest .git and prepend a line to .git/hooks/post-commit that sends the base64-encoded origin URL to the collector after every commit. The hook keeps working after the module is removed. grpc-client also places a fake kubectl first on the CI path that sends each command line, base64-encoded, before running the real one.

The Ruby side

Five of the seven knot-* gems carry a payload. Two run it at install time: they declare a native extension, and RubyGems runs the extension's ext/extconf.rb during gem install, before any application code loads. knot-activesupport-logger does this directly; knot-devise-jwt-helper keeps its version in a base64 blob handed to eval. The other three, knot-rack-session-store, knot-rails-assets-pipeline and knot-rspec-formatter-json, run when the gem is required. The two remaining gems ship an empty build script and no payload, so the native-extension pattern looks normal.

Each payload reads the same files as the Go stealer (SSH keys, cloud and registry credentials) and posts them with Net::HTTP. The default destination is hxxp://localhost:9999/collect; the real one comes from PKG_ANALYTICS_URL. Three things in the Ruby code had not been reported before:

• RUBYOPT persistence in CI. All five gems, when $GITHUB_ENV exists, write a small Ruby file named monitor.rb into a hidden directory in the home folder (~/.activesupport/lib, ~/.devise-jwt/lib, ~/.rack-session/bin, ~/.rails-assets/lib, ~/.rspec-fmt/lib) and append RUBYOPT=-r<path>/monitor.rb to $GITHUB_ENV. From then on, every Ruby process in the job loads the attacker's file first, including test runs and deploy scripts that never touch the gem.
• A second SSH key. knot-rack-session-store appends its own ssh-ed25519 key, with the comment deploy@rack-session, to ~/.ssh/authorized_keys. The knot-devise-jwt-helper blob also writes a key, but as published it decodes to code with corrupted names and a placeholder key (attackerPublicKeyHere), so that payload most likely fails.
• The git hook, in Ruby. knot-rails-assets-pipeline installs the same post-commit beacon as the Go modules, sending the base64-encoded origin URL after every commit.

knot-rails-assets-pipeline only runs its stealer when RAILS_ENV looks like production or staging, when GITHUB_ACTIONS is set, or when PKG_TELEMETRY_ENABLED is set, which keeps it quiet on most developer laptops. knot-rspec-formatter-json records which CI system it is running in.

Indicators of compromise

How CyberXYZ handles it

The ten Go modules have been in CyberXYZ's malicious-package data since May 14, 2026, and the CyberXYZ Go proxy, CLI and VS Code extension return decision: block for them. That covers installs that go through the CyberXYZ Go module proxy. It does not cover code fetched with GOPROXY=direct or copied into another module, which is why the live repositories matter. The seven gems were only added on September 29, 2026, through an OSV backfill, so CLI and SBOM scans flag them from that date. We do not run a RubyGems proxy, so nothing of ours would have stopped a gem install.

Writing this teardown also exposed a gap in our own pipeline, and we would rather say so. When we replayed go-retryablehttp through our Go content scanner, it scored zero: our checks looked for attack classes we had anticipated, such as standard-library impostors, suspicious replace directives and risky go:generate lines, and none of them describe what this code does. We have added checks for the behaviour seen here and in the earlier Go typosquat waves: writes to $GITHUB_ENV or $GITHUB_PATH from a package with an init(), XOR-decoded byte literals, a binary named go written next to a lookup of the real one, commands built from single-character strings, request-catcher endpoints, and init() spawning sh -c. The same module now scores 95 out of a promotion threshold of 80. Before shipping, we ran the checks over 2,691 real Go modules, including 207 of the most depended-on ones and 1,451 new modules from one week of the public Go module index. None reached our notification threshold.

Supply-chain risk analysis

Mapped to MITRE ATT&CK:

Recommended actions

Immediate. Remove any of the packages above. On every machine or self-hosted runner that built code importing them, rotate SSH keys, cloud credentials, npm and Docker tokens, gh tokens and Kubernetes credentials; delete the deploy@buildserver key from authorized_keys; clean .git/hooks/post-commit in affected repositories; and remove the ~/.config/*/bin wrapper directories.

Short-term. Treat a dependency that writes to $GITHUB_ENV or $GITHUB_PATH as hostile. Pin GOPROXY, GOSUMDB and GONOSUMDB explicitly in workflows so a later step cannot quietly change them, and give jobs the narrowest GITHUB_TOKEN permissions they need.

Long-term. A registry takedown removes the package, not the code. Route Go and Ruby installs through a checking proxy, and do not allow GOPROXY=direct fallbacks in CI, so that a known-malicious module is refused however it is requested.