What is the CVSS score of CVE-2026-46551?

CVE-2026-46551 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-46551?

Yes, a patch is available for CVE-2026-46551. Update the affected software to the latest version immediately.

NocoDB CVE-2026-46551

EUVD-2026-38623 MEDIUM

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-05-21 https://github.com/nocodb/nocodb

GHSA-99vc-2jx2-688p

Denial Of Service SSRF

6.5

CVSS 3.1 · Vendor: https://github.com/nocodb/nocodb

Severity by source

Vendor (https://github.com/nocodb/nocodb) PRIMARY

6.5 MEDIUM

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Patch available

Jun 23, 2026 - 23:02 EUVD

Source Code Evidence Fetched

May 21, 2026 - 21:37 vuln.today

Analysis Generated

May 21, 2026 - 21:37 vuln.today

DescriptionCVE.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.