GHSA-7pq9-rf9p-wcrf
MEDIUMgo-f3 Vulnerable to Cached Justification Verification Bypass
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
github.com/filecoin-project/go-f3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Description
A vulnerability exists in go-f3's justification verification caching mechanism where verification results are cached without properly considering the context of the message. An attacker can bypass justification verification by:
- First submitting a valid message with a correct justification
- Then reusing the same cached justification in contexts where it would normally be invalid
This occurs because the cached verification does not properly validate the relationship between the justification and the specific message context it's being used with.
Impact
- Potential consensus integrity issues through invalid justification acceptance
- Could affect network liveness if exploited systematically
- May allow malicious actors to influence consensus decisions with invalid justifications
- Requires significant power (350+ TiB due to power table rounding) to meaningfully exploit
- It would also be difficult to exploit in a synchronised fashion, such that >1/3 of the network goes down at one time. This isn't a one-msg panic, where you can spam it and bring everyone down, because every node will have a different amount of memory andmany SPs also run redundant lotus nodes.
Patches
The fix was merged and released with go-f3 0.8.9. All node software (Lotus, Forest, Venus) are using a patched version of go-f3 with their updates for the nv27 network upgrade.
Workarounds
The are no immediate workarounds available. Nodes should upgrade to the patched version, which they will have done if participating in nv27 on Filecoin mainnet.
Credits
The bug was reported by @lgprbs via our bug bounty program. Thank you for the contributions.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/filecoin-project/go-f3 | all versions | 0.8.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/filecoin-project/go-f3. 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 github.com/filecoin-project/go-f3 to 0.8.9 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7pq9-rf9p-wcrf 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-7pq9-rf9p-wcrf 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-7pq9-rf9p-wcrf. 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-7pq9-rf9p-wcrf in your dependencies?
O3 detects GHSA-7pq9-rf9p-wcrf across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.