<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-07T09:28:13.169921+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-329824</id>
    <title>EUVD-2026-329824</title>
    <updated>2026-10-07T09:28:13.172033+00:00</updated>
    <content>EUVD-2026-329824</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-329824"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-46551</id>
    <title>fkie_cve-2026-46551</title>
    <updated>2026-10-07T09:28:13.172067+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>NocoDB is software for building databases as spreadsheets. Prior to 2026.04.4, 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. 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. This vulnerability is fixed in 2026.04.4.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-46551"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-99vc-2jx2-688p</id>
    <title>GHSA-99vc-2jx2-688p — NocoDB: Missing File Size Enforcement in Upload-by-URL Allows Denial of Service via Disk Exhaustion</title>
    <updated>2026-10-07T09:28:13.172100+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> npm: nocodb</p>
<p>### Summary</p>
<p>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.</p>
<p>### Details</p>
<p>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.</p>
<p>This is distinct from GHSA-xr7v-j379-34v9 (blind SSRF via HEAD) — same code area, different class.</p>
<p>### Impact</p>
<p>- Authenticated DoS via disk exhaustion. Editor role suffices.
- Cascading failures once disk fills: blocked DB writes, log rotation, application crash.</p>
<p>### Credit</p>
<p>This issue was reported by [@ik0z](https://github.com/ik0z).</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-99vc-2jx2-688p"/>
  </entry>
</feed>
