Metamask Snap Audit Report for Openverse

Management Summary

Openverse contacted Sayfer Security in order to perform penetration testing on Openverse’s MetaMask Snap, Openverse Wallet, in 02/2025.

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

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

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

After review by the Sayfer team, we certify that the high-risk vulnerability mentioned in this report has been fixed and that all others have been acknowledged by the Openverse 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

Origin Spoofing

Description

The snap prioritizes the origin value provided in request.params (controlled by the calling dapp) over the validated origin parameter provided by MetaMask. This allows attackers to spoof their displayed origin in UI dialogs (e.g., showing openverse.network while the real origin is phishing.site).

MetaMask’s same-origin policy ensures the origin parameter reflects the true invoking domain, but the snap ignores this safeguard.

• tsx:22

const dappOrigin = (request Yparams as { origin?: string }).origin origin;

Mitigation

We recommend using MetaMask’s validated origin parameter.

Non-standard Signing Implementation

Description

The snap uses tweetnacl to sign raw messages with directly derived private keys (secretKey), instead of leveraging MetaMask’s native methods, such as eth_signTypedData_v4. This violates MetaMask’s key isolation principles and potentially introduces novel vulnerabilities.

• tsx:G2; case signTransaction

const signature = nacl.sign.detached(bs58.decode(message),
keyPair.secretKey);

• tsx:81-84; case signAllTransactions

const signatures = messages
  .map((message: string) => bs58.decode(message))
  .map((message: Uint8Array) => nacl.sign.detached(message,
keyPair.secretKey))
  .map((signature: Uint8Array | number[]) => bs58.encode(signature));

• tsx:113; case signMessage

const signature = nacl.sign.detached(messageBytes, keyPair.secretKey);

Mitigation

We recommend replacing the custom signing logic with eth_signTypedData_v4.

Missing Transaction Broadcasting Functionality

Description

The snap signs transactions and messages but does not broadcast them, relying entirely on the dapp to handle on-chain submission. This increases reliance on potentially malicious dapps.

• tsx:G4-G7, 115-118; case signTransaction, case signMessage

return {
  publicKey: bs58.encode(keyPair.publicKey),
  signature: bs58.encode(signature)
};

• tsx:8G-89; case signAllTransactions

return {
  publicKey: bs58.encode(keyPair.publicKey),
  signatures
};

Mitigation

We recommend implementing transaction broadcasting, or alternatively informing the user that their transaction will be handled by the dapp.

Missing Anti-Replay Protection

Description

The snap signs raw messages without including chain-specific identifiers such as chainId, domain separators (e.g., EIP-712 domain), or nonces. Attackers could reuse signatures on other networks where the same message is valid.

Mitigation

We recommend prepending chain-specific prefixes such as \x19Openverse:\n{chainId} to messages before signing.

Missing Input Sanitization for User-Facing Content

Description

renderSignMessage(string, string) displays raw user-provided messages using the <Text> component, which interprets Markdown syntax. An attacker could inject hyperlinks such as [Legit Site](evil.site) to trick users into approving malicious content.

• tsx:202-209

content: (
  <Box>
    <Heading>Sign message /Heading>
    <Text>{host} /Text>
    <Divider >
    <Text>{message} /Text>
    /Box>
)

Mitigation

Replace <Text> with the <Copyable> component for displaying messages to prevent Markdown rendering and ensure content is treated as plaintext.

Confusing Dialog Box

Description

renderSignAllTransactions(string, any) displays multiple transactions in a single dialog, making it difficult for users to scrutinize each transaction. This increases the likelihood of approving unintended or harmful actions.

• tsx:202-209

for (let i = 0; i < messages.length; i +) {
  uiElements.push(<Divider >);
    / uiElements.push(Text(`Transaction ${i + 1}`));
  uiElements.push(<Text>Transaction {(i + 1).toString()} /Text>);
    / uiElements.push(Copyable(messages[i]));
  uiElements.push(<Copyable value={messages[i]}> /Copyable>);
}

return snap.request({
  method: 'snap_dialog',
  params: {
    type: 'confirmation',
    content:
      (
        <Box>
          <Heading>Sign transactions /Heading>
          <Text>{host} /Text>
          {uiElements}
         /Box>
      )
                                   [ .]
}

Mitigation

Split bulk transactions into individual confirmation dialogs or add a summary screen highlighting critical details, for example total value or list of recipients before approval.