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

renovate-sh-app · 2025-11-27T12:22:27Z

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/golang-jwt/jwt/v4	`v4.4.3` → `v4.5.2`

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

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

Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations

CVE-2024-51744 / GHSA-29wx-vh33-7x7r / GO-2024-3250

More information

Details

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

Severity

CVSS Score: 2.3 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

References

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

Improper error handling in ParseWithClaims and bad documentation may cause dangerous situations in github.com/golang-jwt/jwt

CVE-2024-51744 / GHSA-29wx-vh33-7x7r / GO-2024-3250

More information

Details

Improper error handling in ParseWithClaims and bad documentation may cause dangerous situations in github.com/golang-jwt/jwt

Severity

Unknown

References

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

jwt-go allows excessive memory allocation during header parsing

CVE-2025-30204 / GHSA-mh63-6h87-95cp / GO-2025-3553

More information

Details

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

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

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

Excessive memory allocation during header parsing in github.com/golang-jwt/jwt

CVE-2025-30204 / GHSA-mh63-6h87-95cp / GO-2025-3553

More information

Details

Excessive memory allocation during header parsing in github.com/golang-jwt/jwt

Severity

Unknown

References

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

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

`v4.5.0`

Compare Source

What's Changed

Allow strict base64 decoding by @AlexanderYastrebov in #259

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

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

…curity] | datasource | package | from | to | | ---------- | ---------------------------- | ------ | ------ | | go | github.com/golang-jwt/jwt/v4 | v4.4.3 | v4.5.2 | Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>

github-actions · 2025-11-27T12:23:42Z

😢 zizmor failed with exit code 14.

Expand for full output

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf-lint.yml:13:9
   |
13 |       - uses: bufbuild/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf-lint.yml:16:9
   |
16 |       - uses: bufbuild/buf-lint-action@v1
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf-lint.yml:19:9
   |
19 |       - uses: bufbuild/buf-breaking-action@v1
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf.yml:12:9
   |
12 |       - uses: bufbuild/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf.yml:15:9
   |
15 |       - uses: bufbuild/buf-lint-action@v1
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf.yml:18:9
   |
18 |       - uses: bufbuild/buf-breaking-action@v1
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/buf.yml:22:9
   |
22 |       - uses: bufbuild/buf-push-action@v1
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[template-injection]: code injection via template expansion
   --> ./.github/workflows/ci.yml:208:66
    |
208 |         run: ./scripts/ui_release.sh --check-package "$(echo ${{ github.ref_name }}|sed s/v2/v0/)"
    |         --- this run block                                       ^^^^^^^^^^^^^^^ may expand into attacker-controllable code
    |
    = note: audit confidence → High
    = note: this finding has an auto-fix

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/ci.yml:16:9
   |
16 |       - uses: prometheus/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/ci.yml:38:9
   |
38 |       - uses: prometheus/[email protected]
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:107:9
    |
107 |       - uses: prometheus/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:130:9
    |
130 |       - uses: prometheus/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:149:9
    |
149 |         uses: golangci/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:165:9
    |
165 |       - uses: prometheus/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:179:9
    |
179 |       - uses: prometheus/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
   --> ./.github/workflows/ci.yml:194:9
    |
194 |       - uses: prometheus/[email protected]
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
    |
    = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/codeql-analysis.yml:29:9
   |
29 |         uses: github/codeql-action/init@v2
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/codeql-analysis.yml:34:9
   |
34 |         uses: github/codeql-action/autobuild@v2
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/codeql-analysis.yml:37:9
   |
37 |         uses: github/codeql-action/analyze@v2
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/fuzzing.yml:10:9
   |
10 |         uses: google/oss-fuzz/infra/cifuzz/actions/build_fuzzers@master
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/fuzzing.yml:15:9
   |
15 |         uses: google/oss-fuzz/infra/cifuzz/actions/run_fuzzers@master
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ./.github/workflows/lock.yml:18:9
   |
18 |       - uses: dessant/lock-threads@v4
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-images]: unpinned image references
  --> ./.github/workflows/repo_sync.yml:10:7
   |
10 |       image: quay.io/prometheus/golang-builder
   |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ container image is unpinned
   |
   = note: audit confidence → High

83 findings (37 ignored, 23 suppressed, 1 fixable): 0 informational, 0 low, 0 medium, 23 high

renovate-sh-app bot added automerge-security-update severity:UNKNOWN labels Nov 27, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

Uh oh!

renovate-sh-app bot commented Nov 27, 2025 •

edited

Loading

Uh oh!

github-actions bot commented Nov 27, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

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

Are you sure you want to change the base?

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

Uh oh!

Conversation

renovate-sh-app bot commented Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

CVE-2024-51744

Summary

Fix

Workaround

CVE-2025-30204

Summary

Details

Impact

Bad documentation of error handling in ParseWithClaims can lead to potentially dangerous situations

Details

Summary

Fix

Workaround

Severity

References

Improper error handling in ParseWithClaims and bad documentation may cause dangerous situations in github.com/golang-jwt/jwt

Details

Severity

References

jwt-go allows excessive memory allocation during header parsing

Details

Summary

Details

Impact

Severity

References

Excessive memory allocation during header parsing in github.com/golang-jwt/jwt

Details

Severity

References

Release Notes

v4.5.2

v4.5.1

Security

What's Changed

v4.5.0

What's Changed

Configuration

Need help?

Uh oh!

github-actions bot commented Nov 27, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate-sh-app bot commented Nov 27, 2025 •

edited

Loading

`v4.5.2`

`v4.5.1`

`v4.5.0`