BufferZoneCorp Sleeper Attack: Poisoned Ruby Gems and Go Modules Draining CI/CD Pipelines — Threat Brief: May 2, 2026

Sources: Socket.dev (Kirill Boychenko) · The Hacker News · CyberPress · Fyself News  |  Threat Actor: BufferZoneCorp (GitHub)  |  Ecosystems Hit: RubyGems · Go modules · GitHub Actions  |  Severity: High — credential-stealing, CI pipeline tampering, SSH persistence

The attack that hides in plain sight

Picture this: your team adds a new logging helper to your Rails project. The gem is called knot-activesupport-logger. It has a clean README, a plausible version history, and a name that sounds like it belongs alongside ActiveSupport — the core Rails utility library millions of developers use every day. Your CI runner installs it without complaint. Your security scanner doesn’t flag it. Nothing looks wrong.

But the moment that gem installed, it quietly ran a hidden script embedded in its native extension build process. Before your CI job even got to your actual test suite, the package had already swept your build environment for SSH keys, AWS credentials, GitHub CLI tokens, npm configuration files, and RubyGems credentials — and silently shipped everything to an attacker-controlled endpoint. This is the BufferZoneCorp campaign, documented in a deep-dive published by Socket security researcher Kirill Boychenko and picked up by The Hacker News on May 1, 2026. It is one of the most technically sophisticated open-source supply chain attacks documented so far this year.

What makes this attack different: the sleeper strategy

Most malicious packages are obvious in hindsight — they contain suspicious code from the moment they’re published. BufferZoneCorp did something smarter. The campaign began with sleeper packages: initially clean, professional-looking releases with standard README content, correct version metadata, and no overtly malicious behavior. The packages passed basic automated screening. Some likely sat in developer dependency files for days or weeks before the attackers updated them to add active payloads.

This two-stage approach — publish clean, then update to malicious — is designed specifically to defeat the most common supply chain defenses. Organizations that lock dependencies to a specific version hash at install time are not protected if the malicious update arrived before the lock. Organizations that run automated scanners only at initial dependency adoption may have missed the updated versions entirely. It is a deliberate exploitation of the gap between when a package is trusted and when it becomes dangerous.

The Ruby side: credential theft at install time

The Ruby gems in the BufferZoneCorp campaign carry their malicious payload through two separate execution paths, both designed to run as early and as quietly as possible.

Path 1 — The extconf.rb install-time hook

RubyGems treats extconf.rb as part of the native extension compilation process. If a gem includes this file, RubyGems runs it automatically during gem install — before the developer ever imports or uses the package. The malicious gems embedded their credential-harvesting logic here. The moment bundle install or gem install runs in a CI environment, the script executes. It sweeps the filesystem and environment for:

