Repository navigation
Update module github.com/go-chi/chi/v5 to v5.4.0 [SECURITY] (release-v0.8) - #1937
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the
|
|
🤖 Finished Review · ✅ Success · Started 9:03 AM UTC · Completed 9:12 AM UTC Commit: Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.81 |
|
<!-- fullsend:risk-assessment --> DetailsSecurity-labeled renovate dependency bump touching 4 go.mod/go.sum files with active churn history; XS size, bot-authored, and no source or CI changes keep risk moderate rather than elevated. |
|
Looks good to me Labels: PR is a dependency update |
|
🤖 Finished Retro · ✅ Success · Started 3:36 PM UTC · Completed 3:43 PM UTC Commit: Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $2.94 |
|
Workflow quality: Clean. PR #1937 was a Renovate bot security dependency bump (go-chi/chi v5.2.4/v5.2.5 → v5.4.0, CVE-2026-114437) touching 4 go.mod/go.sum files on No new proposals — all identified improvement opportunities are already covered by existing open issues:
|
This PR contains the following updates:
v5.2.5→v5.4.0v5.2.4→v5.4.0chi: Client IP spoofing in ClientIPFromXFF via X-Forwarded-For
CVE-2026-114437 / GHSA-j6qf-3m9c-vwj3
More information
Details
Summary
ClientIPFromXFFskips anyX-Forwarded-Forentry in a configured trusted CIDR but never verifies that the direct TCP peer inhttp.Request.RemoteAddrbelongs 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 bymiddleware.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
ClientIPFromXFFand makes the origin server reachable by an anonymous client outside the configured trusted-proxy CIDRs. No victim interaction is required.GET /admindirectly to the origin with noX-Forwarded-Forheader.403 Forbiddenresponse and an empty derived client IP.X-Forwarded-For: 10.0.0.7, 198.51.100.42.200 OKandclient-ip="10.0.0.7". Expected: the untrusted direct peer prevents the forwarding chain from being accepted.Details
The vulnerable code is
ClientIPFromXFFinmiddleware/client_ip.go, lines 93-116 at the tested revision. It callswalkXFFwith only the attacker-controlled header, skips every entry that matches a trusted prefix, and stores the first remaining address:The function does not parse
r.RemoteAddrbefore this walk. Consequently, the configured CIDRs identify trusted strings insideX-Forwarded-For, but do not establish that the immediate sender is one of those trusted proxies.Proof of concept
Using Go 1.24 or later, create and run this minimal application against the tested revision:
The no-header control was rejected:
Adding the forged chain authorized the same direct client:
Impact
I made an anonymous direct connection from
127.0.0.1, supplied a header that ended in a different trusted-proxy CIDR, and caused the application to treat my client IP as the allowlisted10.0.0.7. This changed the authorization decision from403 Forbiddento200 OKfor the protected handler.Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
go-chi/chi (github.com/go-chi/chi/v5)
v5.4.0Compare Source
What's Changed
New Contributors
Full Changelog: go-chi/chi@v5.3.2...v5.4.0
v5.3.2Compare Source
What's Changed
middleware.NewCompressor(level, "/*")never worked and silently compressed nothing. Instead of turning it into a compress-everything catch-all (as proposed in #868 and #1121), we decided to reject both "/" and "/*" at construction and panic. Compressing every response wastes CPU on already-compressed types (zip, jpeg, png), which is why the middleware keeps a curated default list. Users should pass explicit content types.Full Changelog: go-chi/chi@v5.3.1...v5.3.2
v5.3.1Compare Source
What's Changed
New Contributors
Full Changelog: go-chi/chi@v5.3.0...v5.3.1
v5.3.0Compare Source
What's Changed
New Contributors
SECURITY: middleware.ClientIP, a replacement for middleware.RealIP
@VojtechVitek submitted PR #967, which introduces middleware.ClientIP — a replacement for middleware.RealIP that closes the three open spoofing advisories:
RemoteAddrresolution (convto)middleware.RealIP(Saku0512, Critical / 9.3)It also addresses issues outlined at:
middleware.RealIPis deprecated in this PR with pointers to the new API.The deprecation only adds a
// Deprecated:doc comment; the function keeps working for backward compatibility.Why a new middleware (not "fix RealIP in place")
RealIPhas two unfixable design choices: it mutatesr.RemoteAddr, and it tries to be a one-size-fits-all default by walking a hard-coded list of headers any client can supply. Per adam-p's "The perils of the 'real' client IP" (which calls chi out by name on this), there is no safe default — the user must pick their trust source explicitly.The new API
Four middlewares, two accessors. Pick exactly one middleware based on your
infrastructure, read the result with one of the two accessors:
Example usage:
And in your handler or downstream middleware:
Thanks to @adam-p, @c2h5oh, @rezmoss, @Saku0512, @convto, @Dirbaio, @jawnsy, @lrstanley, @mfridman, @n33pm, @pkieltyka for the prior discussions, detailed reviews, advisory reports, and test contributions that shaped this PR.
Full Changelog: go-chi/chi@v5.2.5...v5.3.0
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.