The uploadViaURL path in the v1/v2 attachment API did not enforce NC_ATTACHMENT_FIELD_SIZE against the remote content-length or against the response stream. An authenticated user (Editor+) could direct the server to download arbitrarily large files, exhausting disk space and causing denial of service.
In packages/nocodb/src/services/attachments.service.ts, the HEAD probe read content-length but never compared it to NC_ATTACHMENT_FIELD_SIZE; the subsequent storageAdapter.fileCreateByUrl() performed the download without maxContentLength. The v3 service (v3/data-attachment-v3.service.ts) already enforced the limit, but the v1/v2 endpoints (POST /api/v1/db/storage/upload-by-url, POST /api/v2/storage/upload-by-url) did not.
This is distinct from GHSA-xr7v-j379-34v9 (blind SSRF via HEAD) — same code area, different class.
This issue was reported by @ik0z.
No EPSS score in this advisory JSON.
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 6.5 | 3.1 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-99vc-2jx2-688p ↗ |
| CVE | CVE-2026-46551 ↗ |
| CWE id | Name |
|---|---|
| CWE-770 | Allocation of Resources Without Limits or Throttling |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | nocodb | <= 0.301.3 | — | — |