Metamask Snap Audit Report for The Warp

Management Summary

The Warp contacted Sayfer Security in order to perform penetration testing on their MetaMask Snap in April 2025.

Before assessing the above services, we held a kickoff meeting with The Warp technical team and received an overview of the system and the goals for this research

Over the research period of 2 weeks, we discovered 8 vulnerabilities in the system.

In conclusion, several fixes should be implemented following the report, but the system’s security posture is competent.

After a review by the Sayfer team, we certify that all the security issues mentioned in this report have been addressed by The Warp team.

Risk Methodology

At Sayfer, we are committed to delivering the highest quality penetration testing to our clients. That’s why we have implemented a comprehensive risk assessment model to evaluate the severity of our findings and provide our clients with the best possible recommendations for mitigation.

Our risk assessment model is based on two key factors: IMPACT and LIKELIHOOD. Impact refers to the potential harm that could result from an issue, such as financial loss, reputational damage, or a non-operational system. Likelihood refers to the probability that an issue will occur, taking into account factors such as the complexity of the attack and the number of potential attackers.

By combining these two factors, we can create a comprehensive understanding of the risk posed by a particular issue and provide our clients with a clear and actionable assessment of the severity of the issue. This approach allows us to prioritize our recommendations and ensure that our clients receive the best possible advice on how to protect their business.

Risk is defined as follows:

Security Evaluation Methodology

Sayfer uses OWASP WSTG as our technical standard when reviewing web applications. After gaining a thorough understanding of the system we decided which OWASP tests are required to evaluate the system.

Security Assessment

After understanding and defining the scope, performing threat modeling, and evaluating the correct tests required in order to fully check the application for security flaws, we performed our security assessment.

Issue Table Description

Issue title

Description

Here we provide a brief description of the issue and how it formed, the steps we made to find or exploit it, along with proof of concept (if present), and how this issue can affect the product or its users.

Mitigation

Suggested resolving options for this issue and links to advised sites for further remediation.

Security Assessment Findings

Missing User Confirmation When Switching Active Wallets

Description

The handler loads the imported wallet immediately, without prompting the user via any dialog. As a result, any downstream sign or signAndSubmit operations will use the new wallet without explicit user consent.

• SwitchWalletHandler.ts:13-22

// If switching to derived wallet
if (params.address this.context.derivedWallet.address) {
 // Update context
 await this.context.updateActiveWallet(undefned);
 Update state
 await this.context.stateManager.set({
  activeImportedWallet: undefned,
 });
 return { address: params.address };
}

Mitigation

We recommend presenting the user with a confirmation dialog before calling updateActiveWallet(string?).

Entropy Hex Treated as ASCII in Encryption/Decryption

Description

The code calls TextEncoder().encode(entropy) where entropy is a hex string (e.g. “1a2b3c…”) instead of converting it to raw bytes. This reduces the entropy drastically.

• encryption.ts:20-27, 94-101

const encoder = new TextEncoder();
const keyMaterial = await crypto.subtle.importKey(
 'raw',
 encoder.encode(entropy),
 { name: 'PBKDF2' },
 false,
 ['deriveKey']
);

Mitigation

We recommend hex-decoding the entropy into a Uint8Array before importing the key.

State Update during the Read-Only Endpoint Call

Description

In ListWalletsHandler, the logic is meant to be a pure “get” but performs a set operation whenever the derived address differs.

• ListWalletsHandler.ts:28-30

// Ensure the derived wallet address is stored in state for future
rehydration
if (!state.derivedWalletAddress state.derivedWalletAddress
derivedWallet.address) {
 await this.context.stateManager.set({ derivedWalletAddress:
derivedWallet.address });
}

Mitigation

We recommend reconsidering the one‐time derived‐address write to initialization (Context.init()), and removing state writes from the handle() method so it remains truly read-only.

Redundant State Write

Description

In SwitchWalletHandler, the call to updateActiveWallet(string?) already clears activeImportedWallet in state, yet the code immediately calls stateManager.set(Partial) again.

• SwitchWalletHandler.ts:13-22

//If switching to derived wallet
if (params.address this.context.derivedWallet.address) {
 //Update context
 await this.context.updateActiveWallet(undefned);
 //Update state
 await this.context.stateManager.set({
  activeImportedWallet: undefned,
 });
 return { address: params.address };
}

Mitigation

We recommend eliminating the second stateManager.set(Partial<State>) call and rely solely on updateActiveWallet(string?).

Incorrect Regex

Description

The code intends to remove a leading “00” or “s” prefix, but the ungrouped alternation matches either “^00” or any “s” globally.

• Wallet.ts:73

const cleanPrivateKey = privateKey.replace(/^00|s/, '').toUpperCase();

Mitigation

We recommend using a grouped, anchored regex to strip only the prefix.

const cleanPrivateKey = privateKey.replace(/^(?:00|s)/, '').toUpperCase();

Redundant Try/Catch in Encryption Methods

Description

Both encryptData(string) and decryptData(string) wrap their entire logic in a try/catch block, which simply throws the error without any additional handling.

Mitigation

Remove the outer try/catch blocks and let promise rejections propagate naturally.

Redundant Null Check

Description

In ImportWalletHandler, after verifying if (!params.seed && !params.privateKey), the code does a second if (!seed) check, which can never be true.

• ImportWalletHandler.ts:15-23

if (!params.seed !params.privateKey) {
 throw new InvalidParamsError('Family seed must be provided');
}
// Convert privateKey parameter to seed if provided
const seed = params.seed params.privateKey;
if (!seed) {
 throw new InvalidParamsError('Family seed must be provided');
}

Mitigation

We recommend removing the second if block to streamline the logic.

Unused Parameter

Description

SwitchWalletHandler.handle(string, {string}) takes an origin argument but never references it again.

Mitigation

Consider removing this parameter if it is not necessary.