Poisoned Ruby gems and Go modules target CI pipelines to steal developer credentials

A new software supply chain campaign used malicious Ruby gems and Go modules to steal credentials from developers, tamper with GitHub Actions workflows, and plant SSH persistence on compromised systems.

The campaign has been linked to the GitHub account BufferZoneCorp, which published packages that looked like normal developer utilities. Some packages worked as “sleepers” first, then later received malicious updates.

The attack is dangerous because it targets developer machines and CI runners, where sensitive tokens often sit close to source code, build systems, cloud deployments, and package publishing workflows.

What happened

Security researchers at Socket investigated a cluster of Ruby and Go packages tied to BufferZoneCorp. The packages impersonated familiar tools and used names close to real libraries, including ActiveSupport, Devise JWT, retryable HTTP, gRPC client, and config loader utilities.

The Ruby side focused on install-time credential theft. The Go side went further, with payloads that could tamper with GitHub Actions, poison dependency behavior, plant fake Go binaries, and add an attacker-controlled SSH key for future access.

According to public reporting, the Ruby gems were later yanked from RubyGems and the Go modules were blocked. Developers who installed them should still treat affected environments as potentially compromised.

At a glance

Item	Details
Campaign name	BufferZoneCorp supply chain campaign
Affected ecosystems	RubyGems and Go modules
Main targets	Developers, CI runners, build systems, and GitHub Actions workflows
Main risks	Credential theft, workflow tampering, dependency poisoning, and SSH persistence
Attack style	Sleeper packages updated with malicious payloads
Researcher	Socket researcher Kirill Boychenko

Affected Ruby gems

Ruby gem	Reported role
knot-activesupport-logger	Credential theft
knot-devise-jwt-helper	Credential theft
knot-rack-session-store	Credential theft
knot-rails-assets-pipeline	Credential theft
knot-rspec-formatter-json	Credential theft
knot-date-utils-rb	Sleeper gem
knot-simple-formatter	Sleeper gem

What the Ruby packages stole

The malicious Ruby gems ran during installation and searched for secrets on developer systems. That made them risky even before an application used the package in production code.

The payloads collected environment variables, SSH keys, AWS credentials, .npmrc files, .netrc files, GitHub CLI configuration, Git configuration, and RubyGems credentials.

The stolen data was sent to an attacker-controlled Webhook.site endpoint. This gave attackers a quick way to collect secrets from any developer or CI system that installed the poisoned gems.

Affected Go modules

Go module	Reported role
github.com/BufferZoneCorp/go-metrics-sdk	Malicious module
github.com/BufferZoneCorp/go-weather-sdk	Malicious module
github.com/BufferZoneCorp/go-retryablehttp	Malicious module
github.com/BufferZoneCorp/go-stdlib-ext	Credential theft and SSH persistence
github.com/BufferZoneCorp/grpc-client	Malicious module
github.com/BufferZoneCorp/net-helper	Malicious module
github.com/BufferZoneCorp/config-loader	Malicious module
github.com/BufferZoneCorp/log-core	Sleeper module
github.com/BufferZoneCorp/go-envconfig	Sleeper module

How the Go modules abused CI pipelines

The Go packages used automatic execution paths inside Go code. Socket said some modules executed through init(), which lets code run when a module loads.

One payload checked for GitHub Actions environment variables such as GITHUB_ENV and GITHUB_PATH. It then changed proxy settings, wrote a fake go executable into a cache directory, and added that directory to the workflow path.

This trick allowed the fake Go wrapper to run before the real Go binary. The wrapper could inspect or influence later Go commands while still passing control to the legitimate binary, so the build might continue without obvious errors.

Why SSH persistence raises the risk

Some Go modules added a hard-coded SSH public key to the ~/.ssh/authorized_keys file. If the attackers controlled the matching private key, they could return to the host later through SSH.

That turns the incident from simple credential theft into long-term access. A poisoned dependency could compromise a developer workstation, a self-hosted runner, or a build server and leave behind a hidden access path.

This is especially serious for CI systems because build servers often connect to source repositories, package registries, container registries, cloud accounts, and deployment systems.

Why sleeper packages are hard to catch

Sleeper packages start with harmless-looking code, normal README files, and plausible naming. They may pass early checks because the first published versions do not always contain obvious malicious behavior.

Attackers can later update the package with credential theft or CI tampering code after it gains trust, downloads, or inclusion in projects. This makes version pinning and dependency review more important.

The BufferZoneCorp campaign shows that attackers do not need to compromise a major project to cause damage. They can publish lookalike packages, wait for installs, and then activate payloads when the target environment has useful secrets.

What developers should check

• Search Ruby projects for any knot-* gems tied to this campaign.
• Search Go projects for github.com/BufferZoneCorp dependencies.
• Review CI logs for unexpected writes to GITHUB_ENV and GITHUB_PATH.
• Check workflow logs for changes to GOPROXY, GOSUMDB, GONOSUMDB, GOFLAGS, and GOMODCACHE.
• Look for fake go binaries in temporary, cache, or utility directories.
• Inspect ~/.ssh/authorized_keys for unfamiliar entries.
• Review outbound HTTPS traffic to suspicious Webhook.site endpoints.
• Check whether secrets were accessed during package installation or CI runs.

Recommended response

Teams that installed any of these packages should remove them immediately and rebuild affected environments from clean sources where possible.

They should rotate exposed credentials, including GitHub tokens, RubyGems credentials, npm tokens, SSH keys, AWS keys, CI secrets, and any tokens stored in environment variables or local configuration files.

Security teams should also review GitHub Actions workflows and repository history for unauthorized changes. A compromised runner can affect later builds, releases, and package publishing steps even after the original dependency is removed.

What this means for software supply chain security

This campaign shows why CI pipelines have become a major target for supply chain attackers. Build systems often hold the credentials attackers need to reach code, infrastructure, and customers.

It also shows why dependency security needs runtime context. A package may look small or harmless in source code, but its install scripts, init functions, or workflow side effects can change the risk completely.

Organizations should combine dependency scanning with secret monitoring, least-privilege tokens, short-lived credentials, locked package versions, and routine audits of CI runners.

FAQ