GHSA-8986-v76q-8vr2
HIGH@keep-network/tbtc-v2 revealing P2PKH deposit with a wrapped P2SH script
Blast Radius
@keep-network/tbtc-v2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Overview
P2PKH has 20 bytes just like P2SH. We protect against revealing P2PKH deposits by manually assembling the expected P2SH script in the smart contract and comparing hashes. However, we missed the case when the attacker embeds a valid P2SH inside of P2PKH as an output script. bitcoin-spv library extracts the P2SH from P2PKH and we treat it as a valid P2SH output.
This does not lead to stealing funds but can lead to protocol insolvency.
The off-chain client handles this case correctly, but the problem is in the optimistic minting bot. The bot assumes that if the funding TX exists on Bitcoin with the right amount and it was successfully revealed, the transaction is valid.
https://bugs.immunefi.com/magnus/672/projects/502/bug-bounty/reports/55982
Steps
Since there is a 24-hour governance delay on upgrading the Bridge smart contract, we are going to pause optimistic minting.
- Pause optimistic minting.
- Deploy new Bridge implementation with Deposit library containing a fix, WITHOUT VERIFYING THE CODE on Etherscan.
- Schedule upgrade transaction.
- After 24 hours, finalize upgrade.
- Unpause optimistic minting.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @keep-network/tbtc-v2 | all versions | 1.8.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @keep-network/tbtc-v2. 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 @keep-network/tbtc-v2 to 1.8.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-8986-v76q-8vr2 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-8986-v76q-8vr2 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-8986-v76q-8vr2. 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-8986-v76q-8vr2 in your dependencies?
O3 detects GHSA-8986-v76q-8vr2 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.