Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

GHSA-8rwr-f68v-cvw6 — nocodb

GHSA-8rwr-f68v-cvw6 is a CWE-770 vulnerability in nocodb. No vendor fix is recorded yet; mitigation options are listed below.

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

Also known asCVE-2026-46553
Published
Updated
Affected
1 pkg
Patched
None yet
Exploits
None indexed
Exploitation data as of Oct 2, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-8rwr-f68v-cvw6.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs32th percentile — riskier than 32% of all scored CVEsHighest risk
0.00%0.30%0.60%0.91%0.4%0.4%0.4%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
nocodbnpm
3Kdownloads / week

Description

Summary

The upload-by-URL path did not enforce NC_ATTACHMENT_FIELD_SIZE against either the remote file's advertised Content-Length or the decoded length of a data: URI, allowing an authenticated user to bypass the configured per-file size limit.

Details

The attachments service now checks NC_ATTACHMENT_FIELD_SIZE against both the HEAD response's content-length and the decoded length of a data: URI body before fetching. The local storage plugin additionally sets maxContentLength on the axios download so a malicious server cannot stream past the limit.

Impact

Authenticated users with upload permission could attach files larger than the operator-configured limit, defeating storage and bandwidth caps.

Credit

This issue was reported by @bugbunny-research.

Affected Packages

1 total
EcosystemPackageVulnerable rangeFix
📦npmnocodball versionsNo fix

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for nocodb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    No patched version of nocodb has shipped for GHSA-8rwr-f68v-cvw6 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Mitigate without a patch

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### Summary The upload-by-URL path did not enforce `NC_ATTACHMENT_FIELD_SIZE` against either the remote file's advertised `Content-Length` or the decoded length of a `data:` URI, allowing an authenticated user to bypass the configured per-file size limit. ### Details The attachments service now checks `NC_ATTACHMENT_FIELD_SIZE` against both the HEAD response's `content-length` and the decoded length of a `data:` URI body before fetching. The local storage plugin additionally sets `maxContentLength` on the axios download so a malicious server cannot stream past the limit. ### Impact Authentic
O3 Security · Impact-Aware SCA

Is GHSA-8rwr-f68v-cvw6 in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
GHSA-8rwr-f68v-cvw6: nocodb | O3 Security