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 `ALLOW_NO_AUTH=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 th…

Affected: npm: filecoin-pin

## Summary

The IPFS Pinning Service API implementation accepts a caller-controlled CID through `POST /pins`, queues background processing, and then recursively fetches the full DAG with `helia.pins.add(cid)`. The route and background pinning path do not enforce a request rate limit, per-user quota, maximum DAG byte count, maximum block count, traversal timeout, or concurrent pinning limit.

An authenticated caller, or an unauthenticated caller when the server is started with `ALLOW_NO_AUTH=true`, can submit one or more pins whose CIDs resolve to very large DAGs. The server writes fetched blocks to CAR files under `carStoragePath` and can consume disk, network, CPU, and libp2p resources until the process or host becomes unavailable.

## Details

`POST /pins` validates only that the request body contains a syntactically valid CID string, then forwards it to the pin store:

- `src/filecoin-pinning-server.ts:304-342` accepts the request, parses `cid` with `CID.parse`, and calls `pinStore.pin(request.user, cidObject, parsed.options)`. - `src/filecoin-pin-store.ts:153-188` stores the pin as `queued` and schedules `_processPinInBackground` with `setTimeout`. There is no queue, semaphore, or global cap around this scheduling. - `src/filecoin-pin-store.ts:211-217` creates a per-pin Helia node and forwards caller-supplied `origins`. - `src/filecoin-pin-store.ts:260-274` walks the full DAG with `for await (const pinnedCid of helia.pins.add(cid))`. - `src/create-pinning-helia.ts:47-80`…