CVE-2026-62300: missing rate limits allow resource

CISO Take

Filecoin Pin, an IPFS Pinning Service implementation, lets any authenticated caller submit pin requests with no rate limit, quota or concurrency cap, so a single user can make the server fetch huge DAGs and exhaust disk, CPU, memory and network. The CVSS score is a medium 6.5 and it is availability-only: there is no data exposure or code execution. There is no EPSS score, no public exploit, no Nuclei template and no CISA KEV listing, so near-term exploitation likelihood looks low. Exposure is further limited by the default localhost binding and token requirement, but deployments that set ALLOW_NO_AUTH=true or expose the daemon publicly are at real risk, and attackers can use caller-supplied origins to point the node at an attacker-controlled libp2p source. Version 1.1.1 only documents operational mitigations and does not fix the missing controls, so apply compensating controls now: put the service behind a reverse proxy with rate limiting, disable ALLOW_NO_AUTH, enforce disk quotas on carStoragePath, and run it with container CPU and memory limits.

Sources:NVDGitHub AdvisoryATLAS

What is the risk?

Medium. The attack is network-reachable, low complexity and needs only low privileges (a valid token, or none when ALLOW_NO_AUTH=true), and it impacts availability only. Real-world risk depends on exposure: the default localhost binding and token requirement reduce it substantially. The fetch needs a reachable source, either via attacker-controlled origins or already-public content. Upstream has not implemented a code fix, so the exposure persists in 1.1.1. No exploitation is known: EPSS is unavailable, there is no public exploit and it is not in KEV.

How does the attack unfold?

Initial Access

Attacker authenticates with a low-privilege token, or connects anonymously when ALLOW_NO_AUTH=true.

AML.T0049

Exploitation

Attacker submits many concurrent POST /pins requests for large DAGs with origins pointing to an attacker-controlled libp2p node.

AML.T0034.001

Impact

Unbounded background traversals exhaust disk, CPU, memory and network, leaving partial CAR files and degrading or crashing the service.

AML.T0029

Initial Access

Attacker authenticates with a low-privilege token, or connects anonymously when ALLOW_NO_AUTH=true.

AML.T0049

Exploitation

Attacker submits many concurrent POST /pins requests for large DAGs with origins pointing to an attacker-controlled libp2p node.

AML.T0034.001

Impact

Unbounded background traversals exhaust disk, CPU, memory and network, leaving partial CAR files and degrading or crashing the service.

AML.T0029

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 16% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CNone

INone

AHigh

What should I do?

1 step

1) Upgrade to 1.1.1 and follow its documented operational mitigations, noting it does not add the missing code-level limits. 2) Never set ALLOW_NO_AUTH=true on reachable hosts; keep the default localhost binding or restrict access with network ACLs. 3) Front the API with a reverse proxy or WAF that enforces per-token rate limits and request quotas on POST /pins. 4) Put carStoragePath on a dedicated volume with a disk quota, and run the service in a container or cgroup with CPU, memory and file descriptor limits. 5) Monitor disk usage, outbound bandwidth, the number of concurrent pin jobs and process restarts, and alert on spikes. 6) Rotate and tightly scope API tokens, and clean up partial CAR files after incidents. 7) Review the vendor advisory GHSA-m5ph-mmg5-6w5h and watch for a release that adds resource controls.

How is it classified?

DoSFrameworkAPIAML.T0012- Valid Accounts AML.T0029- Denial of AI Service AML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to unknown risks and system failures

Frequently Asked Questions

What is CVE-2026-62300?

Filecoin Pin, an IPFS Pinning Service implementation, lets any authenticated caller submit pin requests with no rate limit, quota or concurrency cap, so a single user can make the server fetch huge DAGs and exhaust disk, CPU, memory and network. The CVSS score is a medium 6.5 and it is availability-only: there is no data exposure or code execution. There is no EPSS score, no public exploit, no Nuclei template and no CISA KEV listing, so near-term exploitation likelihood looks low. Exposure is further limited by the default localhost binding and token requirement, but deployments that set ALLOW_NO_AUTH=true or expose the daemon publicly are at real risk, and attackers can use caller-supplied origins to point the node at an attacker-controlled libp2p source. Version 1.1.1 only documents operational mitigations and does not fix the missing controls, so apply compensating controls now: put the service behind a reverse proxy with rate limiting, disable ALLOW_NO_AUTH, enforce disk quotas on carStoragePath, and run it with container CPU and memory limits.

Is CVE-2026-62300 actively exploited?

No confirmed active exploitation of CVE-2026-62300 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-62300?

1) Upgrade to 1.1.1 and follow its documented operational mitigations, noting it does not add the missing code-level limits. 2) Never set ALLOW_NO_AUTH=true on reachable hosts; keep the default localhost binding or restrict access with network ACLs. 3) Front the API with a reverse proxy or WAF that enforces per-token rate limits and request quotas on POST /pins. 4) Put carStoragePath on a dedicated volume with a disk quota, and run the service in a container or cgroup with CPU, memory and file descriptor limits. 5) Monitor disk usage, outbound bandwidth, the number of concurrent pin jobs and process restarts, and alert on spikes. 6) Rotate and tightly scope API tokens, and clean up partial CAR files after incidents. 7) Review the vendor advisory GHSA-m5ph-mmg5-6w5h and watch for a release that adds resource controls.

What systems are affected by CVE-2026-62300?

This vulnerability affects the following AI/ML architecture patterns: decentralized storage pipelines, data and model artifact archival services, IPFS pinning services.

What is the CVSS score for CVE-2026-62300?

CVE-2026-62300 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.25%.

What is the AI security impact?

Affected AI Architectures

decentralized storage pipelinesdata and model artifact archival servicesIPFS pinning services

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0029Denial of AI Service

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

What are the technical details?

Original Advisory

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 the missing resource controls.

Exploitation Scenario

An attacker with a valid low-privilege token, or anonymous access on a misconfigured instance with ALLOW_NO_AUTH=true, hosts a libp2p node that serves a very large or infinitely branching DAG. They then send many concurrent POST /pins requests with that CID and origins pointing to their node. Each pin spawns an unbounded background traversal that downloads blocks into carStoragePath, quickly exhausting disk, bandwidth, CPU and memory. The service degrades or crashes, interrupting dependent storage and data pipelines and leaving partial CAR files to be cleaned up.

Weaknesses (CWE)

CWE-400Uncontrolled Resource ConsumptionPrimary CWE-400Uncontrolled Resource Consumption

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.