GHSA-8986-v76q-8vr2 — @keep-network/tbtc-v2
HIGHGHSA-8986-v76q-8vr2 is a high-severity (CVSS 7.5) vulnerability in @keep-network/tbtc-v2. A fix is available for @keep-network/tbtc-v2 — see the affected versions and patch details below.
@keep-network/tbtc-v2 revealing P2PKH deposit with a wrapped P2SH script
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.
@keep-network/tbtc-v2npmDescription
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.2npm install @keep-network/tbtc-v2@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, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-8986-v76q-8vr2 can be triaged on real exposure rather than presence alone.
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 Security finds GHSA-8986-v76q-8vr2 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.