Why MetaMask’s Snap System Creates Unauditable Security Risks That Users Can’t See or Revoke

MetaMask has established itself as the dominant browser-based crypto wallet, controlling approximately 25 million active monthly users and serving as the default entry point for Ethereum interaction. Its strength lies in accessibility: installation takes minutes, recovery is straightforward, and the wallet integrates seamlessly with decentralized applications. Yet this ubiquity has led ConsenSys, its developer, to introduce a system called Snaps—third-party code that executes within the MetaMask runtime with permissions that users often do not fully understand or cannot easily revoke.

The consequence is architectural: a crypto wallet designed to be self-custodial and user-controlled now permits arbitrary code execution from unknown developers under a permission model that diverges from traditional browser security standards. A user installing a Snap may believe they are adding a convenience feature; they are also introducing a new attack surface where the wallet itself becomes an intermediary between their private keys and external code they cannot audit. The security implications extend beyond individual keystroke logging or transaction interception. They reach into the fundamental assumption that a non-custodial wallet’s security boundary ends at the application itself.

How Snaps bypass traditional wallet security assumptions

A traditional crypto wallet architecture assumes that security begins and ends within the application. The user controls private keys or seed phrases; the wallet displays transactions; the user approves signature requests. Communication between the wallet and external services—blockchain nodes, price data, token metadata—is typically one-directional: the wallet requests data, an external service responds. The wallet software itself remains bounded.

MetaMask Snaps invert this model. A Snap is JavaScript code running inside the MetaMask process with access to wallet state, transaction data, and user interactions. It can intercept or transform transactions before display, modify how signing works, add new transaction types, or mediate communication between the wallet and applications. Critically, the user does not download and audit the Snap’s code before installation. Instead, they see a permission request that typically uses broad language such as “modify transactions” or “run custom code.” The actual JavaScript—potentially thousands of lines from a developer with no established reputation—remains invisible until after installation.

The permission model itself lacks transparency. According to Ethereum’s technical architecture documentation, wallet standards have evolved to include explicit user consent for sensitive operations. Snaps nominally follow this principle, but the granularity is misleading. A Snap requesting “wallet_snap_manageState” permission gains access to persistent storage; a request for “eth_signTransaction” permits interception of every signing operation. The user sees a brief notification. They do not see which functions the Snap actually uses, how often it runs, or what data it touches. This is not a limitation of the MetaMask interface; it is inherent to the permission model’s design.

Compare this to operating system security models. A macOS application requesting microphone access triggers an explicit system prompt each time the app tries to use it. The user can open System Preferences and see a list of all applications with microphone permissions and revoke them individually. A browser extension in Chrome or Firefox similarly appears in the extension panel, and users can inspect its code on the Chrome Web Store or Mozilla Add-ons. MetaMask Snaps exist in a middle ground where they are more privileged than a typical web application, yet less transparent than a browser extension or system application.

The permission opaqueness problem and practical revocation failures

MetaMask displays a list of installed Snaps in the wallet settings, but this list does not clearly indicate what each Snap does, what permissions it was granted, or when it last executed. A user who installed a Snap six months ago to convert between USD and Ethereum may have forgotten it exists. That Snap, sitting dormant in the wallet runtime, retains every permission granted during installation. If the Snap’s developer was compromised or changed the code remotely, the user has no indication.

Revoking a Snap is possible—the user can delete it from the Snap list—yet this operation is not always atomic or clear in its effects. Removing a Snap does not necessarily purge its stored state or confirm that its processes have terminated. Some Snaps persist data using the wallet’s persistent storage system; after deletion, that data may remain. The user interface does not confirm what will be lost or retained. This creates a plausible scenario where a user uninstalls a Snap believing it is fully removed, but residual permissions or data remain accessible to a different malicious Snap installed later.

An even more concerning pattern is the silent permission elevation. A Snap’s code can request additional permissions after the initial installation. This is theoretically subject to user approval, but the approval prompt may appear in the midst of normal wallet activity. A user confirming a transaction or checking their balance may miss or reflexively approve a prompt asking for new wallet_snap_manageState or eth_sign permissions. The wallet does not maintain a permission change log. There is no notification mechanism alerting the user that an already-installed Snap has acquired new capabilities.

For comparison, the Financial Conduct Authority has outlined principles for financial applications in the UK, emphasizing explicit user control and clear revocation. While crypto wallets fall into a gray regulatory area, the operational principle applies: a user should be able to understand what a third-party extension does and remove it without residual access. MetaMask’s current Snap system does not reliably meet this standard.

