GHSA-99VC-2JX2-688P

Vulnerability from github – Published: 2026-05-21 20:35 – Updated: 2026-05-21 20:35
VLAI
Summary
NocoDB: Missing File Size Enforcement in Upload-by-URL Allows Denial of Service via Disk Exhaustion
Details

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.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "nocodb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.301.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46551"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:35:41Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe `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.\n\n### Details\n\nIn `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.\n\nThis is distinct from GHSA-xr7v-j379-34v9 (blind SSRF via HEAD) \u2014 same code area, different class.\n\n### Impact\n\n- Authenticated DoS via disk exhaustion. Editor role suffices.\n- Cascading failures once disk fills: blocked DB writes, log rotation, application crash.\n\n### Credit\n\nThis issue was reported by [@ik0z](https://github.com/ik0z).",
  "id": "GHSA-99vc-2jx2-688p",
  "modified": "2026-05-21T20:35:41Z",
  "published": "2026-05-21T20:35:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nocodb/nocodb/security/advisories/GHSA-99vc-2jx2-688p"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nocodb/nocodb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NocoDB: Missing File Size Enforcement in Upload-by-URL Allows Denial of Service via Disk Exhaustion"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.