EUVD-2026-38623
GHSA-99vc-2jx2-688p
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Primary rating from Vendor (https://github.com/nocodb/nocodb) · only source for this CVE.
CVSS VectorVendor: https://github.com/nocodb/nocodb
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Lifecycle Timeline
3DescriptionCVE.org
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.
AnalysisAI
Disk exhaustion denial of service in NocoDB's v1/v2 attachment upload-by-URL API allows authenticated users with Editor-level privileges or higher to direct the server to fetch arbitrarily large remote files, consuming all available disk space. The root cause is missing enforcement of the NC_ATTACHMENT_FIELD_SIZE configuration limit in attachments.service.ts for the v1/v2 code paths, despite the v3 equivalent already implementing the constraint correctly. Cascading failures follow disk exhaustion: database writes block, log rotation fails, and the application itself may crash - making this a high-availability-impact issue for any NocoDB deployment with untrusted authenticated users.
Technical ContextAI
NocoDB (npm package nocodb, CPE: pkg:npm/nocodb) is an open-source no-code database platform. The vulnerability resides in packages/nocodb/src/services/attachments.service.ts, specifically in the uploadViaURL handler. The code performs a HEAD request to the remote URL to read the Content-Length header but never compares that value against the NC_ATTACHMENT_FIELD_SIZE configuration limit. The subsequent call to storageAdapter.fileCreateByUrl() then streams the remote file to disk without a maxContentLength guard, meaning an arbitrarily large response body is written in full. This is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) - a resource consumption vulnerability where server-side operations lack upper bounds on externally-influenced inputs. The v3 attachment service (v3/data-attachment-v3.service.ts) correctly enforces the size limit, confirming the fix pattern was already established but not back-ported to the v1/v2 endpoints (POST /api/v1/db/storage/upload-by-url and POST /api/v2/storage/upload-by-url). This is explicitly noted as distinct from GHSA-xr7v-j379-34v9, which covers blind SSRF via the HEAD probe in the same code area.
RemediationAI
No vendor-released patch has been identified at time of analysis - the advisory lists no fixed version for npm/nocodb. Operators should apply the following compensating controls until a patch is available. First, restrict the upload-by-URL endpoints at the reverse proxy or WAF layer: block or rate-limit POST requests to paths matching /api/v1/db/storage/upload-by-url and /api/v2/storage/upload-by-url for all users who do not strictly require the feature; this eliminates the attack surface but disables URL-based attachment uploads for those users. Second, enforce a disk quota or filesystem-level limit on the directory used by NocoDB's storage adapter, so that a fill attack cannot consume the entire host disk; note this causes upload failures rather than preventing the attack attempt, and may still degrade application stability. Third, reduce the Editor role grant to only fully trusted users, limiting the pool of accounts that can invoke the vulnerable endpoints. Monitor disk utilization on NocoDB hosts and set alerts at threshold levels (e.g., 80% capacity) to detect exploitation attempts early. Track the upstream advisory at https://github.com/nocodb/nocodb/security/advisories/GHSA-99vc-2jx2-688p for patch release.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today