Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-c6gw-w398-hv78

Fix: go-jose/go-jose@99b346c

GHSA-c6gw-w398-hv78 is a CWE-770 vulnerability in github.com/go-jose/go-jose/v4. O3 Security confirms whether GHSA-c6gw-w398-hv78 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

DoS in go-jose Parsing

Also known asCVE-2025-27144GO-2025-3485
Published
Feb 24, 2025
Updated
Feb 4, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed

Real-World Exposure

3 pkgs affected
🐹github.com/go-jose/go-jose/v4🐹github.com/go-jose/go-jose/v3🐹github.com/go-jose/go-jose

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Impact

When parsing compact JWS or JWE input, go-jose could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of '.' characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service.

Patches

Version 4.0.5 fixes this issue

Workarounds

Applications could pre-validate payloads passed to go-jose do not contain an excessive number of '.' characters.

References

This is the same sort of issue as in the golang.org/x/oauth2/jws package as CVE-2025-22868 and Go issue https://go.dev/issue/71490.

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/go-jose/go-jose/v4all versions4.0.5
🐹Gogithub.com/go-jose/go-jose/v3all versions3.0.4
🐹Gogithub.com/go-jose/go-joseall versions3.0.4

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/go-jose/go-jose/v4. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/go-jose/go-jose/v4 to 4.0.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-c6gw-w398-hv78 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-c6gw-w398-hv78 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-c6gw-w398-hv78. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Impact When parsing compact JWS or JWE input, go-jose could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of '.' characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. ### Patches Version 4.0.5 fixes this issue ### Workarounds Applications could pre-validate payloads passed to go-jose do not contain an excessive number of '.' characters. ### References This
O3 Security · Impact-Aware SCA

Is GHSA-c6gw-w398-hv78 in your dependencies?

O3 detects GHSA-c6gw-w398-hv78 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.