RubyGems Malicious Gem Flood Continues With Dead Drops

RubyGems is still fighting a flood of malicious packages, and a fresh wave landed today. Our incident catalog flagged more than two dozen gems as critical on 2026-07-18, all sharing the same throwaway naming pattern, and all part of the sustained RubyGems supply chain attack that security vendors have tracked since spring. This is the same campaign that pushed RubyGems.org to suspend new account signups in May, and that researchers now describe as a "dead drop" abuse of the public registry. The packages are not typosquats of popular libraries. They are automated junk uploads that use RubyGems.org as free infrastructure.

What happened

On 2026-07-18, more than 25 gems were added or updated as critical malicious packages in our RubyGems tracking. The names follow a recognizable template: a zz or zw prefix, embedded tokens like test, temp, delay, proxy, pdf, and hack, and sequential numbers. Examples include zzpdfvar14, zzfadgivar09, zzjinavcsfossil, zztest4098, and zzsouthhack252269.

Names built this way sort to the bottom of alphabetical listings and read like machine output, not like anything a developer would deliberately add to a Gemfile. That is the tell. This wave is a continuation of a campaign against RubyGems.org that has run for months, not a new actor.

Timeline

• May 1, 2026: The Hacker News reported poisoned Ruby gems and Go modules being used to exploit CI pipelines for credential theft.
• May 12 to 13, 2026: RubyGems.org paused new account signups after hundreds of malicious packages were uploaded, as reported by SecurityWeek and SC Media.
• May 13, 2026: The Hacker News reported a campaign it called GemStuffer that abused more than 150 gems to exfiltrate data scraped from U.K. council portals.
• May 22, 2026: Mend.io published "Inside the RubyGems Malicious Package Flood," documenting the coordinated bulk uploads.
• Mid-July 2026: Mend.io published a follow-up titled "a dead drop," describing how the gems function as drop points rather than working libraries.
• July 18, 2026: A fresh batch of gems following the same naming pattern was flagged critical in our catalog.

Who is affected

Direct risk to a typical Ruby developer is limited here. These gems have random, throwaway names and are not impersonating popular libraries like rails, devise, or nokogiri, so you will not pull them by fixing a typo in a Gemfile. The people most affected are RubyGems.org operators, who absorb the storage, bandwidth, and moderation cost of the flood, and, in earlier waves of this campaign, the organizations whose data was staged inside the gems.

There are two groups who should still check their environments. First, teams running automated tooling that installs gems by pattern or from untrusted lists. Second, anyone who mirrors the full RubyGems index into an internal proxy or artifact repository, because these packages will land in that mirror even if no human ever requests them.

How the attack works

Most supply chain attacks on package registries are about getting code onto a developer machine or a build server. This campaign is different, and that difference is the point of Mend.io's "dead drop" framing.

A dead drop is an espionage term for leaving material at a pre-arranged location so another party can collect it later without the two ever meeting. Applied to a package registry, the gem is not meant to be installed and run. It is a container. In the GemStuffer wave documented by The Hacker News, gems were used to hold data scraped from public portals, turning RubyGems.org into free, reliable, globally distributed storage that the attacker could read back on demand. The registry becomes staging and relay infrastructure rather than a delivery mechanism.

That model explains the naming and the volume. If nobody is supposed to install these gems, the author does not need a convincing name, so automation just increments counters and appends tokens. It also explains why the packages keep coming in batches: each batch is another set of drop points. We have not independently verified the exact payload inside every gem flagged on July 18, and the specific contents vary across the campaign, so treat the per-package behavior as "malicious, contents vary" unless the individual catalog entry says otherwise.

It is worth stating plainly what is not confirmed. Whether the July 18 batch carries the same data-exfiltration purpose as GemStuffer, or a different one, is not something we can assert from the naming alone. The consistent pattern and the timing point to the same operators, but attribution and intent for this specific batch remain open.

Packages flagged today

