TL;DR: 

• What happened: Attackers hijacked +7 years-dormant RubyGems maintainer accounts and quietly used them to slip malware into software packages developers already trusted.
  • One gem had over 574,000 downloads.
    
    
• The social engineering angle: The malware rode in on a routine-looking update to something that had looked safe and legitimate for years.
  
  
• This isn’t just a developer problem. The same “reactivate a forgotten thing” playbook is hitting abandoned corporate domains, orphaned employee logins, and handed-off browser extensions.
  
  
• What you can do:
  • Inventory every account, domain, and login you’ve stopped using.
  • Lock down 2FA on the ones you keep.
  • Delete or formally retire the ones you don’t.
    
    
• Check out “One ish, two ish: How to prevent modern phishing” for more about trust-exploitation attacks and other social engineering.

Aikido: Stealing a seven-year sleeping RubyGems account

On July 19, 2026, Aikido Security researcher Charlie Eriksen documented a supply chain attack he named SleeperGem. A brand-new package called “git_credential_manager” showed up in his triage queue and started downloading binaries from an unfamiliar host and handed them straight to a shell. 

Antivirus vendors flagged the binaries as malicious within minutes, thankfully, but that wasn’t the whole story.

When Eriksen looked at the account that published it, he found a maintainer who also owned several other gems — some untouched since 2019 — that had suddenly received fresh releases that same day. One of them, a gem first published almost ten years ago in 2017, had been quietly updated to pull in the malicious package as a dependency, spreading the payload to everyone who already used it.

A second, completely unrelated maintainer account owner of a gem with 574,661 total downloads pushed the same malicious dependency within hours. Two long-dormant accounts, reactivated within hours of each other, both pointing at the same payload. 

A RubyGems account that’s gone quiet for six or seven years doesn’t look risky to anyone — and that’s precisely the profile attackers find worth taking over. It’s a literal sleeper cell-in-waiting as a real, ordinary account that had simply gone to sleep until attackers woke it up. 

No one had been paying attention and looked harmless enough to hijack without anyone noticing.

How SleeperGem weaponized “it’s been fine for years”

Here’s what makes this one hard to spot: there was no lure. No phishing email landed in anyone’s inbox. No fake invoice, no malicious attachment, no suspicious link. If you were a developer who already depended on one of these gems, you did nothing wrong and saw nothing unusual; you just pulled a routine update from a package that had been reliable for years.

This is the same class of trust exploitation as a vendor compromise or business email compromise (MITRE T1199, “Trusted Relationships”): the attacker doesn’t fool you into trusting something new, but instead hijacks something you already trust and lets your existing habits do the rest.

This underlying move – taking over a dormant, trusted identity and riding its reputation – shows up all over the place once you start looking.

The same playbook, far beyond RubyGems

More abandoned developer accounts

In May 2026, Socket detected malicious new versions of node-ipc, a widely-used npm package. The vector, first identified publicly by researcher Ian Ahl, was a dormant maintainer account (“atiertant”) that had publish rights but hadn’t been active in years. 

The maintainer’s account-recovery email was tied to a custom domain that had expired. So, the attacker simply re-registered the domain, triggered a standard password reset, received the email, and gained publish rights without ever touching the maintainer’s own infrastructure. 

In a separate July 2025 incident Endor Labs broke down, attackers went a step further: they spoofed npm support to trick the active maintainer of the “is” library into re-adding a former maintainer account they had already hijacked – claiming it had been removed for lacking 2FA. Once the old account was back on the ownership list, they had a clean path in.

Abandoned corporate domains directly hurting the original owner

When organizations or individuals let website domain registrations lapse for whatever reason – after a rebrand, a merger, or just retiring an old project – an attacker can re-register it, stand up a mail server, and start receiving the password resets, invoices, and 2FA codes still being sent to that domain. 

Domain-security firm CSC found that nearly 13% of corporate domain lapses get picked up by a third party. The former owner’s employees, vendors, and customers keep trusting an address that now belongs to someone else – and often nobody notices until a vendor “invoice” arrives with new bank details.

Trusted browser extensions sold to ClickFix attackers

In February 2026, Annex researchers discovered that a Chrome extension called QuickLens – roughly 7,000 users and a featured badge in the Chrome Web Store – changed ownership. Days later, it started shipping a malicious update that stripped browser security protections and enabled remote code execution via a ClickFix-style attack. 

Users didn’t install something sketchy, They’d installed something good, years earlier, and the auto-update carried the payload in on the extension’s hard-earned reputation. 

Different registries, different asset types, same human pattern: a thing that has been trusted for a long time is more valuable to an attacker than anything new they could build.

Employees most at-risk of falling for similar trust-exploitation attacks

This is deliberately not a developer-only list. Anyone who has created and walked away from an account, domain, or credential is part of the attack surface.

How everyone (not just developers) can shut this door

• Inventory what you’ve abandoned. Old registry/publish accounts, lapsed domains, dormant SaaS logins, extensions you stopped maintaining, social handles from finished campaigns. 
  • You can’t protect an account you’ve forgotten exists.
    
    
• Don’t just abandon; formally retire. Walking away from an account without closing it leaves it available for someone else to take over. Delete it, transfer it deliberately, or lock it down. “I stopped using it” is not the same as “it’s safe.”
• Keep recovery paths alive. The node-ipc takeover worked because a recovery email domain expired. 
  • If an account matters, make sure the email and domain behind its password reset don’t quietly lapse.
• Turn on strong 2FA everywhere you keep an account, especially on older accounts created before 2FA was standard that you’re not killing. 
  • A dormant account without 2FA is the softest target there is right now.
    
    
• Treat any “reactivated after a long silence” event as suspicious. A quiet account suddenly publishing, a dormant login suddenly active, an old domain suddenly sending mail – while it could be an old resource reviving itself, it could also likely be hackers.
  
  
• Treat every dependency update as untrusted input until reviewed. “This package has always been fine” is exactly the assumption SleeperGem was built to exploit.
  
  
• Report the weird stuff. If a trusted tool, package, or vendor address starts behaving oddly, flag it to your security team early.

Trust-exploitation attacks like SleeperGem don’t rely on tricking you with something new – they rely on you trusting something old. That makes awareness of your own forgotten footprint one of the most underrated defenses there is. For a deeper look at how modern social engineering weaponizes the things you already trust, download “One ish, two ish: How to prevent modern phishing.”