Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
ClientIPFromXFF skips any X-Forwarded-For entry in a configured trusted CIDR but never verifies that the direct TCP peer in http.Request.RemoteAddr belongs to that CIDR. A client that can reach the Go server directly can therefore append a trusted-looking proxy address and choose the client IP returned by middleware.GetClientIP. The attack is remote and requires one unauthenticated HTTP request with no user interaction (AV:N/AC:L/PR:N/UI:N). It changes security decisions and exposes one protected handler within the same application (S:U/C:L/I:L); no availability loss was observed (A:N). Preconditions: The application uses ClientIPFromXFF and makes the origin server reachable by an anonymous client outside the configured trusted-proxy CIDRs. No victim interaction is required. 1. Send GET /admin directly to the origin with no X-Forwarded-For header. 2. Observe a 403 Forbidden response and an empty derived client IP. 3. Repeat the request with X-Forwarded-For: 10.0.0.7,…
Recommended action: Upgrade to 5.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The `RealIP` middleware in `go-chi/chi` is vulnerable to IP spoofing because it blindly trusts the first (leftmost) element of the `X-Forwarded-For` HTTP header. This allows a remote attacker to bypass IP-based access control lists (ACLs) and rate-limiting mechanisms by providing a spoofed IP address in the header. Details In `middleware/realip.go`, the `realIP` function parses the `X-Forwarded-For` header and extracts the first comma-separated value: ```go func realIP(r *http.Request) string { // ... } else if xff := r.Header.Get(xForwardedFor); xff != "" { ip, _, _ = strings.Cut(xff, ",") } // ... } ``` Standard practice for `X-Forwarded-For` is that each proxy appends the client's IP to the end of the list. However, since the client can also provide this header, the leftmost values are untrusted. A client can send a header like `X-Forwarded-For: , `, and `go-chi/chi` will treat ` ` as the source of the request. Proof of Concept (PoC) The following code…
Recommended action: Upgrade to 5.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The RedirectSlashes function in middleware/strip.go does not perform correct input validation and can lead to an open redirect vulnerability. Details The RedirectSlashes function performs a Trim to all forward slash (/) characters, while prepending a single one at the begining of the path (Line 52). However, it does not trim backslashes (\). Also, from version 5.2.2 onwards the RedirectSlashes function does not take into consideration the Host Header in the redirect response returned. This was done in order to combat another vulnerability. The above make it possible for a response in the following form: The /\evil.com will be transformed by most browsers (Chrome, Firefox, etc. not Safari) into //evil.com which is a protocol relative URL and will result in a redirect to evil.com, essentially making it an open redirect vulnerability. PoC A minimal working example can be seen below. And when we request the…
Recommended action: Upgrade to 5.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The RedirectSlashes function in middleware/strip.go is vulnerable to host header injection which leads to open redirect. We consider this a lower-severity open redirect, as it can't be exploited from browsers or email clients (requires manipulation of a Host header). Details The RedirectSlashes method uses the Host header to construct the redirectURL at this line https://github.com/go-chi/chi/blob/master/middleware/strip.go#L55 The Host header can be manipulated by a user to be any arbitrary host. This leads to open redirect when using the RedirectSlashes middleware PoC Create a simple server which uses the RedirectSlashes middleware Run the server go run main.go Once the server is running, send a request that will trigger the RedirectSlashes function with an arbitrary Host header curl -iL -H "Host: example.com" http://localhost:8080/test/ Observe that the request will be redirected to example.com Without the host header, the response is returned from the test server Impact…
Recommended action: Upgrade to 5.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.