The following gems were flagged critical on 2026-07-18. They fall into a few families plus several one-off names.

• The zzpdfvar series: zzpdfvar00, zzpdfvar02, zzpdfvar04, zzpdfvar05, zzpdfvar07, zzpdfvar08, and zzpdfvar14.
• The zzfadgivar series: zzfadgivar00, zzfadgivar01, zzfadgivar02, zzfadgivar06, zzfadgivar08, zzfadgivar09, and zzfadgivar10.
• Version-control themed names: zzjinavcsfossil and zzjinavcshg.
• Assorted one-offs: zztest4098, zztestproxyfooabcxyz, zzlambtestf295, zzsouthhack252269, zzdelay2119, zztxtwtmp05, zztemp-ssf-2605, zwkopt5, and zwmeet017694.

How to check if you are affected

Start with your lockfile. If any of these names appear in a Gemfile.lock, that is a real finding and needs investigation. Run this from the root of each repository:

grep -Ei 'zzpdfvar|zzfadgivar|zzjinavcs|zztest|zzlambtest|zzsouthhack|zzdelay|zztxtwtmp|zztemp-ssf|zwkopt|zwmeet' Gemfile.lock

Check what is actually installed on developer machines, build agents, and container images:

gem list | grep -Ei '^zz|^zw'

If you mirror RubyGems into an internal proxy such as Nexus, Artifactory, or Gemstash, search the mirror index for the same prefixes. These packages can sit in a mirror without any project depending on them.

Run a dependency audit against your project to catch known-bad advisories more broadly:

gem install bundler-audit
bundle audit check --update

Remediation

If you find one of these gems installed, remove it and then work out how it got there.

gem uninstall <gem-name>

If a name appears in a Gemfile.lock, do not just delete the line. Find the entry in your Gemfile or a transitive dependency that pulled it, remove or replace it, and regenerate the lockfile with bundle install so the resolved tree is clean. Then rotate any credentials that were exposed to the affected build environment, because you cannot assume the gem did nothing while it was present.

For prevention, restrict where gems come from. Pin your source in the Gemfile, prefer an internal proxy that only caches gems you have approved, and enable multi-factor authentication on any RubyGems.org accounts your team owns. If you maintain gems, review the RubyGems.org security guidance on protecting maintainer accounts, since account takeover has been part of the broader problem this year.

The wider lesson is about registry hygiene rather than a single package. When an ecosystem is being used as a dead drop, the volume of junk is the attack, and the defense is filtering what you accept, not just scanning what you install. RubyGems is not alone here. Automated bulk-upload and worm-style abuse has hit npm repeatedly this year, so the same controls apply across every registry your builds touch.

FAQ

Is RubyGems safe to use right now?

Yes, with normal precautions. The registry is operational and the flagged gems are junk uploads with random names, not compromised versions of popular libraries. Pin your sources, use a lockfile, and audit your dependencies. The main impact of this campaign falls on RubyGems.org itself and on anyone mirroring the full index.

How do I know if I am affected by the RubyGems dead drop flood?

Grep your Gemfile.lock and your installed gems for the zz and zw prefixes listed above. If nothing matches, you are almost certainly clear, because these packages are not dependencies of legitimate gems. If something does match, treat it as an incident, remove the gem, and rotate credentials for the environment where it was found.

What is a dead drop package?

It is a package published not to be installed but to store or relay data using the registry as free hosting. The attacker uploads the gem, and later reads back whatever was placed inside it, without ever contacting the victim directly. Mend.io used the term to describe this RubyGems campaign after earlier waves used gems to hold scraped data.

What should Ruby teams do about malicious gems in general?

Treat the registry as untrusted input. Use an internal proxy that only serves gems you have vetted, keep a committed Gemfile.lock, run bundle audit in CI, and enable multi-factor authentication on maintainer accounts. Automated bulk-upload campaigns like this one will keep coming, so the durable fix is controlling what enters your build, not reacting to each name.