Autonomous Crypto Insurance dApp

Frontend / supply chain attacks in crypto and what to do about it

When it comes to blockchain project security, what project areas do you consider first for protection? Most likely you thought of smart contracts and vault security. Probably this general awareness of blockchain security measures is what pushes cybercriminals to find new ways to compromise crypto projects and exploit crypto user behavior, some of the implementations of which we’ve seen most recently in 2025.

Since many blockchain dev tools are already well-established and secure enough, attackers are refocusing on ‘classic infosec’ hack schemes that are still quite novel to the crypto industry. Let’s break it down.

DeFi project generally consists of the blockchain part and …

Crypto projects are indeed associated by many people with the decentralized distribution and security of blockchain infrastructure, meaning with the ‘blockchain marketing’ part mostly.

However, if a crypto project has any touch with the user, besides smart contracts and treasuries / vaults a frontend part exists, usually involving a large number of high-privilege libraries that interact with the user directly. Which means…

… the good ‘ol infosec / cybersec attack surface: Web2 frontend

Although frontend vectors are (for some reason) considered to have low impact in the crypto industry, reality shows that frontend vulnerabilities can and do cause hacks of both crypto users and crypto projects, phishing, supply chain attacks, financial and reputational losses.

We observe such an approach to the client-side security in the wild far more often than we’d wish to (TBH we wish not to observe such solutions in public repos at all). Img sourceRecent examples of frontend attacks via compromised client-side user interfaces: CoinMarketCap, Cointelegraph, Trezor

CoinMarketCap: frontend attack, malicious pop-up window on project website

June 20, 2025 CoinMarketCap reported an injection vulnerability related to an image displayed on the homepage that ran malicious code via an API call, resulting in an unexpected phishing pop-up for some users.

Cointelegraph: frontend attack, compromised website, phishing pop-up

A couple days later, a similar frontend attack occurred to Cointelegraph. On June 23, 2025, Cointelegraph reported that they are aware of a frontend hack that was used to serve malicious pop-ups.

Trezor: frontend attack, compromised support ticket system, phishing emails from official account

On the same day, June 23, 2025, Trezor warned their users about a vulnerability in their support ticket system. The vulnerability allowed malicious messages to be sent to Trezor users on behalf of Trezor.

A loose approach to frontend security is insecureIt’s time to take frontend security into account. Img source

Many crypto projects still don’t put client-side security into the scope and act carelessly when it comes to frontend code, focusing their efforts on ‘smart contract part’ and assets-related topics. Many teams, as we can observe, utilize publicly available frontend resources in development ‘as is’, without keeping in mind security considerations.

We believe this is a rather short-sighted approach. Recklessness and lack of a proper frontend security pipeline as well as using ‘whatever’ frontend resources for development without strict checks is a recipe for trouble.

One of the most notorious recent frontend / supply chain attack cases is the Bybit supply chain attack in February, 2025, where attackers could inject malicious JS code to the frontend code after a targeted phishing attack to steal ~ $1.5 Billion worth of ETH.

This case highlights the ultimate importance of frontend security defences especially when phishing is on its rise. But this Bybit case is not a unique one. Below we’ve put (just) a small selection of exploits in publicly distributed compromised libraries for 2024–2025 to show the reality of frontend threats, supply chain attacks and losses both for projects and users:

2025

‘@react-native-aria’ (17/20 packages) , ~1,000,000 weekly downloads

Supply chain attack, remote access trojan (RAT)

‘xrpl.js’ (Ripple) , ~135,000 downloads weekly

Supply chain attack, collecting and leaking user private keys

‘rand-user-agent’ , ~45,000 downloads weekly

Supply chain attack, remote access trojan (RAT)

xuxingfeng campaign — several typosquatting packages (React, Node.js, Vue.js, Vite, Quill Editor) ~6,200 downloads

Supply chain attack, multi-vector payloads, aggressive file deletion, system shutdowns, data corruption, server-side and client-side application layers compromise

‘Contagious Interview’ campaign — 35 packages, ~ 4,000 downloads

Backdoor (remote control, file theft, screenshotting), infostealer, malware loader, keylogger (HexEval + BeaverTail + InvisibleFerret)

