Spotted what might be an issue in gowind/go.mod around line 1.
The gRPC-Go library before v1.79.3 does not validate the HTTP/2 :path pseudo-header, allowing paths without a leading slash. This causes authorization interceptors (e.g., grpc/authz) to receive a non‑canonical path, making "deny" rules based on canonical paths ineffective. If a fallback "allow" rule exists, an attacker can bypass authorization by sending a malformed HTTP/2 frame, leading to unauthorized access. This is a critical authorization bypass vulnerability.
Something like this might fix it:
--- a/gowind/go.mod
+++ b/gowind/go.mod
@@ -1,4 +1,4 @@
module gowind
go 1.20
-require google.golang.org/grpc v1.71.1
+require google.golang.org/grpc v1.79.3
For reference: rule CVE-2026-33186. Rated critical.
If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Spotted what might be an issue in
gowind/go.modaround line 1.The gRPC-Go library before v1.79.3 does not validate the HTTP/2
:pathpseudo-header, allowing paths without a leading slash. This causes authorization interceptors (e.g., grpc/authz) to receive a non‑canonical path, making "deny" rules based on canonical paths ineffective. If a fallback "allow" rule exists, an attacker can bypass authorization by sending a malformed HTTP/2 frame, leading to unauthorized access. This is a critical authorization bypass vulnerability.Something like this might fix it:
For reference: rule
CVE-2026-33186. Rated critical.If I have misread how this is used, sorry for the noise — feel free to close.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.