<?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>Tue, 06 Oct 2026 20:24:45 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-61726 — Memory exhaustion in query parameter parsing in net/url</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-61726</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go standard library net/url, Red Hat Cryostat 4 on RHEL 9, Red Hat HawtIO HawtIO 4.3.1, Red Hat HawtIO HawtIO 4.4.0, Red Hat Ansible Automation Platform 2.4 for RHEL 8, Red Hat Ansible Automation Platform 2.4 for RHEL 9, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 10, Red Hat Ansible Automation Platform 2.6 for RHEL 9 and 152 more&lt;/p&gt;
&lt;p&gt;The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go standard library net/url, Red Hat Cryostat 4 on RHEL 9, Red Hat HawtIO HawtIO 4.3.1, Red Hat HawtIO HawtIO 4.4.0, Red Hat Ansible Automation Platform 2.4 for RHEL 8, Red Hat Ansible Automation Platform 2.4 for RHEL 9, Red Hat Ansible Automation Platform 2.5 for RHEL 8, Red Hat Ansible Automation Platform 2.5 for RHEL 9, Red Hat Ansible Automation Platform 2.6 for RHEL 10, Red Hat Ansible Automation Platform 2.6 for RHEL 9 and 152 more&lt;/p&gt;
&lt;p&gt;The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-61726</guid>
    </item>
    <item>
      <title>GHSA-hrxh-6v49-42gf — gRPC-Go: xDS RBAC and HTTP/2 Vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hrxh-6v49-42gf</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: google.golang.org/grpc&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:&lt;/p&gt;
&lt;p&gt;- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing `Metadata` or `RequestedServerName` fields.
- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing `NOT` rules around unsupported fields.&lt;/p&gt;
&lt;p&gt;### Impact
_What kind of vulnerability is it? Who is impacted?_&lt;/p&gt;
&lt;p&gt;#### xDS RBAC Authorization Bypass via `Metadata` &amp;amp; `RequestedServerName` matchers&lt;/p&gt;
&lt;p&gt;- Affected Component: xDS RBAC 
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported `permission` and `principal` rules (specifically `Metadata` and `RequestedServerName`) were silently ignored and treated as no-ops.
  - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical `NOT` rules (`Permission_NotRule` / `Principal_NotId`) or multi-condition `OR/AND` rules, silently dropping them changed the boolean logic flow of the authorization engine.&lt;/p&gt;
&lt;p&gt;As a result, policy evaluation decisions could fail open, allowing unauthorized…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: google.golang.org/grpc&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:&lt;/p&gt;
&lt;p&gt;- Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing `Metadata` or `RequestedServerName` fields.
- Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
- Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing `NOT` rules around unsupported fields.&lt;/p&gt;
&lt;p&gt;### Impact
_What kind of vulnerability is it? Who is impacted?_&lt;/p&gt;
&lt;p&gt;#### xDS RBAC Authorization Bypass via `Metadata` &amp;amp; `RequestedServerName` matchers&lt;/p&gt;
&lt;p&gt;- Affected Component: xDS RBAC 
- Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported `permission` and `principal` rules (specifically `Metadata` and `RequestedServerName`) were silently ignored and treated as no-ops.
  - If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
- If these unsupported rules were nested inside logical `NOT` rules (`Permission_NotRule` / `Principal_NotId`) or multi-condition `OR/AND` rules, silently dropping them changed the boolean logic flow of the authorization engine.&lt;/p&gt;
&lt;p&gt;As a result, policy evaluation decisions could fail open, allowing unauthorized…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hrxh-6v49-42gf</guid>
    </item>
  </channel>
</rss>