• Environment variables (all of them — including anything injected by CI secret managers)
• SSH private keys (~/.ssh/id_rsa, id_ed25519, and others)
• AWS credentials (~/.aws/credentials, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
• GitHub CLI configuration (~/.config/gh/hosts.yml) containing OAuth tokens
• .npmrc files containing npm publish tokens
• .netrc files often storing Git hosting credentials
• RubyGems API keys from ~/.gem/credentials

Everything collected is serialized and sent to a hidden exfiltration endpoint. The process produces no terminal output and no error. From the developer’s perspective, the bundle install just… completed normally.

Path 2 — The runtime logger hook

As a second bite at the apple, several gems also embed a runtime hook inside the advertised functionality itself. Taking knot-activesupport-logger as an example: the gem presents itself as a logging helper. The first time application code calls the logger, it triggers a secondary credential harvest and exfiltration — a fallback for environments where the install-time hook was interrupted or sandboxed. This dual-path design means the malware has two independent opportunities to exfiltrate secrets from any environment where the gem is installed.

The Go side: CI pipeline sabotage and proxy poisoning

The Go modules in the campaign are technically more diverse and, in some ways, more dangerous. While the Ruby gems focused primarily on credential harvesting, the Go modules do several additional things that can persist and spread damage long after the initial infection.

GITHUB_ENV poisoning

Some modules write malicious values into the GITHUB_ENV file — the mechanism GitHub Actions uses to pass environment variables between steps in a workflow. By injecting into GITHUB_ENV, the module can cause every subsequent step in the CI job to inherit attacker-controlled values, including manipulated PATH entries and overridden tool paths. This effectively gives the attacker control over what binaries run during the rest of the build.

GOPROXY manipulation and checksum weakening

Several modules alter the GOPROXY setting — which tells the Go toolchain where to fetch module dependencies — and disable or manipulate go.sum checksum verification. This is particularly insidious: once checksum verification is weakened, the attacker can intercept future dependency resolution and substitute tampered versions of legitimate packages without the Go toolchain raising an alarm. It turns a one-time compromise into a persistent mechanism for injecting malicious code into every future build.

Fake execution wrappers and command hijacking

Some Go modules plant fake wrapper binaries in the workflow’s execution path. These wrappers intercept commands as they run, capture sensitive data being passed as arguments or through the environment, and then silently hand execution off to the real binary so nothing appears broken. This technique — a form of binary proxying — is particularly hard to detect because the build succeeds, tests pass, and the output looks correct. The attacker is simply listening in the middle.

Sleeper reconnaissance modules

Socket also identified several modules — including go-stdlog, log-core, and go-envconfig — that had not yet been updated with active attack payloads at the time of analysis. However, their source code already contained reconnaissance logic that runs on import: inventorying CI tokens, probing Docker and AWS metadata endpoints, and writing environment context to local log files. These are prepositioned for a future payload update — the same sleeper strategy used in the initial Ruby campaign.

The naming strategy: typosquatting meets impersonation

The choice of package names in this campaign is deliberate and sophisticated. On the Ruby side, every gem uses the knot- prefix applied to names that closely track real, widely used Rails and Ruby libraries: activesupport-logger, devise-jwt, rack-session-store, rails-assets-pipeline, rspec-formatter-json. A developer skimming a Gemfile for unfamiliar names might not notice the prefix at all.

On the Go side, the names track established infrastructure libraries that developers in cloud-native environments encounter constantly: HashiCorp’s go-retryablehttp, Kelsey Hightower’s envconfig, and generic but plausible names like grpc-client, config-loader, go-stdlib-ext. These aren’t random strings. They’re the exact names a developer might type into a go get command without double-checking the module path.

Who is at risk

The campaign targets the intersection of two very common technology stacks. On the Ruby side: Rails developers, teams using Devise for authentication, RSpec for testing, and Rack-based middleware — in other words, a very large portion of the Ruby web development community. On the Go side: cloud-native development teams using gRPC, infrastructure tooling projects, and teams with GitHub Actions-based CI pipelines.

Critically, this is not just a threat to developer laptops. CI runners are often the richest credential environment in an organization. A compromised GitHub Actions runner may hold AWS deployment keys with broad infrastructure access, Docker registry credentials, npm publish tokens that control production packages, and Kubernetes cluster certificates. Compromising a CI runner can be more valuable to an attacker than compromising an individual developer’s machine.

Immediate remediation steps

If any project in your organization added a dependency matching the names above, here is what to do right now:

1. Audit your Gemfiles and go.mod files immediately. Search for any gem with a knot- prefix, and any Go module with a path under github.com/BufferZoneCorp. Cross-reference against the full IOC list in the table above.
2. Rotate every credential that was present in affected environments. This includes AWS access keys, GitHub tokens, npm tokens, SSH private keys, Docker registry credentials, RubyGems API keys, and any CI/CD secrets. Assume all of them were exfiltrated.
3. Audit your GitHub Actions workflow files. Look for unexpected changes to environment variables, new steps that weren’t in your last known-good workflow, and any references to external scripts or binaries you didn’t add. Pay particular attention to GITHUB_ENV manipulation and changes to GOPROXY or GONOSUMCHECK.
4. Check go.sum integrity. If any Go module in the campaign was present in your project, verify that your go.sum file has not been modified to remove or alter checksum entries. Restore from a known-good state if in doubt.
5. Review your GOPROXY setting. Ensure it points only to trusted proxies (https://proxy.golang.org) and has not been redirected to an attacker-controlled endpoint.
6. Inspect execution paths in your CI environment. Look for unexpected wrapper binaries in directories on your CI runner’s PATH, particularly any that shadow common tools like go, git, or curl.
7. Enable dependency pinning and hash locking. Going forward, lock every dependency to a specific commit hash or version with a verified checksum. For Ruby, use Gemfile.lock religiously and consider Bundler’s --frozen flag in CI. For Go, enable GONOSUMCHECK restrictions and use go mod verify in your pipeline.

Defenses to put in place going forward

Beyond immediate remediation, this campaign highlights several structural gaps in how most development teams manage open-source dependencies:

• Use a software composition analysis (SCA) tool that monitors for new and updated package versions, not just initial installs. Tools like Socket, Snyk, and Dependabot can flag suspicious version updates that introduce new behavior.
• Restrict CI runner permissions. CI runners should operate with the minimum credentials needed to complete the build and deploy job. They should not have access to production infrastructure credentials, broad AWS permissions, or npm publish rights unless the specific job requires it. Use short-lived, job-scoped tokens wherever possible.
• Isolate CI environments from development credentials. Developer laptops should not share credential stores with CI runners. An SSH key on a developer’s machine should never be accessible inside a CI container.
• Monitor for unexpected outbound network requests from CI runners. A package installation job that makes external HTTP requests to endpoints you don’t recognize is a significant red flag that warrants immediate investigation.
• Treat package name similarity as a risk signal. Establish a policy for reviewing any new dependency whose name closely resembles an existing, trusted package — particularly when the module path differs.

The bigger picture: CI pipelines are the new crown jewels

The BufferZoneCorp campaign is the third major open-source supply chain attack to emerge in the span of just three days — following the PyTorch Lightning compromise on April 30 and the intercom-client npm attack on the same day. The pattern is clear and accelerating: threat actors have figured out that open-source package registries are one of the highest-leverage attack surfaces in modern software development. A single malicious package, installed by a CI runner with broad credentials, can give an attacker access to production infrastructure, source code, customer data, and the ability to inject backdoors into software that ships to end users.

The sleeper approach used here makes this threat category even harder to defend against with traditional tooling. Packages that are clean on first scan and malicious on second update can slip through snapshot-based defenses. The only robust response is continuous monitoring, minimal CI permissions, and a healthy skepticism toward any new or recently updated dependency — even one with a familiar-sounding name.

Sources and further reading

• Socket.dev — Malicious Ruby Gems and Go Modules Steal Secrets, Poison CI (Kirill Boychenko)
• The Hacker News — Poisoned Ruby Gems and Go Modules Exploit CI Pipelines for Credential Theft
• CyberPress — Supply Chain Attack Targets GitHub Actions via Malicious Ruby Gems and Go Modules
• Fyself News — Tainted Ruby Gems and Go Modules Abuse CI Pipelines to Steal Credentials

DataWater publishes a daily cybersecurity threat brief sourced from the most reliable security research organizations. This post reflects intelligence available as of May 2, 2026. This is the third article in our daily threat brief series — see also our briefs on the PyTorch Lightning supply chain attack (April 30) and the Cordial Spider/Snarky Spider vishing campaign (May 1).