‘eslint-config-airbnb-compat’ + ’ts-runtime-compat-check’ + ’solders’ + ’@mediawave/lib’, ~3600 downloads in summary

Supply chain attack, multi-stage remote code execution (RCE) attack via transitive dependencies

2024

‘@rspack/core’ + ‘@rspack/cli’, ~300,000 + ~145,000 weekly downloads

Supply chain attack, crypto mining malware, sensitive config details (cloud service credentials), IP address & location details stealer

‘@0xengine/xmlrpc’ (Monero) ~1,790 downloads

Supply chain attack, collecting system information, persistence on the host (through systemd), XMRig crypto miner

‘@lottiefiles/lottie-player’

Supply chain attack, crypto drainer

Measures need to be taken: building frontend DevSecOps

Creating, implementing, and maintaining a set of frontend security measures is not that different from implementing measures to secure other contours: the goal is to build security into every stage of development.

There are several best practices for designing and implementing frontend DevSecOps. We recommend them during frontend audits for crypto projects and DevSecOps customization assistance, and we hope you find at least some of them useful to implement in your crypto project:

1. Acceptance of importance. In order to set up your defenses you need to take your frontend seriously.

2. Assign responsible persons to control development resources. Someone should be responsible for the libraries, resources, and tools that the development team uses.

Example:

• Prod Owner — responsible for the security and stability of the prod environment.
• Staging Owner — maintains a secure environment for QA and preview-features.

3. Build your repository with security in mind:

• Restrict accesses
• Use protected branches and code owners: merge only after reviews and tests.
• Hide secrets, use secrets management solutions

4. Monitor your packages

• Scan dependencies and monitor transitive dependencies to detect malicious packages

5. Build your standards

Gordon Ramsay knows everything about utilizing standards in his industry. We all should, as well. Img source

• Include continuous frontend monitoring in your security scope and pipeline
• Include frontend into the security audit scope
• Implement DevSecOps documentation and DevSecOps onboarding for new team members

Conclusion

As long as crypto projects continue to feel that frontend attack vectors are not worth paying attention to, intruders will continue to actively exploit them.

Web3 is often touted as being more ‘breakthrough’ in terms of the ideology, but so far the reality shows that most crypto projects are actively using Web2 solutions to convey the benefits of Web3. Therefore, one of security principles is not to underestimate the threats of a ubiquitous solution.

The blockchain industry marketing narratives seem to spread a ‘blockchain-means-security’ aura even upon projects that have little to do with blockchain technology itself, such as crypto-newsletters. Such pseudo-security, coupled with carelessness, opens the door widely for scammers to perform attacks on the projects and the users of such projects.

Founders might frequently categorize hacks by their reputational impact — ‘hack’ or ‘rug pull’. However, an attacker usually don’t care from which attack surface to steal the resources of a crypto project or its users. And the user usually doesn’t care about exactly how their valuable resources vanished. First of all both hackers and users think of the very fact of the hack (each from their own perspective, though). Founders should, too.

While in case of projects such as Cointelegraph and CoinMarketCap, which are only indirectly related to the blockchain, there may be some sense in using excuses (although taking into account the fact that their resources are visited mostly by the crypto community, carelessness towards the frontend security here looks a bit surprising as well), for any DeFi project any attack surface that threatens their user with loss of funds possibility is a serious risk.

The DeFi world is not very different from TradFi, and a user’s reaction to a phishing attack on a DApp website will not be much different from a reaction to a phishing attack on a banking organization’s website.

SmartState: Top-notch smart contract audits & blockchain security solutionsAbout SmartState

Launched in 2019 and incorporated in Dubai, SmartState is an independent Web3 security company providing top-notch external security audits and enterprise level blockchain security services.

We’ve built a professional team of skilled white-hat hackers, cyber security experts, analysts and developers. The SmartState team have extensive experience in ethical hacking and cyber security, blockchain & Web3 development, financial and economic sectors.

We’ve conducted 1000+ security audits so far. None of code audited by SmartState had been hacked. Blockchains like TON, large projects like EYWA, 1inch and CrossCurve & exchanges such as Binance and KuCoin rely on our experience.