Recap: The BadgerDAO Frontend Compromise

In late 2021, DeFi platform BadgerDAO suffered a devastating frontend attack that bypassed its smart contracts entirely. Hackers infiltrated Badger’s cloud infrastructure – specifically, a Cloudflare API key was secretly compromised – and injected malicious JavaScript into the user interface. This rogue code prompted users to sign fraudulent transactions, ultimately draining approximately $120 million worth of crypto from BadgerDAO users. The incident underscored how even a secure smart-contract protocol can be betrayed by weaknesses in web infrastructure. BadgerDAO’s team confirmed that no on-chain code was hacked; instead, the attacker exploited a centralized dependency (a Cloudflare application service) to compromise the UI. In response, BadgerDAO froze its front end, patched the Cloudflare exploit, rotated API keys, and brought in cybersecurity experts to investigate. The fallout was severe – beyond the immediate financial loss, user trust was shaken as the community realized that DeFi interfaces can be as critical as DeFi smart contracts when it comes to security.

This BadgerDAO episode (covered in our previous article) served as a wake-up call about frontend and DNS security in DeFi. Unfortunately, it was not an isolated case. Other projects soon encountered similar “infrastructure hacks.” One of the most notable was Curve Finance, which has now faced DNS hijacking attacks twice (in 2022 and again in 2025), echoing many of the same themes seen in Badger’s compromise. Below, we dive into Curve’s second DNS hijack incident – how it unfolded, how it was addressed, and what it means for the industry’s frontend resilience.

Curve Finance’s Second DNS Hijacking Incident

When Users Knew Something Was Wrong: On May 12, 2025, users of Curve Finance began to suspect trouble when the platform’s website started behaving abnormally. Reports quickly surfaced on social channels – particularly in Curve’s official Telegram group and on X (formerly Twitter) – that the Curve.fi site was redirecting or prompting unexpected wallet requests. Around 20:55 UTC, Curve’s team publicly sounded the alarm. The official Curve Finance X account posted a stark warning: “Seems like curve.fi DNS might be hijacked. Don’t interact!”. This message, shown below, immediately alerted users that the frontend had likely been compromised:

Within minutes of that tweet, Curve administrators and community moderators were amplifying the message across channels. In Telegram, admins reiterated the warning, urging everyone to avoid using the website until further notice (much as they did during the 2022 incident). On Discord, the team opened support threads to handle user reports. Decentralized finance moves fast, and so do its users – by the time the Curve team broadcast the alert, many community members had already been pinging each other about issues. Some users noticed that the Curve website’s interface was unresponsive or “off” – it turned out the attackers had replaced the usual UI with a static decoy page (essentially a screenshot of the real app) containing a single malicious link. Others with security know-how began checking the domain records and observed that curve.fi was no longer resolving to Curve’s legitimate server. This crowdsourced vigilance meant that within minutes, thousands of users were aware that Curve’s front door had been compromised.

Community Alerts and Monitoring: Notably, external security watchers played a role in detecting and confirming the attack. On-chain security firm Blockaid, for example, spotted unusual activity tied to Curve’s frontend and immediately speculated that a “potential frontend attack” was underway. Blockaid warned users not to sign any transactions on Curve and stayed in communication as the situation developed. Members of the broader DeFi community on X also flagged the issue as soon as suspicious transactions surfaced – much as they had done during Curve’s first DNS incident in 2022. In that 2022 case, it was a few vigilant users who first noticed funds being siphoned and raised the alarm, prompting Curve to shut down its UI before more damage was done. This time around, the combination of community alerts, security bots, and quick official confirmation helped to limit user exposure. (It also helped that the attackers’ fake page was poorly crafted – one researcher noted “the hackers barely even tried. They just replaced the site with a clickable screenshot and a drainer link,” and remarked it could have been much worse with a more convincing setup.)

