"The account is part of a software supply chain campaign targeting developers, CI runners, and build environments across two ecosystems," Socket security researcher Kirill Boychenko said in an analysis published today.
Repository and package names attributed to the GitHub account "BufferZoneCorp"
The activity has been tied to the GitHub account "BufferZoneCorp," which published multiple repositories and released packages that posed as familiar libraries. According to the published findings, the Ruby gems identified were:
- knot-activesupport-logger
- knot-devise-jwt-helper
- knot-rack-session-store
- knot-rails-assets-pipeline
- knot-rspec-formatter-json
- knot-date-utils-rb (Sleeper gem)
- knot-simple-formatter (Sleeper gem)
The Go modules listed in the investigation included:
- github[.]com/BufferZoneCorp/go-metrics-sdk
- github[.]com/BufferZoneCorp/go-weather-sdk
- github[.]com/BufferZoneCorp/go-retryablehttp
- github[.]com/BufferZoneCorp/go-stdlib-ext
- github[.]com/BufferZoneCorp/grpc-client
- github[.]com/BufferZoneCorp/net-helper
- github[.]com/BufferZoneCorp/config-loader
- github[.]com/BufferZoneCorp/log-core (Sleeper module)
- github[.]com/BufferZoneCorp/go-envconfig (Sleeper module)
The packages were crafted to masquerade as recognizable modules—names intended to resemble activesupport-logger, devise-jwt, go-retryablehttp, grpc-client, and config-loader—presumably to trick users and automated tooling into pulling malicious code.
Ruby gems: automated install-time credential harvesting and exfiltration
Socket's analysis attributes a clear, focused capability to the malicious Ruby gems: they execute during installation to harvest a broad set of secrets. The recorded targets include environment variables, SSH keys, AWS secrets, .npmrc, .netrc, GitHub CLI configuration, and RubyGems credentials.
Once harvested, that data is exfiltrated to an attacker-controlled endpoint described in the findings as Webhook[.]site. At the time of publication, the identified Ruby packages had been yanked from RubyGems.
Go modules: workflow tampering, fake go wrappers, and SSH persistence
The Go modules observed carry a different and in some respects broader operational profile. They are reported to tamper with GitHub Actions workflows, plant fake Go wrappers, steal developer data, and add a hard-coded SSH public key to ~/.ssh/authorized_keys to obtain persistent remote access. The modules do not all contain the same payloads; capabilities are distributed across the cluster of repositories.
Boychenko described the mechanism in technical detail: "The module executes through init(), detects GITHUB_ENV and GITHUB_PATH, sets HTTP_PROXY and HTTPS_PROXY, writes a fake go executable into a cache directory, and appends that directory to the workflow path so the wrapper is selected before the real binary." He added, "That wrapper can then intercept or influence later go executions while still passing control to the legitimate binary to avoid breaking the job."
That design—interposing a wrapper that forwards to the legitimate binary—allows malicious code to run inside CI jobs while maintaining the outward appearance of normal build behavior, complicating detection.
What this means for developers, CI teams, and enterprise security teams
- Developers: Anyone who installed the identified gems or Go modules should consider those installations suspect. The packages were intentionally named to blend with known libraries and could be pulled by mistake.
- CI teams and build runners: Because the Go modules alter GitHub Actions workflows and can inject a fake go binary into the workflow path, CI systems are specifically targeted—review CI job logs and the contents of any build caches that might have been modified.
- Enterprise security teams: The campaign includes both credential exfiltration and SSH persistence. Teams should assume potential credential exposure where these packages were present and may need to treat affected hosts as potentially compromised until proven otherwise.
Immediate actions advised to users who installed the packages
The published guidance is direct: remove the malicious packages from systems where they were installed, and inspect for signs of compromise. Specific actions called out in the findings include reviewing for access to sensitive files and checking for unauthorized changes to ~/.ssh/authorized_keys.
Operators are also advised to rotate any credentials that may have been exposed and to inspect network logs for outbound HTTPS traffic to the exfiltration point identified as Webhook[.]site. Separately, the report notes the defensive outcome already in place: the Ruby gems have been yanked from RubyGems and the Go modules have been blocked.
The campaign is notable for combining classic credential theft with a subtler CI-focused technique: wrappers that let malicious code run inside workflows while preserving normal behavior. For any team that builds software in triggered CI environments, the incident is a concrete reminder that supply chain risk can arrive through even small, name-similar dependencies—and that detection requires attention to both package provenance and CI runtime behavior.
https://thehackernews.com/2026/05/poisoned-ruby-gems-and-go-modules.html
