<?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://db.gcve.eu</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>Thu, 01 Oct 2026 11:29:09 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-88004</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-88004</link>
      <description>&lt;p&gt;Traefik is an open source HTTP reverse proxy and load balancer. From 3.2.0 until 3.7.13, Traefik entrypoint defenses aliasHeadersStrategy, underscoreHeadersStrategy, and forwardedHeaders inspect req.Header but not req.Trailer, allowing an unauthenticated client to submit an aliasing or trusted header name in an HTTP/1.1 chunked trailer or an HTTP/2 trailer. When the retry or buffering middleware reads the body before the reverse proxy clones the request, the attacker-controlled trailer value reaches a backend that merges trailers into the header namespace, bypassing the documented delete or reject behavior and potentially spoofing identity or forwarded routing data. This issue is fixed in 3.7.13.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Traefik is an open source HTTP reverse proxy and load balancer. From 3.2.0 until 3.7.13, Traefik entrypoint defenses aliasHeadersStrategy, underscoreHeadersStrategy, and forwardedHeaders inspect req.Header but not req.Trailer, allowing an unauthenticated client to submit an aliasing or trusted header name in an HTTP/1.1 chunked trailer or an HTTP/2 trailer. When the retry or buffering middleware reads the body before the reverse proxy clones the request, the attacker-controlled trailer value reaches a backend that merges trailers into the header namespace, bypassing the documented delete or reject behavior and potentially spoofing identity or forwarded routing data. This issue is fixed in 3.7.13.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-88004</guid>
    </item>
    <item>
      <title>GHSA-v67p-phpq-fc8x — Traefik entrypoint header-name sanitization bypassed via request trailers</title>
      <link>https://db.gcve.eu/vuln/ghsa-v67p-phpq-fc8x</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/traefik/traefik/v3&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Traefik&amp;#39;s entrypoint defenses against spoofed trusted header names — `aliasHeadersStrategy` / `underscoreHeadersStrategy` in `delete` or `reject` mode, and the default `forwardedHeaders` stripping of client-supplied `X-Forwarded-*` — scan `req.Header` only and never `req.Trailer`. An unauthenticated client can therefore smuggle a sanitized name (an aliasing spelling such as `X_Auth_User`, or a trusted name such as `X-Forwarded-Prefix`) as an HTTP/1.1 chunked trailer or an HTTP/2 trailer: `reject` does not return its documented `400`, `delete` does not remove the name, and Traefik&amp;#39;s reverse proxy forwarded the trailer to the backend — with an attacker-chosen value whenever a body-buffering middleware (the `retry` middleware with status codes, or the `buffering` middleware) reads the body before the proxy clone. Backends that merge trailers into their header namespace then act on the smuggled name. The fix stops forwarding request trailer values to the backend; the declared trailer names are still forwarded as permitted by RFC 9110 section 6.6.2.&lt;/p&gt;
&lt;p&gt;Traefik v2 is not affected: the defect is in the custom reverse proxy introduced in v3 (`pkg/proxy/httputil`), and v2 uses the Go standard library&amp;#39;s `httputil.ReverseProxy`, which does not forward request trailer values to the backend. Affected v3 lines from v3.2.0 through v3.7.12 include the end-of-life v3.2 through v3.6 lines, which will not receive a fix on their own line; the remedy for those users is to upgrade to v3…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/traefik/traefik/v3&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;Traefik&amp;#39;s entrypoint defenses against spoofed trusted header names — `aliasHeadersStrategy` / `underscoreHeadersStrategy` in `delete` or `reject` mode, and the default `forwardedHeaders` stripping of client-supplied `X-Forwarded-*` — scan `req.Header` only and never `req.Trailer`. An unauthenticated client can therefore smuggle a sanitized name (an aliasing spelling such as `X_Auth_User`, or a trusted name such as `X-Forwarded-Prefix`) as an HTTP/1.1 chunked trailer or an HTTP/2 trailer: `reject` does not return its documented `400`, `delete` does not remove the name, and Traefik&amp;#39;s reverse proxy forwarded the trailer to the backend — with an attacker-chosen value whenever a body-buffering middleware (the `retry` middleware with status codes, or the `buffering` middleware) reads the body before the proxy clone. Backends that merge trailers into their header namespace then act on the smuggled name. The fix stops forwarding request trailer values to the backend; the declared trailer names are still forwarded as permitted by RFC 9110 section 6.6.2.&lt;/p&gt;
&lt;p&gt;Traefik v2 is not affected: the defect is in the custom reverse proxy introduced in v3 (`pkg/proxy/httputil`), and v2 uses the Go standard library&amp;#39;s `httputil.ReverseProxy`, which does not forward request trailer values to the backend. Affected v3 lines from v3.2.0 through v3.7.12 include the end-of-life v3.2 through v3.6 lines, which will not receive a fix on their own line; the remedy for those users is to upgrade to v3…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-v67p-phpq-fc8x</guid>
    </item>
  </channel>
</rss>
