Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
@metamask/sdknpm@metamask/sdk-reactnpm@metamask/sdk-communication-layernpmDescription
Who is affected?
This advisory only applies to developers who use MetaMask SDK in the browser and who, on Sept 8th 2025 between 13:00–15:30 UTC, performed one of the following actions and then deployed their application:
- Installed MetaMask SDK into a project with a lockfile for the first time
- Installed MetaMask SDK in a project without a lockfile
- Updated a lockfile to pull in
[email protected](e.g., vianpm updateoryarn upgrade)
What happened?
On Sept 8th, 2025 (13:00–15:30 UTC), a malicious version of the debug package (v4.4.2) was published to npm. The injected code attempts to interfere with dApp-to-wallet communication when executed in a browser context.
While MetaMask SDK itself was not directly impacted, projects installing the SDK during this window may have inadvertently pulled in the malicious version of debug.
Mitigation
- If your application was rebuilt and redeployed after Sept 8th, 2025, 15:30 UTC, the malicious version of debug should no longer be present. Please also verify that your package manager (npm, yarn, pnpm, etc.) is not caching
[email protected]. - If you have not yet deployed since performing one of the actions above, delete your
node_modulesand reinstall dependencies before deploying. - If your application was deployed during the attack window and has not been rebuilt since, perform a clean install of dependencies and redeploy to ensure the malicious package is removed.
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @metamask/sdk | ≥ 0.16.0&&< 0.33.1 | 0.33.1 |
| 📦npm | @metamask/sdk-react | ≥ 0.16.0&&< 0.33.1 | 0.33.1 |
| 📦npm | @metamask/sdk-communication-layer | ≥ 0.16.0&&< 0.33.1 | 0.33.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @metamask/sdk. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @metamask/sdk to 0.33.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qj3p-xc97-xw74 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-qj3p-xc97-xw74 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-qj3p-xc97-xw74. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qj3p-xc97-xw74 in your dependencies?
O3 detects GHSA-qj3p-xc97-xw74 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.