<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 05 Oct 2026 12:49:44 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-331001</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-331001</link>
      <description>EUVD-2026-331001</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-331001</guid>
    </item>
    <item>
      <title>fkie_cve-2026-54353</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-54353</link>
      <description>&lt;p&gt;Budibase is an open-source low-code platform. Prior to 3.39.9, authenticated users with automation permissions can bypass Budibase&amp;#39;s SSRF blacklist through DNS rebinding. The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection. This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints. This vulnerability is fixed in 3.39.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Budibase is an open-source low-code platform. Prior to 3.39.9, authenticated users with automation permissions can bypass Budibase&amp;#39;s SSRF blacklist through DNS rebinding. The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection. This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints. This vulnerability is fixed in 3.39.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-54353</guid>
    </item>
    <item>
      <title>GHSA-gfq7-5x4g-3xhf — @budibase/backend-core has potential SSRF DNS rebinding bypass in outbound fetch validation</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-gfq7-5x4g-3xhf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @budibase/backend-core&lt;/p&gt;
&lt;p&gt;Summary&lt;/p&gt;
&lt;p&gt;Authenticated users with automation permissions can bypass Budibase&amp;#39;s SSRF blacklist through DNS rebinding.&lt;/p&gt;
&lt;p&gt;The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.&lt;/p&gt;
&lt;p&gt;This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.&lt;/p&gt;
&lt;p&gt;Details&lt;/p&gt;
&lt;p&gt;The issue comes from the outbound fetch validation flow resolving DNS twice:&lt;/p&gt;
&lt;p&gt;During blacklist validation
Again during the real socket connection&lt;/p&gt;
&lt;p&gt;The first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.&lt;/p&gt;
&lt;p&gt;This creates a classic TOCTOU DNS rebinding issue.&lt;/p&gt;
&lt;p&gt;Affected flow in:&lt;/p&gt;
&lt;p&gt;packages/backend-core/src/utils/outboundFetch.ts
```
async function throwIfUnsafe(url: string): Promise&amp;lt;void&amp;gt; {
  const parsed = parseUrl(url)&lt;/p&gt;
&lt;p&gt;if (await isBlacklisted(parsed.hostname)) {
    throw new Error(&amp;#34;URL is blocked or could not be resolved safely.&amp;#34;)
  }
}&lt;/p&gt;
&lt;p&gt;for (let redirects = 0; redirects &amp;lt;= MAX_REDIRECTS; redirects++) {
  await throwIfUnsafe(nextUrl)&lt;/p&gt;
&lt;p&gt;const response = await fetchFn(nextUrl, nextRequest)&lt;/p&gt;
&lt;p&gt;// ...
}
```
fetchFn uses plain node-fetch with no custom http.Agent /…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; npm: @budibase/backend-core&lt;/p&gt;
&lt;p&gt;Summary&lt;/p&gt;
&lt;p&gt;Authenticated users with automation permissions can bypass Budibase&amp;#39;s SSRF blacklist through DNS rebinding.&lt;/p&gt;
&lt;p&gt;The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection.&lt;/p&gt;
&lt;p&gt;This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints.&lt;/p&gt;
&lt;p&gt;Details&lt;/p&gt;
&lt;p&gt;The issue comes from the outbound fetch validation flow resolving DNS twice:&lt;/p&gt;
&lt;p&gt;During blacklist validation
Again during the real socket connection&lt;/p&gt;
&lt;p&gt;The first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP.&lt;/p&gt;
&lt;p&gt;This creates a classic TOCTOU DNS rebinding issue.&lt;/p&gt;
&lt;p&gt;Affected flow in:&lt;/p&gt;
&lt;p&gt;packages/backend-core/src/utils/outboundFetch.ts
```
async function throwIfUnsafe(url: string): Promise&amp;lt;void&amp;gt; {
  const parsed = parseUrl(url)&lt;/p&gt;
&lt;p&gt;if (await isBlacklisted(parsed.hostname)) {
    throw new Error(&amp;#34;URL is blocked or could not be resolved safely.&amp;#34;)
  }
}&lt;/p&gt;
&lt;p&gt;for (let redirects = 0; redirects &amp;lt;= MAX_REDIRECTS; redirects++) {
  await throwIfUnsafe(nextUrl)&lt;/p&gt;
&lt;p&gt;const response = await fetchFn(nextUrl, nextRequest)&lt;/p&gt;
&lt;p&gt;// ...
}
```
fetchFn uses plain node-fetch with no custom http.Agent /…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-gfq7-5x4g-3xhf</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1806 — Budibase: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1806</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Budibase ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um Dateien zu manipulieren.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Budibase ausnutzen, um Sicherheitsvorkehrungen zu umgehen, und um Dateien zu manipulieren.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1806</guid>
    </item>
  </channel>
</rss>
