GHSA-mpgr-2cx9-327h is a high-severity (CVSS 7.5) Information Exposure vulnerability in ssb-db. O3 Security confirms whether GHSA-mpgr-2cx9-327h is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Information disclosure in SSB-DB
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
ssb-dbnpmDescription
Impact
What kind of vulnerability is it? Who is impacted?
Servers running SSB-DB 20.0.0 (which is packaged with SSB-Server 16.0.0) must upgrade immediately.
There is no evidence that other SSB apps are vulnerable or that this problem has been exploited in the wild.
The get() method is supposed to only decrypt messages when you explicitly ask it to, but there's a bug where it's decrypting any message that it can. This means that it's returning the decrypted content of private messages, which a malicious peer could use to get access to private data. This only affects peers running [email protected] who also have private messages, and is only known to be exploitable if you're also running SSB-OOO (default in SSB-Server), which exposes a thin wrapper around get() to anonymous peers.
Patches
Has the problem been patched? What versions should users upgrade to?
Yes, please upgrade to SSB-DB 20.0.1 (or SSB-Server 16.0.1) immediately.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
You may be able to disable the most obvious attack vector, SSB-OOO, by disabling the plugin, but you should upgrade immediately anyway.
For more information
If you have any questions or comments about this advisory, open an issue in SSB-DB
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | ssb-db | ≥ 20.0.0&&< 20.0.1 | 20.0.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ssb-db. 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 ssb-db to 20.0.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mpgr-2cx9-327h 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-mpgr-2cx9-327h 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-mpgr-2cx9-327h. 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-mpgr-2cx9-327h in your dependencies?
O3 detects GHSA-mpgr-2cx9-327h across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.