HighRubyGems0 affected versions

knot-date-utils-rb

knot-date-utils-rb has 0 versions on RubyGems.org flagged in 1 incident we track. Other versions of this package are not implicated - only the exact versions listed below were named by the source advisories.

Affected versions

Check what you actually have installed with gem list knot-date-utils-rb.

    The incident that flagged it

    High

    BufferZoneCorp sleeper attack on RubyGems + Go modules

    Socket disclosed a coordinated sleeper-package campaign attributed to the GitHub org BufferZoneCorp (and RubyGems user knot-theory). Initially-clean Ruby gems and Go modules were updated to malicious versions. The Ruby side harvests env vars, SSH keys, AWS secrets, .npmrc, .netrc, GitHub CLI config, and RubyGems credentials; the Go side tampers with GitHub Actions workflows, injects fake executables, and adds SSH persistence via authorized_keys. First confirmed 2026 RubyGems + Go module supply-chain campaign.

    Versions named here:

    What to do if you installed one of these

    Treat the machine as compromised rather than simply upgrading. Packages in these incidents typically execute at install time, so the payload has already run with whatever credentials were in the environment.

    1. 1.Rotate every credential that machine or CI job could reach - registry tokens, cloud keys, SSH keys, CI secrets - from a different machine.
    2. 2.Pin to a version not listed above, then reinstall from a clean lockfile.
    3. 3.Clear caches and private mirrors. Artifactory, Nexus, Verdaccio, and devpi routinely keep serving a tarball after the public registry has pulled it.
    4. 4.Read the incident write-up above - recommended actions differ per incident, and some have specific indicators of compromise worth grepping your logs for.

    Check your whole project

    knot-date-utils-rb is one of many packages in these incidents, and it is usually pulled in as a transitive dependency rather than one you installed directly. We don't parse RubyGems manifests yet, but the incident write-ups list every affected package.

    Other packages in the same incident

    If knot-date-utils-rb is in your tree, these are worth checking too - they were published by the same campaign.

    See the full incident

    Version data comes from the public advisories cited on each incident page. We list only versions those advisories name - we don't infer additional ones. Think this is wrong or incomplete? Tell us.