GHSA-f2gr-7299-487h
DOS and excessive memory usage when passing untrusted user input to to dag import
Blast Radius
github.com/ipfs/go-ipfsReal-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
Impact
go-ipfs nodes crash when trying to import certain malformed CAR files due to an issue in the go-car dependency. This impacts nodes running ipfs dag import on untrusted user inputs, for example, pinning services with a car ingest endpoint.
This include the corresponding HTTP RPC API v0/dag/import endpoint.
An attacker controlling the car file passed in can also make the node allocate arbitrary sized buffers creating memory exhaustion attacks.
Patches
0.13.1, 0.14 and later.
Forks
For those running on forked versions of go-ipfs, simply updating the version of github.com/ipld/go-car/v2 you are using to >= v2.4.0 should resolve the issue.
Libraries consumers
Any users of libraries within the go-ipfs ecosystem, even if not the go-ipfs package or binary itself, may be affected and should upgrade their dependency on go-car.
You can check if your Go module has a dependency on go-car by running a command such as go mod graph | grep go-car in your module root.
Note: if you are using other libraries, some parts of go-car (github.com/ipld/go-car/v2/index/...) have not fully been fixed yet. Please see go-car's security advisory for more information. go-ipfs do not make use of this code.
Workarounds
The best way to work around this is to control exposure to the HTTP RPC API endpoint for CAR imports to only work with trusted data.
You can also validate that the car will not crash go-ipfs by running car verify on it first (go install github.com/ipld/go-car/cmd/car@latest).
References
See also the go-car security advisory.
For more information
If you have any questions or comments about this advisory:
- Ask in the IPFS Discourse
- Ask in the IPFS Discord #ipld-chatter
- Open an issue in go-ipfs
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/ipfs/go-ipfs | ≥ 0.5.0&&< 0.13.1 | 0.13.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/ipfs/go-ipfs. 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/ipfs/go-ipfs to 0.13.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f2gr-7299-487h 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-f2gr-7299-487h 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-f2gr-7299-487h. 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-f2gr-7299-487h in your dependencies?
O3 detects GHSA-f2gr-7299-487h across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.