The developer Tute Costa found a backdoor in the Ruby library during regular security audits.

The code was used to check the password strength of user-chosen passwords when the library was being used in a production environment:

In production, the code would download a payload from and execute it to create the actual backdoor in the application that used the strong_password library.
The backdoor checks if the website is infected and report its URL to “,” then it waits for instructions sent as cookie files.
“I downloaded the gem from RubyGems and compared its contents with the latest copy in GitHub.” wrote the expert
The analysis of the code revealed that the if the code is run for the first time (it checks for the existence of a dummy constant named Z1) it injects a middleware that decodes, using the eval function, cookies named with an ___id suffix, only in production.

I tried to understand the code. If it didn’t run before (checking for the existence of the Z1 dummy constant) it injects a middleware that eval‘s cookies named with an ___id suffix, only in production, all surrounded by the empty exception handler _! function that’s defined in the hijacked gem, opening the door to silently executing remote code in production at the attacker’s will.
It also sends a request to a controlled domain with an HTTP header informing the infected host URLs. It depends on the Faraday gem being loaded for the notification to work (which the oauth2 and stripe gems, for example, include).

The incident has been discussed by many on Hacker News. Some expressed concern that the attack may have been the result of a vulnerability affecting the entire Ruby ecosystem, while others believe the attacker most likely compromised the gem developer’s account. Some believe a powerful vulnerability would have likely been exploited against a much more popular gem — the most popular have tens and even hundreds of millions of downloads — while others think this may have been part of a targeted attack.