<?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>Fri, 16 Oct 2026 09:02:54 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-100351</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-100351</link>
      <description>&lt;p&gt;kin-openapi is a Go project for handling OpenAPI files. From 0.144.0 until 0.147.0, openapi3filter.ValidationHandler validates an operation selected from decoded URL.Path while a downstream gorilla/mux router configured with UseEncodedPath can dispatch a different operation selected from URL.RawPath. When a public exact route and a protected parameterized route use the same method and overlap after decoding, an unauthenticated remote request containing an encoded path separator can be validated as public and then dispatched to the protected handler without invoking the configured AuthenticationFunc. The reachable path parameter is constrained to an encoded representation that decodes to the public literal route, and proxies that canonicalize the URI before forwarding prevent this specific mismatch. This issue is fixed in version 0.147.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kin-openapi is a Go project for handling OpenAPI files. From 0.144.0 until 0.147.0, openapi3filter.ValidationHandler validates an operation selected from decoded URL.Path while a downstream gorilla/mux router configured with UseEncodedPath can dispatch a different operation selected from URL.RawPath. When a public exact route and a protected parameterized route use the same method and overlap after decoding, an unauthenticated remote request containing an encoded path separator can be validated as public and then dispatched to the protected handler without invoking the configured AuthenticationFunc. The reachable path parameter is constrained to an encoded representation that decodes to the public literal route, and proxies that canonicalize the URI before forwarding prevent this specific mismatch. This issue is fixed in version 0.147.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-100351</guid>
    </item>
    <item>
      <title>GHSA-23vg-4cjm-66q5 — kin-openapi: ValidationHandler security-requirement bypass via encoded-path operation confusion</title>
      <link>https://db.gcve.eu/vuln/ghsa-23vg-4cjm-66q5</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/getkin/kin-openapi&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`openapi3filter.ValidationHandler.Middleware` validates requests with kin-openapi&amp;#39;s
legacy router, which selects an OpenAPI operation from the decoded `URL.Path`. The
method is documented as implementing `gorilla/mux.MiddlewareFunc`, but a downstream
gorilla/mux router configured with `UseEncodedPath()` selects its handler from the
encoded representation (`URL.RawPath`).&lt;/p&gt;
&lt;p&gt;An unauthenticated request such as `/public%2Fstatus` can therefore be validated as an
intentionally public operation (`/public/status`) and then dispatched to a protected
operation (`/{id}`). The configured, rejecting `AuthenticationFunc` is never invoked,
and the protected downstream handler runs.&lt;/p&gt;
&lt;p&gt;This is distinct from GHSA-r277-6w6q-xmqw. The behavior below uses an explicit
authentication callback that rejects missing credentials and remains reproducible
after the v0.144.0 fix for the unsafe default callback.&lt;/p&gt;
&lt;p&gt;## Affected products&lt;/p&gt;
&lt;p&gt;- Product: `github.com/getkin/kin-openapi`
- Component: `openapi3filter.ValidationHandler.Middleware`
- Confirmed post-GHSA affected releases: v0.144.0, v0.145.0, and v0.146.0
- Reporter attestation: each listed release was checked out separately, the attached
  single-file test was copied into `openapi3filter/`, and that test passed; maintainers
  should independently confirm the version range
- Confirmed affected development revision: `d33e44e67734dcde81b576582185e1343fb3985d`
- v0.143.0 also reproduces this mechanism, but GHSA-r277-6w6q-xmqw already provides a…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/getkin/kin-openapi&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;`openapi3filter.ValidationHandler.Middleware` validates requests with kin-openapi&amp;#39;s
legacy router, which selects an OpenAPI operation from the decoded `URL.Path`. The
method is documented as implementing `gorilla/mux.MiddlewareFunc`, but a downstream
gorilla/mux router configured with `UseEncodedPath()` selects its handler from the
encoded representation (`URL.RawPath`).&lt;/p&gt;
&lt;p&gt;An unauthenticated request such as `/public%2Fstatus` can therefore be validated as an
intentionally public operation (`/public/status`) and then dispatched to a protected
operation (`/{id}`). The configured, rejecting `AuthenticationFunc` is never invoked,
and the protected downstream handler runs.&lt;/p&gt;
&lt;p&gt;This is distinct from GHSA-r277-6w6q-xmqw. The behavior below uses an explicit
authentication callback that rejects missing credentials and remains reproducible
after the v0.144.0 fix for the unsafe default callback.&lt;/p&gt;
&lt;p&gt;## Affected products&lt;/p&gt;
&lt;p&gt;- Product: `github.com/getkin/kin-openapi`
- Component: `openapi3filter.ValidationHandler.Middleware`
- Confirmed post-GHSA affected releases: v0.144.0, v0.145.0, and v0.146.0
- Reporter attestation: each listed release was checked out separately, the attached
  single-file test was copied into `openapi3filter/`, and that test passed; maintainers
  should independently confirm the version range
- Confirmed affected development revision: `d33e44e67734dcde81b576582185e1343fb3985d`
- v0.143.0 also reproduces this mechanism, but GHSA-r277-6w6q-xmqw already provides a…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-23vg-4cjm-66q5</guid>
    </item>
  </channel>
</rss>
