CVE-2023-50658 is a high severity denial of service in jose2go, a JOSE library for Go. Versions before 1.6.0 let an attacker burn CPU with a very large p2c (PBES2 count) value. NVD scores it 7.5. Upgrade to jose2go 1.6.0 or later.
What's affected
The record lists the jose2go component for Go before version 1.6.0 as affected. Version 1.6.0 is the fixed release. The module is hosted at github.com/dvsekhvalnov/jose2go, and the record was published on 2024-02-29.
NVD scores the flaw 7.5 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, which is network reachable, no privileges, availability impact only. It does not expose data or let an attacker change anything.
The comparison between v1.5.0 and v1.6.0 shows that minimum and maximum iteration count guards were added to the pbes2-hmac-aeskw algorithm, with unit tests for custom p2c headers. The release page does not state the numeric limits, so read the code if you need them.
Only applications that decrypt untrusted JWE tokens with the PBES2 key management algorithms are likely to be reachable. Code that never accepts such tokens from outside is less exposed, but a dependency scan will still flag it.
How to check if you're exposed
Find out whether jose2go is in your module graph and which version resolves:
go list -m all | grep jose2go
go mod why -m github.com/dvsekhvalnov/jose2go
Any version below 1.6.0 is affected. Run the check in every repository, because jose2go often arrives as an indirect dependency through another library that handles JWT or JWE.
Then ask whether the code path is reachable. Does your service call the decrypt function on tokens from untrusted clients, and are PBES2 algorithms accepted? A free scan at https://gold.safeguard.sh/scan lists affected components, and reachability analysis helps separate a library that is present from one that is actually called.
What to do now
- Run the commands above in each Go module and list every jose2go version found.
- Upgrade with go get github.com/dvsekhvalnov/jose2go@v1.6.0 or a later release, then run go mod tidy.
- Rebuild and redeploy the services that embed the library, since Go links dependencies statically.
- Where you control token handling, restrict accepted algorithms to those you actually use.
- Add rate limits or request timeouts in front of any endpoint that decrypts untrusted tokens.
Why it matters
The weakness is allocation of resources without limits or throttling, CWE-770. PBES2 derives a key from a password by repeating a hash many times, and the count is carried in the token header. If a library trusts the count the sender supplies, the sender chooses how much work the server does.
That is a cheap way to cause trouble. One small request can cost the server a large amount of CPU, and a handful of them can stall a service. The fix is the standard one: enforce a sensible minimum and maximum on the count before doing any work.
The record shows no CISA Known Exploited Vulnerabilities listing, and the sources fetched do not report exploitation in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version of jose2go fixes CVE-2023-50658?
Version 1.6.0. The record says versions before 1.6.0 are affected.
Is my service exposed if it only signs tokens?
The weakness is in the PBES2 count handling during decryption. A service that never decrypts untrusted JWE tokens is unlikely to be reachable, but upgrading is still the clean fix.
Sources
Last reviewed: 19 October 2026.
