fix(deps): update module github.com/golang-jwt/jwt/v4 to v4.5.2 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
github.com/golang-jwt/jwt/v4	v4.5.0 -> v4.5.2

GitHub Vulnerability Alerts

CVE-2024-51744

Summary

Unclear documentation of the error behavior in ParseWithClaims can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.

Fix

We have back-ported the error handling logic from the v5 branch to the v4 branch. In this logic, the ParseWithClaims function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release.

Workaround

We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

token, err := /* jwt.Parse or similar */
if token.Valid {
	fmt.Println("You look nice today")
} else if errors.Is(err, jwt.ErrTokenMalformed) {
	fmt.Println("That's not even a token")
} else if errors.Is(err, jwt.ErrTokenUnverifiable) {
	fmt.Println("We could not verify this token")
} else if errors.Is(err, jwt.ErrTokenSignatureInvalid) {
	fmt.Println("This token has an invalid signature")
} else if errors.Is(err, jwt.ErrTokenExpired) || errors.Is(err, jwt.ErrTokenNotValidYet) {
	// Token is either expired or not active yet
	fmt.Println("Timing is everything")
} else {
	fmt.Println("Couldn't handle this token:", err)
}

CVE-2025-30204

Summary

Function parse.ParseUnverified currently splits (via a call to strings.Split) its argument (which is untrusted data) on periods.

As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. Relevant weakness: CWE-405: Asymmetric Resource Consumption (Amplification)

Details

See parse.ParseUnverified

Impact

Excessive memory allocation

---

Release Notes

golang-jwt/jwt (github.com/golang-jwt/jwt/v4)

v4.5.2

Compare Source

See GHSA-mh63-6h87-95cp

Full Changelog: golang-jwt/jwt@v4.5.1...v4.5.2

v4.5.1

Compare Source

Security

Unclear documentation of the error behavior in ParseWithClaims in <= 4.5.0 could lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by ParseWithClaims return both error codes. If users only check for the jwt.ErrTokenExpired using error.Is, they will ignore the embedded jwt.ErrTokenSignatureInvalid and thus potentially accept invalid tokens.

This issue was documented in GHSA-29wx-vh33-7x7r and fixed in this release.

Note: v5 was not affected by this issue. So upgrading to this release version is also recommended.

What's Changed

• Back-ported error-handling logic in ParseWithClaims from v5 branch. This fixes GHSA-29wx-vh33-7x7r.

Full Changelog: golang-jwt/jwt@v4.5.0...v4.5.1

---

Configuration

📅 Schedule: Branch creation - "" (UTC), 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.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

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

---

This PR was generated by Mend Renovate. View the repository job log.

[druid-infra]

Renovate audit (druid-infra): inspected metadata, diff, head 689f6c7, reviews, and check runs.

• Diff: github.com/golang-jwt/jwt/v4 4.5.0 -> 4.5.2 plus matching go.sum entries; no application code changed. Upstream v4.5.2 release notes link GHSA-mh63-6h87-95cp.
• Test: Docker golang:1.23 go test -vet=off ./... -run ^$ passed (compile-only). A full go test ./... attempt did not complete within 600s; the repository has an unrelated existing debug/exec.go vet error and QueueManager test instability in the attempted run.
• Browser: not applicable (Go dependency-only diff).
• Decision: not merged. PR is conflicting/dirty, has no check runs, and requires branch refresh before considering the security update.

[druid-infra]

Daily Renovate audit (2026-09-04): inspected metadata, changed files/diff, head 689f6c7, reviews, mergeability, and check runs. Diff updates github.com/golang-jwt/jwt/v4 v4.5.0 to v4.5.2 and refreshes go.sum; release notes identify CVE-2024-51744 and CVE-2025-30204 fixes. Tests: Dockerized Go 1.24 go test ./... (timed out after 300s during module downloads); git diff --check (PASS). Browser coverage: not applicable (Go dependency metadata only). Release review: target is a security patch, but golang-jwt has since released v5.3.1; v4 behavior changes are called out upstream and need compatibility review. Merge decision: NOT MERGED — PR is conflicted (mergeable_state=dirty), has no check runs, and security-sensitive dependency updates are excluded from autonomous merge.

[druid-infra]