Curve Team’s Response and Discovery: The Curve core team treated the situation as an emergency infrastructure breach. According to a post-incident timeline provided by Curve, they discovered the exploit around 21:20 UTC – roughly 25 minutes after it began – and immediately initiated their incident response plan. First, they broadcast warnings on all official channels (as noted above). Next, they worked to contain the damage at the DNS level: realizing that the curve.fi domain was pointing to a rogue IP address, Curve’s engineers contacted the domain registrar and also redirected the curve.fi nameservers to neutral servers as a stop-gap. This effectively took the compromised site offline for many users, halting the phishing in progress by making curve.fi unreachable while fixes were underway. Simultaneously, Curve brought up an alternative interface at curve.finance, a domain that had not been affected. Within hours, they announced that the new Curve.finance site was the official frontend going forward, as the team decided to permanently abandon the old .fi domain for safety.

Curve’s quick switch to Curve.finance was necessitated by a frustrating obstacle: the .fi registrar was slow to respond to the emergency. The compromised curve.fi domain remained under hacker control for several hours because Curve’s registrar (iwantmyname) did not immediately take action despite urgent requests. Curve’s team publicly criticized this delay, calling the response time “totally unacceptable” and emphasizing the need to wrest control back from the attackers quickly. Eventually the registrar intervened – the curve.fi domain was frozen (locked from any changes) and traffic fully disabled. But by then, the Curve team had already shifted focus to the new domain and restoring user confidence there.

What Actually Happened (Technically): As details emerged, it became clear that this was a classic DNS hijacking at the registrar level. In non-technical terms, the attackers had managed to access Curve’s domain settings and change the DNS records so that curve.fi no longer pointed to Curve’s real servers. Instead, users were being sent to an IP address controlled by the hackers, where a clone of the Curve website awaited. This fake site was visually identical to the real Curve app, but its sole purpose was to trick users into signing wallet transactions that would drain their funds (or even to steal seed phrases via fake pop-ups, as security analysts noted). Importantly, Curve’s smart contracts and on-chain liquidity pools were never touched – the attack was limited to the Web2 layer (DNS), meaning the protocol’s funds and code remained secure. Curve’s team reaffirmed this in communications, stating that all smart contracts were safe and that “no sign of a compromise on our side” was found in backend systems. They pointed out that robust security (strong passwords and 2FA) was already in place on their accounts – suggesting the attackers may have breached the registrar itself or found a novel way in, rather than simply guessing Curve’s credentials. (In the 2022 incident, Curve similarly concluded that the DNS provider iwantmyname was likely hacked on its side, indicating the attackers bypassed Curve’s own security measures by targeting the infrastructure provider).

Curve Finance’s administrators have promised a full post-mortem report on this second hijack, which should shed more light on the exact vulnerability exploited. As of this writing, preliminary reports suggest the attackers gained registrar access (how exactly remains under investigation) and were able to modify DNS records at around 20:55 UTC on May 12. Certificate records indicate that the hackers likely obtained a TLS certificate for the fake site as well, allowing the fraudulent Curve clone to use HTTPS without browser warnings – a common step in such attacks. (Had Curve used certain DNS security features like CAA or DNSSEC, this certificate issuance might have been harder, a point we’ll revisit in the countermeasures section.) The attack was mitigated by roughly 23:00 UTC once curve.fi was taken offline and the new domain was in place.

Impact and Aftermath: Fortunately, the May 2025 hijack appears to have caused less financial damage than Curve’s first DNS hack in 2022. In that earlier August 2022 incident, users who interacted with the fake site lost about $570,000 worth of cryptocurrency within a few hours. (Over $450K of that was later frozen or recovered with help from exchanges, but the shock was enough to rattle DeFi circles.) The 2025 hijack’s losses have not been fully disclosed, but anecdotal reports suggest they were limited – possibly a few thousand dollars – because the alarm was raised quickly and the fake site was relatively crude. The psychological impact, however, was significant. CRV (Curve’s governance token) dropped over 7% on the news, as investors reacted to yet another security failure on a critical DeFi platform. The incident came just a week after Curve’s official X (Twitter) account itself had been hacked on May 5 (an attacker briefly took over the @CurveFinance handle to post phishing links). Suffering back-to-back social engineering attacks – first on its social media, then on its DNS – put Curve in an uncomfortable spotlight.

