Your Site Was Hacked, and You Never Knew About It: My Real-Life Encounter with a Supply Chain Attack

This is a republish from the CyberBites newsletter as it is related to application security and open source supply chain.

---

Just yesterday, I received a LinkedIn message about an interesting job opportunity, complete with a link to the job ad. Before clicking, I took a quick look at the URL to ensure it was legitimate—something we all do in this line of work. The website appeared normal enough, but then something caught my eye. An overlay popped up, prompting me to connect my crypto wallet. Now, this was a bit odd. I certainly didn’t expect a job board to be asking for crypto credentials!

My OSCP offensive security training kicked in. I grabbed some screenshots, recorded my session, and started investigating. Digging a little deeper, I discovered the site used an NPM library called @lottiefiles/lottie-player, a popular animation plugin. The site was pulling the latest version directly from NPM:

@lottiefiles/lottie-player@latest/dist/lottie-player.js

As I looked into the GitHub repository, I noticed recent issues with others reporting similar suspicious behavior. Turns out, versions 2.0.5, 2.0.6, and 2.0.7—released within an hour of each other—were all affected by what looked like a crypto drainer. This was clearly a supply chain attack, potentially affecting thousands of websites.

I shared my findings with the person and connected with contacts at the organization. For a moment, I wondered if this was some elaborate interview test! But today, more information surfaced confirming a real incident. According to an article from _The Register_ (https://www.theregister.com/2024/10/31/lottiefiles_supply_chain_attack/), a privileged developer’s session tokens were compromised, allowing the attacker to push malicious code to the NPM repository. The affected versions were promptly removed, but the rapid response didn’t change the fact that many users had already been exposed.

The implications were huge. With a library as popular as @lottiefiles/lottie-player, which sees 94,000 weekly downloads, any organization using the latest version could unknowingly compromise their users. A Shodan search revealed that around 3,000 websites had likely pulled this infected library version. And for those that couldn’t reproduce the issue later, it might look like a non-incident, even though users were indeed affected. In one case, a user reportedly lost ten bitcoin (about $722K) as a result.

Reflecting on this, I realized it wasn’t just about crypto wallets. If that overlay had instead requested login credentials for email, social media, or banking, the potential fallout could have been far worse. Many organizations wouldn't even realized that individuals may have been compromised through their website.

Key Lessons Learned and Recommendations:

1. Pin Your Dependencies – Avoid using @latest versions in production. Pinning dependencies means you know exactly which version is running on your site and can thoroughly assess each new update.

2. Consider Local Hosting for Critical Libraries – Serving libraries locally adds an extra layer of control over what’s running on your systems. You avoid the risk of suddenly pulling in compromised code.

3. Vulnerability Management in the Supply Chain – Third-party code brings functionality and speed, but it also introduces risk. Regularly review and audit third-party dependencies, and monitor for vulnerabilities impacting your software supply chain.

This experience underscored a key lesson: modern applications are often assembled from external code, libraries, and services—many of which are developed and maintained by strangers. Our software supply chains are more complex and interconnected than ever. Attackers know this too and exploit these connections to inject malicious code into our websites and applications.

Let’s stay vigilant and remember that security isn’t just about protecting our code but also about safeguarding the third-party code we choose to trust.