GHSA-vrw8-fxc6-2r93 — v5
Fix: go-chi/chi@1be7ad9GHSA-vrw8-fxc6-2r93 is a Open Redirect vulnerability in github.com/go-chi/chi/v5. A fix is available for github.com/go-chi/chi/v5 — see the affected versions and patch details below.
chi Allows Host Header Injection which Leads to Open Redirect in RedirectSlashes
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
github.com/go-chi/chi/v5Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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
package main
import (
"fmt"
"net/http"
"github.com/go-chi/chi/v5"
"github.com/go-chi/chi/v5/middleware" // Import the middleware package
)
func main() {
// Create a new Chi router
r := chi.NewRouter()
// Use the built-in RedirectSlashes middleware
r.Use(middleware.RedirectSlashes) // Use middleware.RedirectSlashes
// Define a route handler
r.Get("/", func(w http.ResponseWriter, r *http.Request) {
// A simple response
w.Write([]byte("Hello, World!"))
})
// Start the server
fmt.Println("Starting server on :8080")
http.ListenAndServe(":8080", r)
}
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
curl -L -H "Host: example.com" http://localhost:8080/test/
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style type="text/css">
body {
background-color: #f0f0f2;
margin: 0;
padding: 0;
font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;
... snipped ...
Without the host header, the response is returned from the test server
curl -L http://localhost:8080/test/
404 page not found
Impact
An open redirect vulnerability allows attackers to trick users into visiting malicious sites. This can lead to phishing attacks, credential theft, and malware distribution, as users trust the application’s domain while being redirected to harmful sites.
Potential mitigation
It seems that the purpose of the RedirectSlashes function is to redirect within the same application. In that case r.RequestURI can be used instead of r.Host by default. If there is a use case to redirect to a different host, a flag can be added to use the Host header instead. As this flag will be controlled by the developer they will make the decision of allowing redirects to arbitrary hosts based on their judgement.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/go-chi/chi/v5 | all versions | 5.2.2go get github.com/go-chi/chi/v5@v5.2.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/go-chi/chi/v5, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/go-chi/chi/v5 to 5.2.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vrw8-fxc6-2r93 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vrw8-fxc6-2r93 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-vrw8-fxc6-2r93. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vrw8-fxc6-2r93 in your dependencies?
O3 Security finds GHSA-vrw8-fxc6-2r93 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.