In response, Curve’s team has doubled down on security upgrades. Immediately after the second DNS hijack, they permanently moved to the new curve.finance domain, explicitly citing “prolonged downtime and limited support” from the old .fi registrar as reasons to never go back. They froze updates on the .fi domain to prevent any further abuse. A spokesperson from Curve assured users that internal controls (passwords, 2FA, etc.) had not been bypassed and that the exploit was isolated to the DNS layer. Going forward, Curve stated it is enhancing registrar-level security and exploring alternative registrars with stronger protections. They are also actively investigating decentralized front-end options (like using IPFS or Ethereum Name Service) to reduce reliance on traditional DNS infrastructure. In fact, Curve is collaborating with the ENS community on initiatives to enable native browser support for .eth domains, which could allow a “DNS-free” access path for users in the future. In short, Curve’s second DNS fiasco has prompted a comprehensive re-evaluation of its front-end architecture.

Before discussing potential solutions to these recurring issues, let’s compare the Curve and BadgerDAO cases to understand common patterns.

Patterns in DeFi Frontend Vulnerabilities (Curve vs. BadgerDAO)

The BadgerDAO and Curve attacks, while exploiting different entry points (a cloud API vs. a DNS registrar), highlight a similar pattern: DeFi projects remain dependent on centralized web infrastructure, which can be a single point of failure. In both cases, the protocol’s decentralized smart contracts were untouched – Badger’s vaults and Curve’s liquidity pools were secure – yet users still lost funds because the interface that connects users to those contracts was compromised. This underscores a critical “trust gap” in DeFi: even if back-end code is trustless, the front-end that most users rely on is not trustless at all.

Both incidents demonstrate how attackers are increasingly shifting focus from protocol code to infrastructure and user-facing systems. As one report noted, these hacks show that hackers will target the “weakest link,” which is often the web2 components like DNS, hosting, or social media, rather than the smart contracts themselves. In the months surrounding Curve’s DNS hack, several other crypto platforms saw DNS or social account hijacks, indicating a broader trend of targeting operational infrastructure over on-chain vulnerabilities. The appeal for attackers is clear: why try to defeat audited smart contracts when you can simply trick users into giving you permission to their assets?

Another commonality is the importance of real-time communication during such attacks. Both BadgerDAO and Curve were able to limit damage by quickly alerting their communities. In Badger’s case, once they realized the frontend was malicious, they halted all contracts and warned users, but by then a lot of damage was done due to the speed of the attack. Curve, during both DNS incidents, immediately used Twitter, Telegram, and Discord to broadcast warnings. Fast communication can save users from falling prey to an ongoing attack, especially in DNS hijacks where the only indication of fraud might be a subtle URL or certificate discrepancy that many users miss. The lesson is that DeFi teams need robust monitoring and incident response plans for their frontends, just as they have for their smart contracts.

Finally, these cases highlight that recovery is difficult once such an attack occurs. Even though some of Curve’s stolen funds were recovered with the help of exchanges freezing assets, and BadgerDAO later worked on reimbursing users, prevention is far preferable. Unlike a smart contract exploit where a bug can be patched, a DNS or frontend attack often stems from weaknesses in human or organizational processes (e.g. API keys, account security, registrar reliability) – plugging those holes requires a mixture of technical and procedural fixes. In the next section, we evaluate several proposed countermeasures that could make DeFi frontends more resilient against these “infrastructure attacks.”

Hardening DeFi Frontends: Eight Countermeasures

In light of repeated DNS and frontend attacks, the crypto community has brainstormed various measures to bolster the resilience of DeFi user interfaces. Below we evaluate eight such proposed countermeasures, discussing how each could help and what trade-offs they entail:

1. Multiple Domains (Different Registrars & TLDs): One idea is to maintain redundant domain names on separate top-level domains and with different registrars. This means if one domain is hijacked or goes down, users can quickly switch to an alternate official domain. Curve actually had a glimpse of this strategy: in the 2022 attack, they directed users to curve.exchange as a fallback while resolving the curve.fi issue. Likewise, after the 2025 hack they permanently shifted to curve.finance. By registering domains in different TLD zones (e.g. .fi, .com, .xyz) and using reputable, separate registrars for each, a project reduces the risk that a single point of failure takes them completely offline. Even if an attacker compromises one registrar, the others remain unaffected. However, this approach only works if users know about the alternate domains and trust them. Projects would need to publicize their official mirrors well in advance (see point 6 on social posts) to avoid confusion. There’s also overhead in maintaining multiple domains securely (renewing them, securing each account with 2FA, etc.). Still, this redundancy can be a lifesaver. It creates an “insurance policy” – for example, had Curve’s team not controlled curve.finance already, spinning up a new domain during the crisis would have been slower and harder. Many projects are now considering reserving extra domains proactively to prepare for such scenarios.

