GHSA-v666-6w97-pcwm
GHSA-v666-6w97-pcwm is a security vulnerability in ckb. O3 Security confirms whether GHSA-v666-6w97-pcwm is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Miner fails to get block template when a cell used as a cell dep has been destroyed.
Real-World Exposure
ckbReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
Impact
The RPC get_block_template fails when a cell has been used as a cell dep and an input in the different transactions.
Say cell C is used as a dep group in the transaction A, and is destroyed in the transaction B.
The node adds transaction A first, then B into the transaction pool. They are both valid. But when generating the block template, if the fee rate of B is higher, it comes before A, which will invalidate A. Currently the RPC get_block_template will fail instead of dropping A.
Patch
First, the get_block_template should not fail but dropping the conflict transactions.
Then we can propose solution to this issue. Here is an example. When a transaction is added to the pool, the pool must consider it depending on all the transactions which dep cell (direct or indirect via dep group) has been destroyed in this transaction. Because future transactions using the destroyed cells as dep will be rejected, the spending transaction only need to wait for all the existing dep transactions on chain.
Workaround
- Submit transaction B when A is already on chain.
- Let B depend on A explicitly, there are several solutions:
- a. Add any output cell on A as a dep cell or input in B.
- b. Merge A and B. CKB allows using the same cell as both dep and input in the same transaction.
- Ensure the fee rate of B is less than A so A always has higher priority.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | ckb | all versions | 0.40.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ckb. 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 ckb to 0.40.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v666-6w97-pcwm 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-v666-6w97-pcwm 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-v666-6w97-pcwm. 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-v666-6w97-pcwm in your dependencies?
O3 detects GHSA-v666-6w97-pcwm across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.