GHSA-m5ph-mmg5-6w5h: Filecoin Pin: Unbounded DAG pinning can exhaust filecoin-pin server resources
Filecoin Pin is an IPFS Pinning Service API implementation that pins to Filecoin's PDP service. In daemon deployments up to and including version 1.1.0, POST /pins in src/filecoin-pinning-server.ts checks a caller-supplied CID with CID.parse and passes it to pinStore.pin, but does not enforce request rate limits or per-user quotas. In src/filecoin-pin-store.ts, each pin independently schedules processPinInBackground with setTimeout without a queue, semaphore or concurrency cap, then recursively traverses the full DAG using helia.pins.add(cid). The per-pin Helia/Bitswap node in src/create-pinning-helia.ts has no application-level byte, block or traversal-time limits. Blocks are written under carStoragePath by src/core/car/car-blockstore-base.ts and src/core/car/car-file-backend.ts, with stats.totalSize updated only after writing. An authenticated caller, or an anonymous caller when ALLOWNOAUTH=true, can submit large DAGs and exhaust disk, network, CPU, memory and libp2p resources, causing service degradation or host/process failure and leaving partial CAR files requiring recovery. The default localhost binding and token requirement reduce exposure. Because nodes have no bootstrap or mDNS configuration, a CID alone may not be fetchable, but caller-supplied origins can point to a reachable attacker-controlled libp2p source; concurrent requests accelerate resource pressure. Version 1.1.1 documents operational mitigations but does not implement the missing resource controls.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Disable anonymous access by setting ALLOW_NO_AUTH=false so callers must authenticate before submitting DAGs or pins.
ALLOW_NO_AUTH = false
Event History
Frequently Asked Questions
Which deployments are most exposed?
Daemon deployments up to and including version 1.1.0 are affected. Servers exposed beyond localhost, especially those configured with ALLOW_NO_AUTH=true, have the greatest exposure; the default localhost binding and token requirement reduce exposure.
What does an attacker need to exploit this issue?
An attacker needs access to POST /pins and must submit pin requests for large DAGs. A valid authenticated caller can do this, or any caller can do it when ALLOW_NO_AUTH=true.
What can be done while patching is unavailable?
Do not enable ALLOW_NO_AUTH, retain the token requirement, and keep the service bound to localhost where possible. These measures reduce who can submit resource-intensive pin requests, although authenticated callers can still trigger the issue.
How can operators determine whether they may already be affected?
Check whether the deployment is a daemon running version 1.1.0 or earlier and whether POST /pins is reachable by authenticated users or anonymously through ALLOW_NO_AUTH=true. Signs of impact include exhausted disk, network, CPU, memory, or libp2p resources, service degradation or failure, and partial CAR files that require recovery.