2. Adding CAA DNS Records: DNS CAA (Certification Authority Authorization) records are a security measure to harden the SSL/TLS certificate issuance for a domain. In essence, a CAA record lets a domain owner specify which certificate authorities (CAs) are allowed to issue certificates for their domain. For example, a project can say “only Let’s Encrypt and DigiCert can issue certs for mydomain.com” – so if an attacker tries to get a certificate from another CA, that CA should refuse. Why does this matter? In a DNS hijack, the attacker will often attempt to obtain a valid HTTPS certificate for the hijacked domain (to avoid browser warnings). CAA records make that harder by limiting the universe of CAs they can use and providing notification if an unauthorized request is made. In Curve’s case, if they had strict CAA records, an attacker might have been unable to silently get a certificate from, say, a lesser-known CA. The attack could still proceed (attackers could use an allowed CA or may have compromised the registrar enough to edit CAA records too), but CAA raises the bar. It’s a relatively simple, low-cost defense that can prevent some phishing scenarios or at least generate audit logs (via CAA’s reporting) if someone tries to abuse certificate issuance. However, CAA is not foolproof – a determined attacker who has fully hijacked DNS could simply modify the CAA record as well. Still, many security experts recommend CAA as part of a defense-in-depth strategy to prevent unnoticed certificate mis-issuance.

3. Deploy the Frontend on ENS + IPFS: To eliminate dependence on traditional DNS entirely, DeFi projects can use the Ethereum Name Service (ENS) and content-addressable storage like IPFS for their frontends. ENS is a decentralized naming system on Ethereum (e.g. resolving curve.eth), and it can be used to point to content on IPFS. IPFS (InterPlanetary File System) allows hosting the static web app code in a distributed way. The combination means users can access the app via a URL like curve.eth (or a gateway like curve.eth.limo which fetches from IPFS) instead of a DNS-based URL. The advantage is that ENS names are secured by the blockchain, not by a centralized registrar, and IPFS content is tamper-evident (addressed by hash). This drastically reduces the attack surface for domain hijacks – there is no traditional DNS to hijack. Curve’s team has indicated they are now exploring such decentralized front-end options, and they are advocating for better browser support of ENS links. In practice, some DeFi apps (like Uniswap) already provide an IPFS-hosted interface accessible via ENS or dedicated gateways. The downside to this approach is primarily usability: average users may not know how to use an ENS domain or may be uncomfortable without the familiar “.com” or “.fi”. There’s also the need to keep the IPFS content updated with every frontend change (though this can be automated in deployment pipelines). Additionally, while ENS can’t be hijacked via DNS, it introduces the need to secure the ENS owner keys – a new kind of risk (if someone compromises the team’s ENS controller keys, they could repoint the name). Nonetheless, ENS+IPFS is widely seen as a promising path to trustless frontends, and incidents like Curve’s have accelerated calls to adopt these technologies.

4. Hosting a Tor .onion Mirror: Another path to bypass DNS entirely is providing an official Tor hidden service (onion) address for the DApp frontend. Onion addresses are self-authenticating and do not rely on DNS hierarchies – the “name” of an onion site is derived from its public key. By accessing Curve (or any DeFi app) via a Tor browser and a .onion URL, users could be sure they are connecting to the intended server run by the project, assuming the onion address is correct and verified. Even if an attacker hijacks the regular DNS, they cannot easily hijack the Tor address because that would require stealing the private key for the onion service. Some cryptocurrency services already offer onion sites for censorship-resistance and security (for instance, major exchanges have onion mirrors to serve users in restrictive regions). For DeFi, an onion site could serve as a high-security fallback – likely used by fewer users, but available in emergencies or for those who prioritize security. The challenges here: users must use the Tor network (which can be slower and is blocked in some corporate environments), and the project must make the community aware of the official onion address (perhaps publishing the onion fingerprint in documentation or tweets). Additionally, the frontend must be configured to work over Tor, which may involve some tweaks (e.g. avoiding clearnet API calls that would leak out of Tor). Despite being a niche solution, a Tor mirror would directly counter DNS hijacks by providing an access method completely independent of DNS and CA infrastructure. It’s a strong option for resilience, appealing especially to power-users and security-conscious community members.

