<?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 23:34:21 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-22771 — Envoy Extension Policy lua scripts injection causes arbitrary command execution</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2026-22771</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; envoyproxy gateway, Red Hat Connectivity Link 1&lt;/p&gt;
&lt;p&gt;Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.5.7 and 1.6.2, EnvoyExtensionPolicy Lua scripts executed by Envoy proxy can be used to leak the proxy&amp;#39;s credentials. These credentials can then be used to communicate with the control plane and gain access to all secrets that are used by Envoy proxy, e.g. TLS private keys and credentials used for downstream and upstream communication. This vulnerability is fixed in 1.5.7 and 1.6.2.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; envoyproxy gateway, Red Hat Connectivity Link 1&lt;/p&gt;
&lt;p&gt;Envoy Gateway is an open source project for managing Envoy Proxy as a standalone or Kubernetes-based application gateway. Prior to 1.5.7 and 1.6.2, EnvoyExtensionPolicy Lua scripts executed by Envoy proxy can be used to leak the proxy&amp;#39;s credentials. These credentials can then be used to communicate with the control plane and gain access to all secrets that are used by Envoy proxy, e.g. TLS private keys and credentials used for downstream and upstream communication. This vulnerability is fixed in 1.5.7 and 1.6.2.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2026-22771</guid>
    </item>
    <item>
      <title>GHSA-22xc-xg2r-9j7v — Envoy Gateway: xDS Control Plane Information Disclosure when operating in GatewayNamespaceMode</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-22xc-xg2r-9j7v</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/envoyproxy/gateway&lt;/p&gt;
&lt;p&gt;### Impact
When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated.&lt;/p&gt;
&lt;p&gt;Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication.&lt;/p&gt;
&lt;p&gt;Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access:&lt;/p&gt;
&lt;p&gt;* TLS private keys via StreamSecrets (SDS)
* All xDS resources via StreamAggregatedResources (ADS)
* Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS)
* Routing rules via StreamRoutes / StreamListeners (RDS/LDS)&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/envoyproxy/gateway&lt;/p&gt;
&lt;p&gt;### Impact
When Envoy Gateway runs in GatewayNamespaceMode (`provider.kubernetes.deploy.type=GatewayNamespace`), the xDS gRPC server is configured with a `StreamInterceptor` for JWT authentication but no UnaryInterceptor. The go-control-plane xDS server exposes both streaming and unary (Fetch) RPC methods for all registered discovery services. Since there is no unary interceptor, these Fetch endpoints are completely unauthenticated.&lt;/p&gt;
&lt;p&gt;Additionally, the JWT authentication interceptor in GatewayNamespaceMode only validates tokens when the received gRPC message is of type `discoveryv3.DeltaDiscoveryRequest` . If the message is a `discoveryv3.DiscoveryRequest` — used by the State-of-the-World (SotW) xDS protocol — the type assertion fails, the validation block is skipped entirely, and RecvMsg returns nil (success) without any authentication.&lt;/p&gt;
&lt;p&gt;Any pod in the cluster that can reach the xDS server (port 18000) can use the SotW protocol to bypass JWT authentication and access:&lt;/p&gt;
&lt;p&gt;* TLS private keys via StreamSecrets (SDS)
* All xDS resources via StreamAggregatedResources (ADS)
* Backend endpoints via StreamClusters / StreamEndpoints (CDS/EDS)
* Routing rules via StreamRoutes / StreamListeners (RDS/LDS)&lt;/p&gt;
&lt;p&gt;### Credits&lt;/p&gt;
&lt;p&gt;Envoy Gateway thanks @dashingDragon and @Donjon-Cerberus for reporting this issue.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-22xc-xg2r-9j7v</guid>
    </item>
  </channel>
</rss>
