filecoin-project

CVE-2026-62300: CVE-2026-62300: Uncontrolled Resource Consumption in filecoin-pin Daemon CVE-2026-62300: Uncontrolled Resource Consumption in filecoin-pin Daemon > Vulnerability ID: CVE-2026-62300 > CVSS Score: 6.5 > Published: 2026-11-05 CVE-2026-62300 is an uncontrolled resource consumption vulnerability (CWE-400) affecting the daemon mode of filecoin-pin in versions up to and including 1.1.0. The daemon implements the IPFS Pinning Service API to store content on Filecoin's Proof of Data Possession (PDP) service. Due to the absence of rate limits, concurrency caps, execution timeouts, and Directed Acyclic Graph (DAG) traversal limits, an authenticated user—or an unauthenticated user when authentication is disabled—can exhaust system resources via crafted POST /pins requests. TL;DR The filecoin-pin daemon (<= 1.1.0) lacks concurrency controls, rate limits, and DAG size restrictions on the POST /pins endpoint. Each request spawns an isolated Helia/libp2p node and executes an unbounded recursive DAG traversal, writing incoming blocks directly to disk as CAR files. Attackers can trigger denial of service by exhausting disk space, file descriptors, memory, and CPU. --- Technical Details - CVE ID: CVE-2026-62300 (GHSA-m5ph-mmg5-6w5h) - Weakness Class: CWE-400: Uncontrolled Resource Consumption - CVSS v3.1 Score: 6.5 Medium (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) - EPSS Score: 0.25% (16.29th percentile) - Affected Component: filecoin-pin daemon (<= 1.1.0) - Attack Vector: Network via HTTP POST /pins with large DAG CIDs and custom libp2p origins - Primary Impact: Host and process Denial of Service via disk, socket, memory, and CPU exhaustion - CISA KEV Status: Not Listed Affected Systems - filecoin-pin (npm package / CLI daemon mode) - filecoin-pin: <= 1.1.0 (Fixed in: 1.1.1) Code Analysis Commit: 8db22b4 Strengthens the README Beta status block to make clear the pinning server is not intended for production use today, and adds an explicit Known limitations and operational guidance section listing the missing resource controls. File: README.md @@ -64,12 +64,32 @@ Use Filecoin Pin programmatically in your Node.js or browser applications. The l ### 📡 IPFS Pinning Server (Daemon Mode) Run a localhost IPFS Pinning Service API server that implements the [IPFS Pinning Service API specification](https://ipfs.github.io/pinning-services-api-spec/). This allows you to use standard IPFS tooling (like `ipfs pin remote`) while storing data on Filecoin. -- **Status**: Beta. Works and is tested, but hasn't received as many features as the CLI. State is held in memory and is lost across restarts. If it would benefit your use case, please comment on the [tracking issue](https://github.com/filecoin-project/filecoin-pin/issues/46) so we can be better informed when it comes to prioritizing. +- **Status**: ⚠️ **Beta — not intended for production use.** Works and is tested but does not yet have the resource controls or hardening required to safely serve untrusted (or even semi-trusted) callers. State is held in memory and is lost across restarts. Feature parity with the CLI is partial. If running a pinning server would benefit your use case, please comment on the [tracking issue](https://github.com/filecoin-project/filecoin-pin/issues/46) so we can prioritize. - **Repository**: This repo (`filecoin-pin server` command in CLI) - **Usage**: `PRIVATE_KEY=0x... ACCESS_TOKEN=... npx filecoin-pin server` (or use session key auth — see [Configuration](#configuration)) - **Authentication**: The server refuses to start unless an access token is configured via `--access-token` / `ACCESS_TOKEN`. Clients then authenticate with `Authorization: Bearer <token>` on every request except `GET /`. To run the server open to all requests (not recommended), pass `--allow-no-auth` / `ALLOW_NO_AUTH=true`. - **`delegates` is always empty**: Each pin spins up its own short-lived Helia node that is stopped as soon as the pin operation finishes, so there is no long-lived node to advertise. The `delegates` array in pin responses is therefore always `[]`. +#### ⚠️ Known limitations and operational guidance + +The pinning server is currently safe to run only in trusted, single-operator environments. Specifically, **it does not enforce** any of the following: + +- Per-request, per-user, or global rate limits on `POST /pins` +- Per-user quotas (active pins, total bytes pinned, transfer) +- Maximum DAG byte count, block count, or traversal depth +- Traversal timeout / `AbortController` on pin operations +- Concurrency cap across in-flight pin operations +- Filesystem quotas on the configured `CAR_STORAGE_PATH` + +As a result, a single caller can submit a CID resolving to a very large DAG (or supply a reachable `origins` peer that serves one) and exhaust disk, network, CPU, or libp2p resources on the host. Hardening this surface is tracked in [#46](https://github.com/filecoin-project/filecoin-pin/issues/46) and will be a prerequisite for promoting the affordance out of beta. + +Until then, operators should: + +- **Bind to `localhost`** (the default) and never expose the daemon directly to the public internet. +- **Treat the `ACCESS_TOKEN` as a single-tenant secret.** Do not share it across users you don't fully trust to behave well; there's no per-token quota to contain misbehavior. +- **Do not enable `ALLOW_NO_AUTH=true`** outside of disposable local development. +- **Run on a host with bounded storage** (e.g., a dedicated volume) so a runaway pin can't take down other workloads on the same machine. + ### 📊 Management Console GUI Web-based management console for monitoring and managing your Filecoin Pin deployments. This is effectively a Web UI equivalent to the [CLI](#-cli) affordance. Mitigation Strategies - Restrict network exposure by binding the filecoin-pin daemon exclusively to localhost (127.0.0.1). - Enforce strict authentication by requiring a strong ACCESS_TOKEN and never enabling ALLOW_NO_AUTH=true in non-disposable environments. - Treat the bearer token as a single-tenant secret and do not share it across semi-trusted or untrusted users. - Deploy a reverse proxy (e.g., Nginx, Envoy) in front of the daemon to enforce request rate limits and concurrent connection caps on POST /pins. - Isolate CAR_STORAGE_PATH on a dedicated, size-bounded filesystem partition or volume so runaway DAG writes cannot exhaust host root storage. - Constrain the daemon process using systemd or container cgroup limits (MemoryMax, CPUQuota, LimitNOFILE) and schedule periodic cleanup of orphaned .car files. Remediation Steps: 1. Upgrade filecoin-pin to version 1.1.1 or later to ensure alignment with current upstream documentation and operational guidance. 2. Verify daemon startup flags and environment variables to confirm --allow-no-auth / ALLOW_NO_AUTH=true is removed and --host is set to 127.0.0.1. 3. Mount a dedicated, quota-restricted disk volume for CAR_STORAGE_PATH. 4. If remote access is required, place the daemon behind an Nginx reverse proxy configured with limit_req_zone and limit_conn_zone directives targeting the /pins endpoint. 5. Configure a cron job or systemd timer to delete stale partial .car files in CAR_STORAGE_PATH that exceed expected pinning durations. References - GitHub Security Advisory GHSA-m5ph-mmg5-6w5h - Merge commit 8db22b47899deb78dadf415fc477cae4bd6e82c2 documenting limitations and operational guidance - Commit afa019307db23a703737675e94316edcc6572050 in filecoin-pin - filecoin-pin v1.1.1 Release - GitHub Issue #46: Pinning Server Hardening Tracking Issue - NVD Detail for CVE-2026-62300 - CVE.org Record for CVE-2026-62300 - CVEListV5 JSON Record for CVE-2026-62300 --- Read the full report for CVE-2026-62300 on our website for more details including interactive diagrams and full exploit analysis.

What Is Synthos Collective? A Plain-English Guide to the Layer 1 By James Isham Williams, founder of Synthos Collective · October 28, 2026 TL;DR Synthos Collective is an independent Layer 1 blockchain, written in Go, that has run on CometBFT consensus since October 22, 2026. Four validators with equal stake produce a block about every 12 seconds, and each block is final the moment it is committed. Two of those validators are rented servers; the other two are ordinary HP desktops in a home. The native coin is SYN, with a fixed supply of 100 billion. Synthos Collective also posts its block fingerprints to Base, so anyone can check its history against a second, independent chain. The problem: validators live in a few data centers A blockchain is only as independent as the machines that run it. Across the industry, a lot of validators sit with a small number of cloud and hosting companies, so one provider's outage or policy change can hit many of them at once. Synthos Collective is built to test a different setup: validators that run on everyday hardware, next to rented servers, with no single company holding the majority. The node software needs no special rig, and a home validator connects out to the network rather than requiring open ports. How the chain works !How a Synthos Collective block is made Synthos Collective splits the work in two. CometBFT, the consensus engine behind many Cosmos chains, orders and finalizes blocks; a Go application decides what each transaction does to balances and stakes. - Block time: about 12 seconds on average; when idle, the chain still makes a block at least every 10 seconds. - Finality: one block. Once committed, a block is never reversed. - Accounts: Ed25519 keys; an address is the first 20 bytes of the SHA-256 hash of the public key. - Joining as a validator: bond at least 10,000 SYN with a validator_bond transaction. Voting power equals the bond, and the validator set updates every 100 blocks. - Leaving: unbonded SYN unlocks after 86,400 blocks, about 12 days at the current pace. - Penalties: signing two different blocks at the same height costs 5% of the bond and permanently removes the validator. The validator network today Four validators secure Synthos Collective, each with 1,000,000 SYN bonded, so each holds 25% of the voting power. | Validator | Machine | Location | Bond (SYN) | Joined | | --- | --- | --- | --- | --- | | hosteons-validator-1 | Rented VPS | Salt Lake City, US | 1,000,000 | Genesis, Oct 22, 2026 | | jim-pc-validator-1 | Home desktop PC | California, US | 1,000,000 | Genesis, Oct 22, 2026 | | hosteons-validator-ny-1 | Rented VPS | New York, US | 1,000,000 | Block 27,496 | | jim-tower-validator-4 | Home HP tower | California, US | 1,000,000 | Block 33,034 | CometBFT needs more than two-thirds of the voting power to agree on every block. With four equal validators, any one of them can go offline and the other three, at 75%, keep the chain running. If two go down at the same time, block production pauses until one returns; no blocks are lost or reversed. SYN tokenomics !SYN allocation: nearly half of all SYN is set aside for network rewards SYN has a fixed supply of 100 billion, all created at genesis, and nearly half of it is earmarked for rewarding the people who run and use the network. - Founder vesting: 17B SYN unlocks in 10 equal yearly releases of 1.7B, each on May 29. - Founder launch allocation: 500M SYN at launch, for legal work, audits, infrastructure and validators. - Validator rewards (planned): a one-time 10,000 SYN activation reward per approved validator, then 5,000 SYN a month for uptime. - Staking: validators lock SYN as a bond; it stays the owner's and unlocks about 12 days after unbonding. SYN is not listed or traded on any exchange today. Live on Base: the SynthosAnchor contract Synthos Collective records its block fingerprints on Base, Coinbase's Ethereum layer 2, through a small contract called SynthosAnchor. Each record stores a Synthos Collective block height, that block's hash and its state hash, so anyone can check the chain's history against a public ledger that Synthos Collective does not control. - Contract: 0xae4C167ff08d13CaC9b397D13c50904bb9c881a5 on Base mainnet - First record: Synthos Collective block 42,288, written in this transaction on October 28, 2026 - Only one approved relayer can write, and heights must always go up, so old records can't be rewritten - A Synthos Collective server posts a new record automatically every hour SYN itself is not on Base and is not traded on any exchange. The anchor proves history; it doesn't move tokens. Honest status and what's next Synthos Collective is live and producing blocks, but it is early. All four validators are run by the founder today, so the network is spread across machines and locations, not yet across independent operators. Known limits right now: - Both home validators share one home internet connection, and both servers use the same hosting company. Either outage takes down two validators at once and pauses the chain until one is back. - Blocks are mostly empty; there is no outside transaction volume yet. - History from before the October 22 switch to CometBFT, more than 75,000 blocks from the chain's original engine, is kept on a single server. Next up: 1. Bring in outside node operators and validators. 2. Archive the full chain history, both engines, on Filecoin, which is the subject of an open grant proposal. How to get involved - Run a node: the full node is open source; build it from the cometapp folder on GitHub. A step-by-step developer quickstart is coming next. Project site: ishamwilliamsblockchains.com (type the www.). - Read the code: everything is open source under Apache-2.0 on GitHub and GitLab. - Check the chain yourself: the live explorer is at 82-29-54-7.sslip.io, and the Base anchor is on Basescan. - Follow along: @elpresidentejim on X and James Isham Williams on LinkedIn. Sources Figures come from the live Synthos Collective chain (CometBFT status and validator set, read October 28, 2026), the project's TOKENOMICS.md and genesis file, and the SynthosAnchor contract on Basescan. Originally published on GitHub.