5. Telegram Mini-App Interface: Given the prevalence of Telegram in the crypto community, one innovative idea is to build a Telegram Mini App for the DeFi platform. Telegram’s mini-app platform allows projects to embed lightweight web apps within the Telegram interface (often used for games or tools). In this context, Curve could develop a mini-app that lets users perform basic functions (view balances, swap tokens, add liquidity, etc.) inside Telegram’s app, without visiting an external browser at all. The security benefit is that users would be interacting with Curve through a trusted channel (the official Telegram bot/app) – DNS hijacking is not an issue because Telegram itself handles the addressing. The mini-app’s content is served via Telegram’s infrastructure, and while that is still centralized, it’s much harder for a random attacker to compromise than an isolated domain registrar. Essentially, the trust shifts to Telegram’s platform and the integrity of Curve’s mini-app code. This approach could also mitigate phishing, since users wouldn’t have to type a URL – they’d just open Telegram and use the verified Curve app interface. There are caveats: A mini-app may not support all advanced features of the web app initially, and users must trust the Telegram closed-source environment to some degree. Also, developing and maintaining a parallel interface is extra work for the team. However, many DeFi users are already on Telegram, so this could greatly lower the barrier for accessing a “known good” interface. Over time, a Telegram mini-app could grow in functionality and serve as an official fallback if the main site is ever down or suspect. It leverages the fact that Telegram chats (especially official announcement channels) are a primary way teams disseminate urgent messages – by having an app right there, the team can direct users: “use our Telegram mini-app for now” in case of an attack. This is a relatively novel countermeasure, but it aligns with the broader idea of multiplatform frontends to avoid total reliance on any single web domain.

6. Auto-Sharing Official Mirror Lists: A simpler but important practice is to consistently share and update the list of official web gateways in all communications. This means every major social post, blog update, or pinned message should remind users of the project’s legitimate domains (e.g. “Our official sites are curve.finance, curve.fi (currently down), curve.onion, and our ENS curve.eth”). By doing this proactively, users are less likely to be caught off-guard by a sudden domain change or to fall for impostor sites. In the chaos of a DNS hijack, scammers often spin up lookalike domains or social accounts to further confuse users. If the community has ingrained knowledge of the exact mirrors and alternatives, they can more easily avoid fakes. During Curve’s May 2025 incident, once the team brought up curve.finance as a new domain, they blasted that information on Twitter and Telegram so users knew where to safely go. Imagine if those alternative links were already in everyone’s bookmarks or linked in Curve’s Twitter bio beforehand – the switchover could have been even smoother. The takeaway is that projects should treat their domain list as part of their identity, and continuously publish it. For example, having a command in Telegram/Discord where the bot replies with “Official links:” and lists them, or a standing section in newsletters repeating the mirrors. This reduces reliance on frantic communication during an attack; users will already have reference points. Of course, maintaining this list means updating it whenever new mirrors (like an ENS or onion) are added, and ensuring all team communications use those official links (to train users to recognize them). It’s an operational step more than a technical one, but it strengthens the human layer of phishing defense.

