NocoDB: Missing File Size Enforcement in Upload-by-URL Allows Denial of Service via Disk Exhaustion

The uploadViaURL path in NocoDB's v1 and v2 attachment API (POST /api/v1/db/storage/upload-by-url and POST /api/v2/storage/upload-by-url) fails to enforce the NC_ATTACHMENT_FIELD_SIZE limit against the remote content-length or during the download stream [1][2]. While the v3 service already checks this limit, the v1/v2 endpoints in packages/nocodb/src/services/attachments.service.ts read the content-length from a HEAD request but never compare it to the configured maximum, and subsequent download via storageAdapter.fileCreateByUrl() occurs without a maxContentLength [1][2].

An authenticated user with at least Editor privileges can exploit this by providing a URL pointing to an arbitrarily large file. The server will download the entire file without any size restriction, consuming disk space rapidly [1][2].

The impact is a denial of service through disk exhaustion. Once the disk is full, cascading failures occur, including blocked database writes, log rotation failures, and potential application crashes [1][2].

This vulnerability is distinct from a previously reported blind SSRF issue (GHSA-xr7v-j379-34v9) in the same code area [1][2]. As of the advisory, no specific patch version is mentioned; users should restrict access to these endpoints or monitor disk usage until an update is applied.