https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 04:33:47 +0000 https://cve.radiocsirt.org/vuln/alsa-2026:19135 <p><strong>Affected:</strong> AlmaLinux:10: opentelemetry-collector</p> <p>Collector with the supported components for a AlmaLinux build of OpenTelemetry</p> <p>Security Fix(es):</p> <p>* net/url: Incorrect parsing of IPv6 host literals in net/url (CVE-2026-25679) * google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation (CVE-2026-33186) * github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986) * crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281) * crypto/x509: golang: Go crypto/x509: Certificate validation bypass due to incorrect DNS constraint application (CVE-2026-33810) * golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root (CVE-2026-32282) * crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283) * crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building (CVE-2026-32280)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p><strong>Affected:</strong> AlmaLinux:10: opentelemetry-collector</p> <p>Collector with the supported components for a AlmaLinux build of OpenTelemetry</p> <p>Security Fix(es):</p> <p>* net/url: Incorrect parsing of IPv6 host literals in net/url (CVE-2026-25679) * google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation (CVE-2026-33186) * github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986) * crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281) * crypto/x509: golang: Go crypto/x509: Certificate validation bypass due to incorrect DNS constraint application (CVE-2026-33810) * golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root (CVE-2026-32282) * crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283) * crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building (CVE-2026-32280)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> https://cve.radiocsirt.org/vuln/alsa-2026:19135 https://cve.radiocsirt.org/vuln/bdu:2026-04598 bdu:2026-04598 https://cve.radiocsirt.org/vuln/bdu:2026-04598 https://cve.radiocsirt.org/vuln/bell-cve-2026-33186 <p><strong>Affected:</strong> Alpaquita:stream: docker</p> <p><strong>Affected:</strong> Alpaquita:stream: docker</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-33186 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0366 certfr-2026-avi-0366 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0366 https://cve.radiocsirt.org/vuln/cleanstart-2026-aa33691 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: calico-fips</p> <p>Package calico-fips version 3.28.5-r4 fixes 5 vulnerabilities: CVE-2026-33186, CVE-2026-25679, CVE-2026-27142, CVE-2026-27139, CVE-2025-13281</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: calico-fips</p> <p>Package calico-fips version 3.28.5-r4 fixes 5 vulnerabilities: CVE-2026-33186, CVE-2026-25679, CVE-2026-27142, CVE-2026-27139, CVE-2025-13281</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-aa33691 https://cve.radiocsirt.org/vuln/euvd-2026-371800 EUVD-2026-371800 https://cve.radiocsirt.org/vuln/euvd-2026-371800 https://cve.radiocsirt.org/vuln/fkie_cve-2026-33186 <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers w…</p> <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers w…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-33186 https://cve.radiocsirt.org/vuln/ghsa-p77j-4mvh-x3m3 <p><strong>Affected:</strong> Go: google.golang.org/grpc</p> <p>### Impact _What kind of vulnerability is it? Who is impacted?_</p> <p>It is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.</p> <p>The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present.</p> <p>**Who is impacted?** This affects gRPC-Go servers that meet both of the following criteria: 1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`. 2. Their security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule).</p> <p>The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.</p> <p>### Patches _Has the problem been patched? What versions should users upgrade to?_</p> <p>Yes, the issue has been patched. The fix ensures that any request with a `:path` that does…</p> <p><strong>Affected:</strong> Go: google.golang.org/grpc</p> <p>### Impact _What kind of vulnerability is it? Who is impacted?_</p> <p>It is an **Authorization Bypass** resulting from **Improper Input Validation** of the HTTP/2 `:path` pseudo-header.</p> <p>The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present.</p> <p>**Who is impacted?** This affects gRPC-Go servers that meet both of the following criteria: 1. They use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`. 2. Their security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule).</p> <p>The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server.</p> <p>### Patches _Has the problem been patched? What versions should users upgrade to?_</p> <p>Yes, the issue has been patched. The fix ensures that any request with a `:path` that does…</p> https://cve.radiocsirt.org/vuln/ghsa-p77j-4mvh-x3m3 https://cve.radiocsirt.org/vuln/msrc_cve-2026-33186 msrc_CVE-2026-33186 https://cve.radiocsirt.org/vuln/msrc_cve-2026-33186 https://cve.radiocsirt.org/vuln/ncsc-2026-0306 NCSC-2026-0306 https://cve.radiocsirt.org/vuln/ncsc-2026-0306 https://cve.radiocsirt.org/vuln/oesa-2026-1866 <p><strong>Affected:</strong> openEuler:24.03-LTS-SP3: kata-containers-go</p> <p>This is core component of Kata Container, to make it work, you need a isulad/docker engine. Security Fix(es):</p> <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &amp;quot;deny&amp;quot; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &amp;quot;allow&amp;quot; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &amp;quot;deny&amp;quot; rules for canonical paths but allows other requests by default (a fallback &amp;quot;allow&amp;quot; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not s…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS-SP3: kata-containers-go</p> <p>This is core component of Kata Container, to make it work, you need a isulad/docker engine. Security Fix(es):</p> <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &amp;quot;deny&amp;quot; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &amp;quot;allow&amp;quot; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &amp;quot;deny&amp;quot; rules for canonical paths but allows other requests by default (a fallback &amp;quot;allow&amp;quot; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not s…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1866 https://cve.radiocsirt.org/vuln/opensuse-ru-2026:21160-1 <p>Recommended update for dnscrypt-proxy</p> <p>Recommended update for dnscrypt-proxy</p> https://cve.radiocsirt.org/vuln/opensuse-ru-2026:21160-1 https://cve.radiocsirt.org/vuln/rhsa-2026:10093 <p>ajv: ReDoS via $data reference google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation</p> <p>ajv: ReDoS via $data reference google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation</p> https://cve.radiocsirt.org/vuln/rhsa-2026:10093 https://cve.radiocsirt.org/vuln/rlsa-2026:19135 <p><strong>Affected:</strong> Rocky Linux:10: opentelemetry-collector</p> <p>Collector with the supported components for a Rocky Enterprise Software Foundation build of OpenTelemetry</p> <p>Security Fix(es):</p> <p>* net/url: Incorrect parsing of IPv6 host literals in net/url (CVE-2026-25679)</p> <p>* google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation (CVE-2026-33186)</p> <p>* github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986)</p> <p>* crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281)</p> <p>* crypto/x509: golang: Go crypto/x509: Certificate validation bypass due to incorrect DNS constraint application (CVE-2026-33810)</p> <p>* golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root (CVE-2026-32282)</p> <p>* crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283)</p> <p>* crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building (CVE-2026-32280)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p><strong>Affected:</strong> Rocky Linux:10: opentelemetry-collector</p> <p>Collector with the supported components for a Rocky Enterprise Software Foundation build of OpenTelemetry</p> <p>Security Fix(es):</p> <p>* net/url: Incorrect parsing of IPv6 host literals in net/url (CVE-2026-25679)</p> <p>* google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation (CVE-2026-33186)</p> <p>* github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object (CVE-2026-34986)</p> <p>* crypto/x509: golang: Go crypto/x509: Denial of Service via inefficient certificate chain validation (CVE-2026-32281)</p> <p>* crypto/x509: golang: Go crypto/x509: Certificate validation bypass due to incorrect DNS constraint application (CVE-2026-33810)</p> <p>* golang: internal/syscall/unix: Root.Chmod can follow symlinks out of the root (CVE-2026-32282)</p> <p>* crypto/tls: golang: Go crypto/tls: Denial of Service via multiple TLS 1.3 key update messages (CVE-2026-32283)</p> <p>* crypto/x509: crypto/tls: golang: Go: Denial of Service vulnerability in certificate chain building (CVE-2026-32280)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> https://cve.radiocsirt.org/vuln/rlsa-2026:19135 https://cve.radiocsirt.org/vuln/suse-su-2026:1195-1 <p>Security update for google-cloud-sap-agent</p> <p>Security update for google-cloud-sap-agent</p> https://cve.radiocsirt.org/vuln/suse-su-2026:1195-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33186 <p><strong>Affected:</strong> Ubuntu:16.04:LTS: golang-google-grpc, Ubuntu:Pro:16.04:LTS: google-guest-agent, Ubuntu:18.04:LTS: golang-google-grpc, Ubuntu:Pro:18.04:LTS: google-guest-agent, Ubuntu:Pro:20.04:LTS: google-guest-agent, Ubuntu:20.04:LTS: golang-google-grpc, Ubuntu:22.04:LTS: golang-google-grpc, Ubuntu:22.04:LTS: google-guest-agent, Ubuntu:24.04:LTS: google-guest-agent, Ubuntu:Pro:24.04:LTS: golang-google-grpc and 4 more</p> <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers w…</p> <p><strong>Affected:</strong> Ubuntu:16.04:LTS: golang-google-grpc, Ubuntu:Pro:16.04:LTS: google-guest-agent, Ubuntu:18.04:LTS: golang-google-grpc, Ubuntu:Pro:18.04:LTS: google-guest-agent, Ubuntu:Pro:20.04:LTS: google-guest-agent, Ubuntu:20.04:LTS: golang-google-grpc, Ubuntu:22.04:LTS: golang-google-grpc, Ubuntu:22.04:LTS: google-guest-agent, Ubuntu:24.04:LTS: google-guest-agent, Ubuntu:Pro:24.04:LTS: golang-google-grpc and 4 more</p> <p>gRPC-Go is the Go language implementation of gRPC. Versions prior to 1.79.3 have an authorization bypass resulting from improper input validation of the HTTP/2 `:path` pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the `:path` omitted the mandatory leading slash (e.g., `Service/Method` instead of `/Service/Method`). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official `grpc/authz` package) evaluated the raw, non-canonical path string. Consequently, &#34;deny&#34; rules defined using canonical paths (starting with `/`) failed to match the incoming request, allowing it to bypass the policy if a fallback &#34;allow&#34; rule was present. This affects gRPC-Go servers that use path-based authorization interceptors, such as the official RBAC implementation in `google.golang.org/grpc/authz` or custom interceptors relying on `info.FullMethod` or `grpc.Method(ctx)`; AND that have a security policy contains specific &#34;deny&#34; rules for canonical paths but allows other requests by default (a fallback &#34;allow&#34; rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed `:path` headers directly to the gRPC server. The fix in version 1.79.3 ensures that any request with a `:path` that does not start with a leading slash is immediately rejected with a `codes.Unimplemented` error, preventing it from reaching authorization interceptors or handlers w…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-33186 https://cve.radiocsirt.org/vuln/vde-2026-088 <p>The vulnerabilities found in LabX Standard versions 21.3.22 - 21.4.23 are CVE-2025-69419, CVE-2026-0915, CVE-2025-15467, CVE-2026-4800, CVE-2026-33186, CVE-2026-39821, CVE-2026-33671 and are fixed in LabX Standard v21.4.25.</p> <p>The vulnerabilities found in LabX Enterprise versions 21.3.22 - 21.4.23 are CVE-2026-4800, CVE-2026-33186, CVE-2026-39821, CVE-2026-33671 and are fixed in LabX Enterprise v21.4.25</p> <p>All other vulnerabilities are to be fixed in the upcoming releases.</p> <p>The vulnerabilities found in LabX Standard versions 21.3.22 - 21.4.23 are CVE-2025-69419, CVE-2026-0915, CVE-2025-15467, CVE-2026-4800, CVE-2026-33186, CVE-2026-39821, CVE-2026-33671 and are fixed in LabX Standard v21.4.25.</p> <p>The vulnerabilities found in LabX Enterprise versions 21.3.22 - 21.4.23 are CVE-2026-4800, CVE-2026-33186, CVE-2026-39821, CVE-2026-33671 and are fixed in LabX Enterprise v21.4.25</p> <p>All other vulnerabilities are to be fixed in the upcoming releases.</p> https://cve.radiocsirt.org/vuln/vde-2026-088 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1136 <p>Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Red Hat OpenShift Container Platform ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> <p>Ein entfernter, authentisierter Angreifer kann eine Schwachstelle in Red Hat OpenShift Container Platform ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1136