7. Distributed APIs and Third-Party Access Providers: Another countermeasure is to decouple the data and transaction layer from the project’s own frontend by leveraging third-party API services. For instance, some wallets and aggregator apps use services like Moralis Web3, Infura, Alchemy, or others to fetch data and even to execute contract calls on behalf of the user. If a DeFi project ensures that its contracts are easily accessible through well-known public APIs or SDKs, then users have alternatives to the official frontend. In practice, this means if the website is down or compromised, users (especially advanced ones) can switch to using a wallet’s built-in DApp browser, a command-line tool, or a community-built interface that interacts with the same contracts via those APIs. How does this help security? It doesn’t prevent a DNS hack, but it mitigates user impact by not making them solely reliant on one website. In Curve’s case, even while their frontend was under attack, the smart contracts continued to operate – in fact, Curve processed over $400 million in on-chain volume during the DNS outage via direct contract calls and aggregators. Many users with knowledge simply went to other platforms (like Zapper, Zerion, or Etherscan’s Write Contract feature) to interact with Curve contracts directly. By encouraging use of distributed access providers (and perhaps providing an official API endpoint as a fallback), DeFi projects can ensure there’s no single web portal whose compromise would completely halt user ability to transact. Another angle is that if the official frontend is using a third-party API for critical actions, an attacker who only hijacks the static site might not easily redirect those API calls to malicious ones without also defeating additional authentication. However, reliance on third-party APIs can introduce new trust issues and dependencies (if those services have outages or if they were compromised, that’s another problem). So this measure is more about resilience and availability than pure security. It complements the others by giving savvy users multiple paths to the protocol.

8. Use Cloud-Native Domains & Multi-Cloud Mirrors: Instead of (or in addition to) running a website on a custom domain, projects can leverage domains provided by big cloud platforms that have extremely robust security. For example, an app deployed on Google App Engine can be accessed at *.appspot.com, and a static site on GitHub Pages is available at *.github.io. These domains are managed by Google and GitHub respectively, which means an attacker would have to breach those companies’ infrastructure (or the project’s account) to hijack the DNS – a much more difficult feat than hacking a small registrar. By hosting a verified mirror of the frontend on such domains, teams add an extra layer of protection. If curve.fi is down, users might go to a URL like curve.web.app (if hosted on Firebase) or curve.pages.dev (if on Cloudflare Pages), etc. Each of these uses the provider’s globally secured domain. During an incident, the team could quickly announce: “Use our verified mirror on XYZ.cloudprovider.com.” Because these platforms often integrate SSL and security by default, the attack surface is reduced (no separate DNS to manipulate apart from the platform itself). Additionally, maintaining multi-cloud deployments – e.g. one on AWS, one on GCP, one on Cloudflare – means even if one provider has an issue or the project’s account is compromised on one platform, the others are unaffected. This strategy is about diversifying hosting and domain control under the assumption that not all platforms will fail at once. The downside is complexity and cost: deploying and updating across multiple cloud providers requires DevOps effort, and the user experience of non-standard URLs might be confusing if not well-publicized. There’s also a small risk that users might be phished by fake “mirror” URLs – hence the importance of point #6 (always publish the exact official mirrors). Despite these challenges, some security-focused projects adopt this approach. It aligns with the general principle of avoiding a single point of failure. In the context of DNS attacks, using the battle-hardened infrastructure of companies like Google, Cloudflare, or Amazon for fallback addresses can significantly raise the attacker’s burden.

Closing Thoughts: None of these countermeasures alone can guarantee safety, but layered together, they dramatically improve front-end security and resilience. As Cointelegraph noted in the wake of Curve’s hack, bridging the gap between decentralized backends and centralized frontends requires a multi-layered approach. Projects must secure their domain registrars (with 2FA, registrar locks, etc.), consider decentralized hosting (ENS/IPFS), implement technical DNS safeguards (DNSSEC, CAA), and have operational plans for rapid user communication and failover. Equally important is user education: even the best infrastructure can falter if users aren’t aware of alternate access methods or how to verify the legitimacy of a site. In the evolving landscape of DeFi, the infrastructure standoff between developers and attackers continues. The second Curve DNS hijack shows that attackers will repeat tactics that work – it’s on projects now to learn from these incidents and fortify the weakest links. By adopting measures like the ones above, DeFi platforms can make it exponentially harder for the next DNS hijacker or web-interface hacker to succeed, thereby protecting their users and the ecosystem’s credibility.

Sources: The information in this article is backed by incident reports and statements from the affected projects and security researchers. For instance, CoinDesk and Cointelegraph reported detailed breakdowns of the BadgerDAO hack and Curve’s 2022 DNS hijack, while updates from May 2025 (Curve’s own posts and analyses by Cointelegraph, CryptoSlate, and others) chronicle the second Curve hijacking and its resolution.

These events underscore a crucial lesson: decentralization doesn’t end at the smart contract – to truly safeguard user funds, the community must also decentralize and secure the front-end gateways into DeFi.