OAuth2 Redirect URL validity does not respect query parameters and character casing for loopback addressesGHSA-rfq3-w54c-f9q5
MEDIUMFix: ory/fosite#400GHSA-rfq3-w54c-f9q5 is a medium-severity (CVSS 6.1) Improper Input Validation vulnerability in github.com/ory/fosite. A fix is available for github.com/ory/fosite — see the affected versions and patch details below.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-rfq3-w54c-f9q5 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/ory/fositeReal-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
Impact
fosite#400 (released as v0.30.2) introduced a new feature for handling redirect URLs pointing to loopback interfaces (rfc8252#section-7.3). As part of that change new behavior was introduced which failed to respect the redirect URL's (only for loopback interfaces!) query parameters
- Registering a client with allowed redirect URL
http://127.0.0.1/callback - Performing OAuth2 flow and requesting redirect URL
http://127.0.0.1/callback?bar=foo - Instead of an error, the browser is redirected to
http://127.0.0.1/callback?bar=foowith a potentially successful OAuth2 response.
as well as the host parameter (as long as the host is a loopback interface):
- Registering a client with allowed redirect URL
https://example.com/callback - Performing OAuth2 flow and requesting redirect URL
http://127.0.0.1/callback - Instead of an error, the browser is redirected to
http://127.0.0.1/callbackwith a potentially successful OAuth2 response.
These bugs are only applicable in scenarios where the attacker has control over the loopback interface (localhost, 127.0.0.1, [::1]) where the browser performing the OAuth2 flow is running.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/ory/fosite | ≥ 0.30.3&&< 0.34.1 | 0.34.1go get github.com/ory/fosite@v0.34.1 |
Affected Products
fositeoryDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/ory/fosite, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/ory/fosite to 0.34.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rfq3-w54c-f9q5 is resolved across your whole dependency graph.
Workarounds
Stop reflecting attacker-controlled destinations: resolve every redirect target against an allowlist of paths or hosts you own, prefer a server-side key over a full URL in the request, and reject absolute URLs entirely where the flow only ever needs a relative one.
Frequently Asked Questions
Is GHSA-rfq3-w54c-f9q5 in your dependencies?
Find it across Go, including transitive dependencies.