Daily Renovate audit (druid-infra): inspected PR metadata, head 689f6c7d59025503c1a403ef9d625302851b9a1d, diff (go.mod/go.sum only), the two published security advisories/release notes, review state, mergeability, and check runs. The update is github.com/golang-jwt/jwt/v4 v4.5.0 → v4.5.2 and addresses the documented ParseWithClaims error-handling issue plus excessive allocation in ParseUnverified. Checks: no check runs reported. Dockerized test: docker run --rm -v /tmp/druid-cli-pr-51:/app -w /app golang:1.23 bash -lc 'export PATH=/usr/local/go/bin:$PATH; go test ./test' — PASS. Broader go test ./... reached the repository's pre-existing debug/exec.go:54 vet/build error and timed out while integration work continued. Browser coverage: not applicable (Go dependency-only diff). Decision: NOT MERGED; GitHub reports mergeable_state=dirty, so branch refresh/CI is required before considering this security fix.

[druid-infra]

druid-infra daily Renovate audit (2026-09-11 UTC): inspected metadata, changed files/diff, head 689f6c7d59025503c1a403ef9d625302851b9a1d, review state, mergeability, and check runs. Diff is limited to github.com/golang-jwt/jwt/v4 v4.5.0 -> v4.5.2 plus matching go.sum entries; the upstream v4.5.2 security advisory/release notes were reviewed. Ran Dockerized Go 1.24 go test ./...; the full suite did not complete within the audit window and was stopped after more than five minutes. No browser test: backend security dependency-only change. Not merged: security-sensitive dependency, mergeable_state=dirty, no check runs, and incomplete local verification.

[druid-infra]

Daily Renovate audit (2026-09-12), authenticated as druid-infra.

Inspected head 689f6c7d59025503c1a403ef9d625302851b9a1d, metadata, diff, review state, mergeability, and check runs. Diff is scoped to go.mod/go.sum, updating github.com/golang-jwt/jwt/v4 4.5.0 → 4.5.2 for the published security advisories; no source imports changed. No check runs are reported; GitHub reports mergeability dirty.

Tests in an isolated worktree using Docker golang:1.23:

• go test -timeout 120s ./test — PASS
• go build ./... — PASS
• git diff --check — PASS

Browser coverage: not applicable; this is a Go dependency/lockfile-only change with no UI surface. Decision: not merged. Blockers are the dirty/non-clean merge state, absent required check runs, and the explicit audit policy requiring user instruction before merging security-sensitive dependency changes.

[druid-infra]

Renovate audit (druid-infra, 2026-09-13): inspected PR metadata, head 689f6c7d59025503c1a403ef9d625302851b9a1d, mergeability/review state, all check runs (0 check runs; combined status pending), and the full diff (go.mod/go.sum, jwt/v4 4.5.0→4.5.2). Reviewed the PR’s release/security notes for CVE-2024-51744 and CVE-2025-30204; lockfile entries are consistent and git diff --check passed. Dockerized compile coverage passed: docker run --rm -v <checkout>:/src -w /src golang:1.24.7 /usr/local/go/bin/go test -vet=off -run '^$' ./.... A full go test ./... attempt exposed pre-existing repository failures in debug/exec.go vet and test/TestQueueManager; integration packages also begin long-running tests, so it was not treated as a clean full-suite result. No browser test applies to this Go-only dependency diff. Decision: NOT MERGED — security-sensitive dependency change requires explicit instruction, and required checks are absent/pending with mergeability reported unknown.

[druid-infra]

Daily Renovate audit (druid-infra): inspected PR metadata/head 689f6c7d59025503c1a403ef9d625302851b9a1d, diff (go.mod, go.sum), mergeability, reviews, and check runs. Release/security notes reviewed for golang-jwt/jwt v4.5.2 (CVE-2024-51744 and CVE-2025-30204). git diff --check passed. Attempted Dockerized Go validation: docker run --rm -v /tmp/druid-pr-audit/druid-cli-51:/src -w /src golang:1.24 bash -c 'go test ./...'; dependency download did not complete within 300s, so no passing test result is claimed. Browser coverage: not applicable (Go dependency-only diff). Decision: not merged; GitHub reports mergeable_state=dirty, with no check runs, so clean/required-check criteria are not met.

[druid-infra]

Daily Renovate audit (druid-infra): inspected head 689f6c7d59025503c1a403ef9d625302851b9a1d, metadata/diff/reviews/check-runs. Diff is limited to go.mod/go.sum, upgrading github.com/golang-jwt/jwt/v4 4.5.0→4.5.2 for the documented security fixes. No reviews and zero check runs reported; mergeability is dirty. Reproduced in Dockerized Go 1.24: go test -vet=off ./... -run ^$ passed (compile-only); full go test ./... && go vet ./... did not pass because existing debug/exec.go:54 triggers the Go vet int-to-string diagnostic and TestProcessManager failed, then the command hit the 600s timeout. No browser coverage applicable (Go dependency-only diff). Decision: not merged; blocked by dirty mergeability, absent checks, and incomplete/full-test failure.