https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 22 Oct 2026 20:55:16 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-84747 <p>Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version &lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.</p> <p>Root Cause: The method dispatch function FindMethodPropertyByURI() in bRPC&#39;s HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with &#39;/&#39; nor is the asterisk-form &#39;*&#39;, contrary to RFC 9113 section 8.3.1, were not rejected.</p> <p>Affected Scenarios: Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front…</p> <p>Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version &lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.</p> <p>Root Cause: The method dispatch function FindMethodPropertyByURI() in bRPC&#39;s HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with &#39;/&#39; nor is the asterisk-form &#39;*&#39;, contrary to RFC 9113 section 8.3.1, were not rejected.</p> <p>Affected Scenarios: Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front…</p> https://db.gcve.eu/vuln/fkie_cve-2026-84747 https://db.gcve.eu/vuln/ghsa-94r6-xp5c-qwq5 <p>Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version &lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.</p> <p>Root Cause: The method dispatch function FindMethodPropertyByURI() in bRPC&#39;s HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with &#39;/&#39; nor is the asterisk-form &#39;*&#39;, contrary to RFC 9113 section 8.3.1, were not rejected.</p> <p>Affected Scenarios: Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front…</p> <p>Interpretation conflict in the HTTP protocol implementation in Apache bRPC (version &lt; 1.18.0) on all platforms allows remote attackers to bypass access control rules enforced by a front proxy.</p> <p>Root Cause: The method dispatch function FindMethodPropertyByURI() in bRPC&#39;s HTTP protocol splits the request path with a string splitter that skips empty fields, so paths containing empty path segments (consecutive slashes), such as //flags, /flags// and /flags//port, are dispatched to the same method as their collapsed form /flags. Per RFC 3986 these are distinct paths. A front proxy that enforces an ACL (e.g. blocking access to builtin services such as /flags) matches the collapsed form only, and therefore forwards the padded literal to the bRPC server, where it is dispatched as if it were the collapsed form. This differential allows //flags?setvalue= to reach a builtin service that /flags is not allowed to reach. Additionally, the HTTP/2 implementation never validated the :path pseudo-header, so requests without a :path, or with a :path that neither begins with &#39;/&#39; nor is the asterisk-form &#39;*&#39;, contrary to RFC 9113 section 8.3.1, were not rejected.</p> <p>Affected Scenarios: Deployments of Apache bRPC behind a front proxy or gateway that performs access control (ACL) decisions on the literal request path, where the bRPC server accepts HTTP or HTTP/2 traffic from that proxy. In such deployments an attacker can send a path containing empty path segments to reach a resource that the front…</p> https://db.gcve.eu/vuln/ghsa-94r6-xp5c-qwq5