Attack vectors enabled by Snap code execution

The technical attacks enabled by unrestricted Snap execution span several categories. The first is transaction substitution: a Snap intercepts a transaction after the user approves it but before it is broadcast. The Snap modifies the recipient address, amount, or contract interaction, then re-signs or submits the modified transaction. The user sees a success notification; the wrong destination or amount was transferred. This is distinct from a man-in-the-middle attack because it occurs within the wallet software itself, beyond the user’s ability to inspect network traffic or blockchain confirmation.

The second is seed phrase exfiltration. Although MetaMask’s design does not normally expose the seed phrase to the Snap context, a Snap with certain permissions can observe the wallet’s internal state during key derivation or seed phrase operations. If a user manually enters their seed phrase during wallet recovery or backup verification, a running Snap can capture it. The wallet does not isolate these operations from Snap code.

The third is signature hijacking. A Snap with eth_sign or wallet_snap_manageState permissions can modify how transactions are signed. This could involve signing a different transaction than the one displayed, or performing signatures in response to external signals (an HTTP request, a timer) rather than explicit user action. The user believes they are signing one thing; the Snap signs another. Importantly, the signature is cryptographically valid—the blockchain will accept it. The discrepancy lies between what the user intended and what actually occurred.

The fourth is data harvesting. A Snap can log every transaction the user initiates, every address they interact with, every balance check, and every application they connect to. This data can be transmitted to a remote server under the guise of “analytics” or “performance monitoring.” The user has no clear way to audit this communication because the Snap runs in a JavaScript runtime with access to network APIs.

These attacks are not hypothetical. They follow directly from the permission model. OWASP’s security principles explicitly warn against architectures that combine broad code execution privileges with opaque permissions and weak audit trails. MetaMask Snaps exhibit all three characteristics.

The ecosystem pressure driving Snap adoption

ConsenSys has positioned Snaps as the future of wallet extensibility. A wallet developer can create a Snap to add support for a new blockchain, enable privacy-focused transaction patterns, provide custom signing workflows, or integrate with a specific service. Without Snaps, these features would require forking MetaMask or maintaining a separate wallet. From a developer experience perspective, Snaps solve a real problem.

The pressure to adopt Snaps is asymmetric. A blockchain project, decentralized finance protocol, or wallet service provider can build a Snap and encourage users to install it. The incentives for the user to install are also often strong: improved functionality, faster transactions, or integration with a specific service they already use. Yet the incentive to audit the Snap’s code or understand its permissions is low. Most users do not read source code. They trust the developer’s reputation or the fact that the Snap appears in MetaMask’s official registry.

An independent crypto wallet review platform can document these risks and compare how different wallets handle extensibility, but individual users face a practical choice: use MetaMask and accept Snaps as a potential security cost, or migrate to a wallet without this attack surface. That choice is easier for technical users than for ordinary people managing their first crypto assets.

This creates a bootstrapping problem for the ecosystem. The more Snaps are built and adopted, the more incentives exist for attackers to develop malicious Snaps. The more malicious Snaps circulate, the more damage can occur before users realize the risk. MetaMask’s response—improving the permission model, adding audit logging, or requiring code review—has been slower than the expansion of Snap capabilities.

Comparison with alternative permission models

Other crypto wallets have approached extensibility differently. Ledger Live uses a plugin architecture where third-party code runs in a sandboxed iframe with strictly limited access to the hardware wallet’s private keys. Phantom, built on Solana, implements a capability-based permissions system where applications (Snaps, in Phantom’s terminology) can request specific actions rather than broad state access. Trezor T devices support multiple firmware versions but do not permit runtime code installation from untrusted developers.

The BIP39 standard for seed phrase generation was designed to give users portable wallet recovery across compatible implementations. Part of that portability requires that wallet software remain predictable and non-extensible—a seed phrase should generate the same keys in any compliant wallet. This architectural principle, intentionally conservative, avoids the problem that MetaMask faces: if user funds can be handled by multiple extensions with different permissions, the same seed phrase may lead to different security outcomes depending on which Snap is installed.

Hardware wallets like Ledger and Trezor provide another comparison point. They do not permit third-party code execution at runtime. Instead, they support multiple asset types and signing protocols through firmware updates, which are reviewed before release. This is slower and less flexible than Snaps, but it avoids the runtime permission problem entirely. The trade-off is explicit: less extensibility for more predictability and auditability.

