<?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>Wed, 07 Oct 2026 02:20:41 +0000</lastBuildDate>
    <item>
      <title>BIT-envoy-2023-27488 — Envoy gRPC client produces invalid protobuf when an HTTP header with non-UTF8 value is received.</title>
      <link>https://cve.radiocsirt.org/vuln/bit-envoy-2023-27488</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: envoy&lt;/p&gt;
&lt;p&gt;Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, escalation of privileges is possible when `failure_mode_allow: true` is configured for `ext_authz` filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.&lt;/p&gt;
&lt;p&gt;When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforeseen errors such as a lack of visibility into requests.&lt;/p&gt;
&lt;p&gt;As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy by default sanitizes the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a `!` character. This behavioral change can be temporarily reverted by setting runtime guard `envoy.reloadable_features.service_sanitize_non_utf8_strings` to false. As a workaround, one may set `failure_mode_allow: false` for `ext_authz`.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: envoy&lt;/p&gt;
&lt;p&gt;Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, escalation of privileges is possible when `failure_mode_allow: true` is configured for `ext_authz` filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.&lt;/p&gt;
&lt;p&gt;When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforeseen errors such as a lack of visibility into requests.&lt;/p&gt;
&lt;p&gt;As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy by default sanitizes the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a `!` character. This behavioral change can be temporarily reverted by setting runtime guard `envoy.reloadable_features.service_sanitize_non_utf8_strings` to false. As a workaround, one may set `failure_mode_allow: false` for `ext_authz`.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bit-envoy-2023-27488</guid>
    </item>
    <item>
      <title>EUVD-2026-214696</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-214696</link>
      <description>EUVD-2026-214696</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-214696</guid>
    </item>
    <item>
      <title>fkie_cve-2023-27488</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-27488</link>
      <description>&lt;p&gt;Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, escalation of privileges is possible when `failure_mode_allow: true` is configured for `ext_authz` filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.&lt;/p&gt;
&lt;p&gt;When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforeseen errors such as a lack of visibility into requests.&lt;/p&gt;
&lt;p&gt;As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy by default sanitizes the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a `!` character. This behavioral change can be temporarily reverted by setting runtime guard `envoy.reloadable_features.service_sanitize_non_utf8_strings` to false. As a workaround, one may set `failure_mode_allow: false` for `ext_authz`.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, escalation of privileges is possible when `failure_mode_allow: true` is configured for `ext_authz` filter. For affected components that are used for logging and/or visibility, requests may not be logged by the receiving service.&lt;/p&gt;
&lt;p&gt;When Envoy was configured to use ext_authz, ext_proc, tap, ratelimit filters, and grpc access log service and an http header with non-UTF-8 data was received, Envoy would generate an invalid protobuf message and send it to the configured service. The receiving service would typically generate an error when decoding the protobuf message. For ext_authz that was configured with ``failure_mode_allow: true``, the request would have been allowed in this case. For the other services, this could have resulted in other unforeseen errors such as a lack of visibility into requests.&lt;/p&gt;
&lt;p&gt;As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy by default sanitizes the values sent in gRPC service calls to be valid UTF-8, replacing data that is not valid UTF-8 with a `!` character. This behavioral change can be temporarily reverted by setting runtime guard `envoy.reloadable_features.service_sanitize_non_utf8_strings` to false. As a workaround, one may set `failure_mode_allow: false` for `ext_authz`.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-27488</guid>
    </item>
    <item>
      <title>gsd-2023-27488</title>
      <link>https://cve.radiocsirt.org/vuln/gsd-2023-27488</link>
      <description>gsd-2023-27488</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/gsd-2023-27488</guid>
    </item>
    <item>
      <title>RHSA-2023:4623 — Red Hat Security Advisory: Red Hat OpenShift Service Mesh 2.2.9  security update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2023:4623</link>
      <description>&lt;p&gt;envoy: Client may fake the header `x-envoy-original-path` envoy: gRPC client produces invalid protobuf when an HTTP header with non-UTF8 value is received envoy: Envoy forwards invalid HTTP/2 and HTTP/3 downstream envoy: Crash when a large request body is processed in Lua filter envoy: envoy doesn&amp;#39;t escape HTTP header values envoy: Crash when a redirect url without a state param is received in the oauth filter&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;envoy: Client may fake the header `x-envoy-original-path` envoy: gRPC client produces invalid protobuf when an HTTP header with non-UTF8 value is received envoy: Envoy forwards invalid HTTP/2 and HTTP/3 downstream envoy: Crash when a large request body is processed in Lua filter envoy: envoy doesn&amp;#39;t escape HTTP header values envoy: Crash when a redirect url without a state param is received in the oauth filter&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2023:4623</guid>
    </item>
    <item>
      <title>WID-SEC-W-2023-2058 — Red Hat OpenShift Service Mesh und Service Mesh Containers: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2058</link>
      <description>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Red Hat OpenShift Service Mesh und Service Mesh Containers, sowie Red Hat Enterprise Linux ausnutzen, um einen Denial of Service Zustand herbeizuführen, Dateien zu manipulieren, Sicherheitsvorkehrungen zu umgehen oder Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in Red Hat OpenShift Service Mesh und Service Mesh Containers, sowie Red Hat Enterprise Linux ausnutzen, um einen Denial of Service Zustand herbeizuführen, Dateien zu manipulieren, Sicherheitsvorkehrungen zu umgehen oder Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2023-2058</guid>
    </item>
  </channel>
</rss>
