Summary 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. Details 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. Impact - Authenticated DoS via disk exhaustion. Editor role suffices. - Cascading failures once disk fills: blocked DB writes, log rotation, application crash. Credit This issue was reported by "@ik0z" (https://github.com/ik0z).