<?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>Sat, 10 Oct 2026 02:55:41 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-341682</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-341682</link>
      <description>EUVD-2026-341682</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-341682</guid>
    </item>
    <item>
      <title>fkie_cve-2025-71390</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2025-71390</link>
      <description>&lt;p&gt;SurrealDB before 2.2.6, 2.3.6, and 2.1.8 (and 3.0.0-alpha.7 and earlier) fails to validate DNS-resolved hostnames against --deny-net network access restrictions in its http::* functions. An authenticated user can invoke http::&amp;lt;fn&amp;gt;(&amp;lt;url&amp;gt;) with a hostname that resolves to a denied IP address, causing the server to issue the request anyway and return the response. This bypasses network access controls, allowing access to restricted internal endpoints and potentially retrieving or altering sensitive information and credentials, depending on the deployment.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;SurrealDB before 2.2.6, 2.3.6, and 2.1.8 (and 3.0.0-alpha.7 and earlier) fails to validate DNS-resolved hostnames against --deny-net network access restrictions in its http::* functions. An authenticated user can invoke http::&amp;lt;fn&amp;gt;(&amp;lt;url&amp;gt;) with a hostname that resolves to a denied IP address, causing the server to issue the request anyway and return the response. This bypasses network access controls, allowing access to restricted internal endpoints and potentially retrieving or altering sensitive information and credentials, depending on the deployment.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2025-71390</guid>
    </item>
    <item>
      <title>GHSA-m3c3-78fh-w3w7 — SurrealDB allows bypass of deny-net flags via DNS resolution</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-m3c3-78fh-w3w7</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: SurrealDB&lt;/p&gt;
&lt;p&gt;SurrealDB offers http functions that can access external network endpoints. A typical, albeit [not recommended ](https://surrealdb.com/docs/surrealdb/reference-guide/security-best-practices#example-deny-all-capabilities-with-some-exceptions)configuration would be to start SurrealDB with all network connections allowed with the exception of a deny list. For example, `surreal start --allow-net --deny-net 10.0.0.0/8` will allow all network connections except to the 10.0.0.0/8 block.&lt;/p&gt;
&lt;p&gt;An authenticated user of SurrealDB can use bypass this restriction, using `http::&amp;lt;fn&amp;gt;(&amp;lt;url&amp;gt;)` functions where the hostname resolves to an IP within the `--deny-net` block. For example if a SurrealDB administrator wanted to restrict access to other services within a private network and thus set the `--deny-net` to a network IP range, this could be circumvented by an attacker leveraging DNS records and hostname resolution.&lt;/p&gt;
&lt;p&gt;When sending SurrealDB statements containing the `http::*` functions, if the hostname resolves to a forbidden IP, the SurrealDB server will still issue the request and return the responses to the attacker.&lt;/p&gt;
&lt;p&gt;### Impact
The impact of this vulnerability is circumvention of the `--deny-net` capability and resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.&lt;/p&gt;
&lt;p&gt;For example, if the SurrealDB server blocks requests to internal/private IP addresses because those services don’t require authentication, but an attacker can still use…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; crates.io: SurrealDB&lt;/p&gt;
&lt;p&gt;SurrealDB offers http functions that can access external network endpoints. A typical, albeit [not recommended ](https://surrealdb.com/docs/surrealdb/reference-guide/security-best-practices#example-deny-all-capabilities-with-some-exceptions)configuration would be to start SurrealDB with all network connections allowed with the exception of a deny list. For example, `surreal start --allow-net --deny-net 10.0.0.0/8` will allow all network connections except to the 10.0.0.0/8 block.&lt;/p&gt;
&lt;p&gt;An authenticated user of SurrealDB can use bypass this restriction, using `http::&amp;lt;fn&amp;gt;(&amp;lt;url&amp;gt;)` functions where the hostname resolves to an IP within the `--deny-net` block. For example if a SurrealDB administrator wanted to restrict access to other services within a private network and thus set the `--deny-net` to a network IP range, this could be circumvented by an attacker leveraging DNS records and hostname resolution.&lt;/p&gt;
&lt;p&gt;When sending SurrealDB statements containing the `http::*` functions, if the hostname resolves to a forbidden IP, the SurrealDB server will still issue the request and return the responses to the attacker.&lt;/p&gt;
&lt;p&gt;### Impact
The impact of this vulnerability is circumvention of the `--deny-net` capability and resulting impact on systems external to SurrealDB. The ultimate impact is dependent on the deployment scenario.&lt;/p&gt;
&lt;p&gt;For example, if the SurrealDB server blocks requests to internal/private IP addresses because those services don’t require authentication, but an attacker can still use…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-m3c3-78fh-w3w7</guid>
    </item>
  </channel>
</rss>