Phantom’s approach sits between these extremes. It allows third-party applications to request permissions (like MetaMask), but the permission model is more granular. An application can request “signMessage” or “signTransaction” without gaining general state access. Critically, Phantom maintains an audit log of which applications requested what permissions and when. Users can inspect this log, though most do not. The architectural difference is that Phantom’s permissions are tied to specific applications rather than to arbitrary code running in the wallet runtime.

Why revoking MetaMask Snap permissions is insufficient

A user who discovers that a Snap has misbehaved can uninstall it. But this does not fully address the security risk. First, the damage may already be done. If a malicious Snap captured the user’s seed phrase, private keys, or transaction history, uninstalling it does not recover that information or undo any theft.

Second, uninstallation does not guarantee that related code or configuration has been removed. A Snap can store state in persistent storage. If the Snap is written to restart itself or reinstall upon certain conditions, removing it from the Snap list may not be sufficient. The user would need to manually clear browser storage, check MetaMask’s internal state, and potentially reset the wallet entirely—a process most users cannot perform.

Third, European Commission digital finance regulations now require that wallet providers maintain clear user control and revocation mechanisms for third-party services. MetaMask’s current Snap infrastructure does not fully align with this expectation. The EU’s Markets in Crypto-assets Regulation (MiCA) framework envisions wallets as providers of custody services, where users should have explicit rights to revoke third-party access. Snaps blur this boundary because they execute with the wallet’s privileges rather than being treated as separate services.

The practical result is that a user relying on revoking Snap permissions as a security measure is operating with incomplete information. Revocation may not be complete. New Snaps can request the same permissions as their predecessors. And the time between installation and discovery of malicious behavior could be weeks or months, during which the Snap had full access to the wallet’s transaction data.

Toward a more auditable wallet architecture

Addressing MetaMask’s Snap security risks would require architectural changes that ConsenSys has not yet implemented. The first is mandatory code review. Before a Snap is added to the official registry, it should be audited by a third party. This would increase the friction for publishing Snaps, but it would catch obvious malicious patterns such as exfiltration loops or hardcoded private keys being transmitted externally. It would not catch sophisticated attacks, but it would raise the barrier meaningfully.

The second is atomic permission grants and revocation. Each permission should have a clear description of what it enables, and revocation should provide a confirmation of what will be removed. If a Snap stores persistent data, uninstalling the Snap should remove that data by default. Users should have the option to retain it, but the default should be erasure.

The third is permission change auditing. The wallet should maintain a cryptographically signed log of every permission granted to every Snap, including the timestamp and what the user was shown. This log should be available to the user and should be cleared only upon explicit request. If a Snap requests a new permission, the user should see a history of its previous requests and be able to compare them.

The fourth is execution isolation. Snaps should not run in the same JavaScript context as the wallet’s core signing and key management logic. Instead, they should communicate through a well-defined API that explicitly prevents direct access to private keys or seed phrases. This is technically feasible—it is how browser extensions work—but it would require significant redesign.

None of these changes would make MetaMask’s Snap system completely safe. They would make it more comparable to existing security standards for browser extensions and operating system applications. Users selecting a crypto wallet should understand that MetaMask’s convenience comes with architectural trade-offs that other wallet designs avoid.

What users should do now

For users currently using MetaMask with Snaps installed, the practical steps are straightforward. First, audit the Snap list in MetaMask settings. Check the name, developer, and installation date of each Snap. If any Snap is unfamiliar or has not been used in months, uninstall it. Second, visit the developer’s website or official documentation to confirm that the Snap is legitimate and has not had security incidents. ConsenSys does not maintain an official security advisory list for Snaps, so this requires individual research.

Third, limit Snap permissions to the minimum necessary. Some Snaps request permissions they do not actually need; asking the developer to clarify why specific permissions are required can reveal whether the Snap is trustworthy. Fourth, consider using a separate wallet instance or browser profile for high-value transactions. This reduces the number of Snaps that could potentially interfere with important transfers.

Fifth, keep MetaMask updated. ConsenSys regularly releases security patches. Using an outdated version increases the risk that known Snap vulnerabilities or permission bypasses could be exploited. Finally, understand that MetaMask’s default permission model does not prevent all attacks. For large holdings, a hardware wallet such as Ledger or Trezor provides a security boundary that does not include Snaps or third-party code execution.

The larger question is how the wallet industry will evolve. Bitcoin’s protocol specification and Ethereum’s technical standards leave room for variation in how wallets implement interfaces and handle user authorization. Some projects will continue to prioritize extensibility; others will maintain security through conservatism. Users should recognize that a crypto wallet’s architecture is not a detail—it is the foundation of whether their security actually rests with them or with the developers who maintain the wallet’s code and the third parties who extend it.