NocoDB: Attachment Size Limit Bypass via Upload-by-URL

What the vulnerability is

The upload-by-URL path in NocoDB's attachments service did not validate the NC_ATTACHMENT_FIELD_SIZE configuration against the remote file's advertised Content-Length (from a HEAD response) or the decoded length of a data: URI. This allowed an authenticated user to bypass the operator-configured per-file size limit [1][2]. The root cause is a missing size check in the upload-by-URL logic before fetching the remote content.

How it is exploited

An authenticated user with upload permission can provide a URL pointing to a file larger than the configured NC_ATTACHMENT_FIELD_SIZE limit, or craft a data: URI that decodes to a similarly oversized payload. Without proper enforcement, the system proceeds to fetch and store the file, ignoring the size constraints [1][2]. Exploitation requires only a valid user account with file upload privileges.

Impact

By attaching files that exceed the configured limit, an attacker can defeat storage and bandwidth caps imposed by the operator. This could lead to excessive disk usage, increased network transfer costs, and potential denial of service through resource exhaustion [1][2].

Mitigation

The vulnerability has been addressed in a security advisory. The fix ensures that the attachments service checks NC_ATTACHMENT_FIELD_SIZE against both the HEAD response's Content-Length and the decoded length of data: URIs before fetching. Additionally, the local storage plugin now sets maxContentLength on the axios download to prevent a malicious server from streaming data past the limit [1][2]. Users should update to a patched version as recommended by the vendor.