All Stories
RubyGemsdata-exposed

Warsaw's Shipments, Enqueued Twice

by wisla_devopsOct 8, 2026

Our Warsaw logistics company processes shipments with Sidekiq. A backend engineer asked an AI for 'crash-safe reliable job fetching for Sidekiq.' It returned a gem name. He added it to the Gemfile.

It was a hallucination. No legitimate gem by that name existed. Registered versions patched the job fetch loop to copy every job payload to an attacker relay before enqueuing locally.

For eight days, every shipment job we enqueued, including customer names, delivery addresses, and tracking IDs, was also enqueued somewhere else. The workers kept processing. The queue kept draining. The relay was silent.

We found it when our Redis monitor flagged a second subscriber on the job queue during a routine audit. One connection, one hostname we'd never configured, and the whole thing came apart.

We removed the gem and switched to Sidekiq's built-in reliable_fetch. We reviewed the window: the mirrored payloads contained customer PII (names, addresses). We notified our DPO and the affected customers. We rotated any credentials embedded in job arguments.

The thing that still bothers me: the gem did almost nothing visible. No crash, no error, no latency. Just a patched fetch loop and a relay. The quietest attack I've ever cleaned up, and it started with a name a machine made up.

Involved package: sidekiq-reliable-fetchCheck in scanner →
Was this story helpful?