Filecoin Pin
Monthly
Improper authorization in the Filecoin Pin `upload-action` GitHub Action (versions ≤1.0.1, covering the entire 0.x line and 1.0.x) lets an external fork contributor get arbitrary artifacts produced by their pull request pinned to Filecoin using the repository owner's configured wallet, causing unauthorized storage expenditure, dataset pollution and drainage of wallet funds - without ever learning the wallet private key. The bypass only bites repositories that follow the documented two-workflow pattern, where an untrusted PR workflow builds an artifact and a privileged `workflow_run` workflow downloads and uploads it; the fork check in `upload-action/src/build.js` only inspects `event.pull_request`, which is absent on `workflow_run` events, so `isForkPR` evaluates to false and the upload is allowed to proceed. There is no CISA KEV entry and no confirmed working exploit; a public PoC reference (a sample event/simulation script) exists but is not verified as working exploit code, and no EPSS score was supplied. The vendor fixed the issue in 1.1.0 and explicitly will not backport to 0.x.
Unbounded DAG pinning in the Filecoin Pin pinning daemon through 1.1.0 lets a caller holding a valid access token - or any caller when the server runs with ALLOW_NO_AUTH=true - exhaust disk, network, CPU, memory and libp2p resources by submitting a CID that resolves to a very large DAG, degrading or crashing the process or host and leaving oversized partial CAR files that require manual recovery. The issue is availability-only (CVSS 6.5, C:N/I:N/A:H) and authentication is required per the vector (PR:L); the advisory ships a public PoC request referencing a caller-supplied origins peer, but it is a reference that is not verified as working exploit code, and the CVE is not in CISA KEV. Exploitation is conditional: each per-pin Helia node has no bootstrap or mDNS configuration so a bare CID may not be fetchable, the daemon binds to localhost by default and refuses to start without a token, so realistic exposure is limited to daemons reachable beyond localhost, shared tokens among untrusted users, or deliberately enabled no-auth mode.
Improper authorization in the Filecoin Pin `upload-action` GitHub Action (versions ≤1.0.1, covering the entire 0.x line and 1.0.x) lets an external fork contributor get arbitrary artifacts produced by their pull request pinned to Filecoin using the repository owner's configured wallet, causing unauthorized storage expenditure, dataset pollution and drainage of wallet funds - without ever learning the wallet private key. The bypass only bites repositories that follow the documented two-workflow pattern, where an untrusted PR workflow builds an artifact and a privileged `workflow_run` workflow downloads and uploads it; the fork check in `upload-action/src/build.js` only inspects `event.pull_request`, which is absent on `workflow_run` events, so `isForkPR` evaluates to false and the upload is allowed to proceed. There is no CISA KEV entry and no confirmed working exploit; a public PoC reference (a sample event/simulation script) exists but is not verified as working exploit code, and no EPSS score was supplied. The vendor fixed the issue in 1.1.0 and explicitly will not backport to 0.x.
Unbounded DAG pinning in the Filecoin Pin pinning daemon through 1.1.0 lets a caller holding a valid access token - or any caller when the server runs with ALLOW_NO_AUTH=true - exhaust disk, network, CPU, memory and libp2p resources by submitting a CID that resolves to a very large DAG, degrading or crashing the process or host and leaving oversized partial CAR files that require manual recovery. The issue is availability-only (CVSS 6.5, C:N/I:N/A:H) and authentication is required per the vector (PR:L); the advisory ships a public PoC request referencing a caller-supplied origins peer, but it is a reference that is not verified as working exploit code, and the CVE is not in CISA KEV. Exploitation is conditional: each per-pin Helia node has no bootstrap or mDNS configuration so a bare CID may not be fetchable, the daemon binds to localhost by default and refuses to start without a token, so realistic exposure is limited to daemons reachable beyond localhost, shared tokens among untrusted users, or deliberately enabled no-auth mode.