Web3Auth flaw empties Keplr wallets: lessons for SMBs

A flaw in Web3Auth authentication compromises Keplr wallets

Security in the cryptocurrency ecosystem is once again in the spotlight. This time, the incident affects Keplr, a popular cryptocurrency wallet, and Web3Auth, the company that manages sign-in with Google and Apple accounts for that wallet. As both companies have confirmed, an attacker took advantage of a vulnerability in Web3Auth to access wallets created with those authentication methods and steal funds. The provider's reaction was swift: Web3Auth used the same path as the attacker to empty other wallets at risk before the attacker could do so.

The event, first reported by The Hacker News, highlights a critical aspect of security: reliance on third parties for functions as sensitive as authentication. In this case, Keplr delegated identity verification via Google and Apple to Web3Auth, a convenient model for the user but one that introduces an additional link in the chain of trust. If that link fails, the consequences can be immediate and financial.

What exactly happened?

The facts, as reported by the companies, are as follows: an attacker exploited a vulnerability in Web3Auth to reach Keplr wallets that had been set up using Google or Apple sign-in. The number of affected users and the amount stolen are not specified, but it is confirmed that funds were stolen. Faced with this situation, Web3Auth took a drastic measure: it emptied other wallets it considered at risk, using the same path the attacker had used, in order to safeguard the assets before the attacker could act on them.

It is important to stress that this is not a flaw in the blockchain or in the Keplr protocol itself, but in the external authentication system. This reinforces the idea that an application's security depends not only on its code, but also on the integrations and providers it uses.

Provider's reaction: a controversial but effective measure

Web3Auth's decision to empty other people's wallets in order to protect them raises an interesting debate. On the one hand, it demonstrates a capacity for rapid response and a certain control over the infrastructure, which made it possible to prevent greater harm. On the other, it highlights the level of access an authentication provider can have over users' funds. In a decentralized environment, the fact that a third party can move assets without the user's explicit consent is, to say the least, striking. However, in an emergency situation such as the one described, the alternative could have been worse: letting the attacker continue to act.

For companies and SMBs that operate with cryptocurrencies or that integrate third-party solutions for authentication, this incident leaves several lessons. The first is the need to assess the security of the providers you work with, especially if they handle credentials or access digital assets. The second is the importance of having contingency plans and incident response protocols that allow you to react quickly without depending exclusively on the provider's goodwill.

Implications for SMBs and IT teams

Although the case affects a cryptocurrency wallet, the pattern can be extrapolated to any service that uses delegated authentication (OAuth, sign-in with Google, etc.). Many SMBs turn to these solutions for convenience and speed of implementation, but they do not always analyze the associated risks. A flaw in the identity provider can compromise access to sensitive data or critical systems. That is why, at ForgeNEX, we recommend:

• Audit identity providers: review their certifications, incident history and response policies.
• Implement the principle of least privilege: limit the access third parties have to our systems and data.
• Establish early warning mechanisms: monitor anomalous access and have detection tools in place.
• Train users: explain the risks of using third-party accounts for sensitive services and encourage the use of multi-factor authentication where possible.

In addition, it is advisable to review the architecture of our applications to avoid unnecessary dependencies. If an external authentication service goes down or is compromised, do we have an alternative? Can we revoke access immediately? These are questions every IT team should ask itself.

Relation to other recent incidents

This case has similarities with other security flaws we have discussed on the blog, such as admin:admin on identity servers, which made it possible to unlock and start cars, or Barracuda with two chained flaws. In all of them, the common denominator is the trust placed in an external component that, when it fails, opens the door to unauthorized access. The difference here is that the asset at stake is cryptocurrency, which adds a direct financial incentive for the attacker.

The lesson is clear: security is a chain and its strength depends on the weakest link. In an increasingly interconnected world, identifying and reinforcing those links becomes an essential task for any organization, regardless of its size.

Final recommendations

For SMBs that manage digital assets or that integrate third-party authentication services, the Web3Auth and Keplr incident is a wake-up call. It is not about giving up the convenience these solutions offer, but about adopting them with due caution. Some specific measures:

1. Carry out a risk assessment of all external providers, paying special attention to those that handle identities or access.
2. Demand transparency from providers about their security practices and their incident response plans.
3. Diversify: do not depend on a single provider for critical functions.
4. Maintain a communication and incident response plan that includes the possibility of revoking access and notifying those affected.

At ForgeNEX we help SMBs design secure architectures and evaluate their technology providers. If you have doubts about how to protect your authentication systems, do not hesitate to contact us.

Source: The Hacker News. Analysis and adaptation: ForgeNEX.