Go JOSE CVE-2024-28180: Data Amplification and Patch Guide

The Go implementation of JOSE (JSON Object Signing and Encryption) was disclosed vulnerable to an Improper Handling of Highly Compressed Data (Data Amplification) flaw—tracked as CVE-2024-28180—which can let an attacker send a specially crafted JWE (JSON Web Encryption) that forces the recipient to decompress data far larger than expected, consuming CPU and memory and potentially causing denial-of-service conditions for services that call Decrypt or DecryptMulti without defensive limits. (github.com)

Background / Overview​

Go‑JOSE is a widely used Go library that implements JWS/JWE/JWK and related standards for signing, encrypting, and processing JSON-based security tokens. Many applications and downstream projects rely on it for token handling in web services, embedded agents, container tooling, and telemetry pipelines. The flaw CVE‑2024‑28180 was publicly documented in March 2024 and affects multiple release lines; maintainers released patched versions that add decompression limits and related checks to mitigate the amplification risk. (github.com)
The vulnerability class—CWE‑409: Improper Handling of Highly Compressed Data (Data Amplification)—describes a recurrent risk: compressed payloads can be crafted to expand to many times their compressed size (so‑called “zip bombs” or amplification constructs). If a decompressor does not enforce sane output limits, the target process can be forced to allocate huge amounts of memory or consume large CPU cycles while decompressing, resulting in resource exhaustion and service disruption. This is a historically recurring failure mode in compression and archive processing, and Go-based systems have seen related incidents before. (github.com)

---

What the advisory says (technical summary)​

• The vulnerability allows an attacker to send a JWE containing compressed data that, when decompressed by Decrypt or DecryptMulti, can use large amounts of memory and CPU. (github.com)
• The immediate fix implemented by the library: those functions now return an error if the decompressed data size would exceed 250 KB or 10× the compressed size, whichever is larger. This introduces a pragmatic ceiling on allowed inflation during decompression. (github.com)
• Affected and patched versions were explicitly listed by the project and advisory databases: the fix is available in go-jose versions v4.0.1, v3.0.3, and v2.6.3 (for the maintained branches). Some archived package variants (not actively maintained) have no upstream fix. (github.com)
• The reported CVSS v3.1 base score is 4.3 (Medium)—the weakness is network‑accessible and low complexity to attempt, but its impact is primarily availability (denial of service) rather than confidentiality or integrity. (github.com)

These are the core, verifiable technical claims; they are corroborated by multiple independent vulnerability databases and advisories, including the GitHub Advisory, GitLab’s advisory catalog, NVD/OSV aggregations, and ecosystem scanners. (github.com)

---

Why this matters: practical impact and attack scenarios​

At first glance the flaw looks like a classic denial-of-service vector rather than an immediate path to remote code execution or data theft. That classification is accurate for the majority of realistic deployments: CVE‑2024‑28180 enables uncontrolled resource consumption rather than memory corruption or key exfiltration. Still, the operational consequences can be severe:

• Public-facing services that accept JWE tokens and perform server-side decryption can be trivially probed by remote adversaries. Sending a relatively small compressed JWE can induce the server into decompressing tens or hundreds of megabytes (or more) of data, depending on the construction, causing spikes in CPU/memory or process crashes. (github.com)
• Services that perform synchronous processing of decrypted payloads (for example authentication gateways, telemetry ingest endpoints, or middleware in web servers) are particularly at risk because a blocked thread or goroutine can tie up resources that handle legitimate traffic.
• Environments that run many copies of vulnerable code—containers, autoscaled web front ends, or distributed microservices—can become convenient amplification vectors for a denial‑of‑service campaign, increasing operational blast radius.
• Downstream packaging: many distributions and product vendors embed go-jose in larger packages (observed in images or toolchains used by container tooling and monitoring stacks). Some vendors published advisories to their customers noting impact to specific products—operators should not assume a product is unaffected simply because the top-level project was not mentioned; supply‑chain tracing is necessary.

In short: while CVE‑2024‑28180 does not enable data disclosure or code execution by itself, it is an accessible and inexpensive way to degrade availability and must be treated as an operational risk.

---

Strengths of the fix and responsible disclosure​

The maintainers implemented a clear, pragmatic defensive approach: introduce output-size checks at the decompression boundary and fail the operation when inflation thresholds are exceeded. That approach has several strengths:

• Fail-fast behavior: returning an error avoids silent resource growth and lets callers decide how to handle oversized tokens.
• Small, targeted change: the limits are relatively conservative (250 KB floor, 10× compressed size multiplier) and are narrowly scoped to the decompression step, reducing risk of broad functional regressions.
• Coordinated patching: the project issued fixes across supported release lines and published commits and advisories, enabling ecosystem tooling to detect and propose upgrades. Multiple vulnerability catalogs and package managers have recorded the fix and mapped affected packages. (github.com)

These design choices are appropriate for a token-processing library: reject data that request disproportionate resource allocation and surface errors to the caller, which is the safest default for libraries that perform cryptographic and compression work on untrusted inputs.

---

Risks, limitations, and unanswered questions​

No fix is perfect; operators and maintainers should be aware of remaining risks and tradeoffs:

• Threshold tuning is policy, not proof: the 250 KB / 10× rule is a pragmatic cut‑off, but it is not a formal security boundary. Some legitimate use-cases may legitimately exceed those limits; conversely, a clever attacker might craft compressed payloads that remain under the threshold but still impose CPU cost during decompression. Operators need to decide whether the threshold is acceptable for their workload or if stricter throttling is required. (github.com)
• Not all downstreams are patched simultaneously: many distributions and products bundle go-jose in larger artifacts or images. Patches propagate at different speeds across the supply chain: distro packages, container images, and vendor builds may lag behind the upstream library release. Some archived package variants may have no fix. Detection and proactive rebuilds are necessary.
• Service-level mitigations still needed: library-level checks are necessary but insufficient. Systems must still implement timeouts, resource limits, and request‑level throttling to avoid a single malformed token taking down a process or a node in a cluster.
• Potential for false negatives/positives: depending on how consumers construct JWE tokens, strict decompression caps could reject valid messages. System owners that depend on transferring large compressed payloads inside JWE must re-evaluate token design or accept a controlled risk posture.
• Historical context shows recurrence: Go’s ecosystem has seen compression/format‑parsing DOS/edge cases previously (for example gzip and archive parsing bugs), and those precedents show that input validation across decompression and file parsing is a persistent and challenging area.

Where specific deployment details are missing—such as whether a given vendor image embeds an unpatched go-jose—treat those claims as potential until inventorying and scanning confirm presence.

---

Recommended actions — an operational checklist​

Below are prioritized steps for defenders: developers, release engineers, SREs, and security teams.

• Inventory first
• Scan code repositories (go.mod, go.sum), vendor directories, and compiled binaries for references to github.com/go-jose/go-jose or its legacy package names.
• Scan container images and build pipelines; use SCA tools (Dependabot, Snyk, OSV‑based scanners) to detect vulnerable versions.
• Patch promptly
• Upgrade direct dependencies to the fixed versions: v4.0.1, v3.0.3, or v2.6.3, depending on which branch you use. For Go module consumers, update your module requirement and run a tidy/build to propagate changes.
• If you vendor or embed copies of the library in artifacts, rebuild and redeploy images and packages after applying the updated library. (github.com)
• Apply defense-in-depth
• Enforce per-request CPU and memory limits where possible (OS-level cgroups for containers, process isolation, request timeouts).
• Add application-layer rate limits for endpoints that accept JWE tokens.
• Treat tokens that include compressed payloads from untrusted sources as high-risk; require authentication/authorization before processing.
• Consider implementing decompression in a guarded worker with strict output-size and time budgets.
• Detection and monitoring
• Add telemetry to log decompression errors and anomalous spikes in CPU/memory correlated with token processing.
• Alert on repeated decompression failures or on sudden increases in time‑to‑decrypt metrics.
• Use runtime observability to detect goroutine saturation or system swap pressure that can indicate exploitation attempts.
• If you cannot immediately upgrade
• Implement a short-term mitigation: wrap calls to token decryption in a sandboxed subprocess or worker pool that enforces memory and time budgets; reboot or restart workers automatically on resource constraint breaches.
• Reject compressed JWE tokens from untrusted sources where possible until you can deploy a fix.
• Document any devices, agents, or images that cannot be updated and prioritize compensating controls.
• Communicate to stakeholders
• Notify product owners, downstream integrators, and customers where you control the build or distribution of images that embed go-jose. Some vendors have already published advisories for impacted products that include the library—operators should verify product-specific guidance.

---

Developer guidance: how to fix codebases safely​

• Update module references:
• For Go modules: change required version in go.mod and run go get github.com/go-jose/go-jose/[email]v4@v4.0.1[/email] (or the appropriate path for your release line), then go mod tidy and rebuild.
• Add application-level safeguards:
• Validate token sizes before attempting expensive operations.
• If you must accept compressed JWE from clients, consider moving decompression to a gated worker with limited memory and timeouts, and instrument that worker heavily.
• Test for regressions:
• Add unit and integration tests that cover error flows for decompression limits.
• Include load tests that simulate near-threshold compressed token handling to ensure your application’s behavior remains acceptable under stress.

Note: legacy libraries (for example archived forks) may be unmaintained; consider migrating to the actively maintained canonical repository or switching to an alternative library with active security support if you cannot secure the archived fork. (github.com)

---

Detection recipes and sample checks​

• Codebase grep:
• Search for import lines: grep -R "github.com/go-jose/go-jose" . and check versions in go.mod and go.sum.
• Container image inspection:
• Use image‑scanning tools (Snyk, Trivy, or your organization’s scanner) to detect packages bundled into images; cross-check reported versions against the fixed list.
• Runtime signals:
• Correlate Decrypt errors with memory spikes or goroutine counts. If you see repeated decompression errors with concurrent resource spikes, escalate and consider blocking the source IPs or token origins.

---

Case studies and downstream impact (what vendors said)​

Multiple upstream/vulnerability databases and some vendors recorded or incorporated the advisory into their distributor updates. For example, several Linux distributions issued security advisories referencing the CVE and created package updates; large product vendors that embed Grafana or similar tooling alerted operators to upgrade their product images where go-jose appears. These vendor notices underline a key point: patching must happen across the supply chain—not only in the library source tree.
At the time of disclosure, some downstream products required distribution-specific patching to reconcile embedded versions; operators should assume third-party packages and images may still be unpatched until they confirm otherwise.

---

Context: why compression-related bugs keep appearing​

Parsing and decompressing compressed data safely requires careful attention to resource amplification—a relatively low-skill, high-impact attack surface. Libraries that accept compressed input from potentially untrusted sources must check both compressed and decompressed sizes, throttle CPU usage, and apply timeouts.
Go’s ecosystem has previously addressed similar issues in compression and archive processing where malformed inputs triggered panics or unbounded recursion in standard libraries; these precedents show the practical difficulty of getting decompression logic right in a world where many different formats and edge cases exist. The current fix in go-jose aligns with industry best practice: put explicit limits on decompressed size and make failures deterministic and visible.

---

Final appraisal: who should care most, and how urgent is this?​

• Urgency: Moderate to high for internet-facing token processors. The CVSS score and EPSS reflect a moderate risk, but ease of exploitation and wide distribution of token-handling code make rapid remediation important for services that accept unauthenticated or externally sent JWE tokens. (github.com)
• Who should act immediately:
• Backend teams that process JWE tokens in public APIs or proxies.
• Container image maintainers and distro packagers that include go-jose.
• Security teams responsible for dependency management and incident response.
• Who should plan and monitor:
• Internal applications that accept tokens only from trusted partners (they may have lower exposure but should still inventory and decide whether to upgrade).
• Offline tooling or build-time utilities that only run in trusted CI/CD contexts—these still benefit from upgrades but can be prioritized lower if resource constraints exist.

---

Closing recommendations​

• Treat CVE‑2024‑28180 as a patch-and-mitigate event: update go-jose to the patched versions and enforce process-level resource controls.
• Use supply‑chain scanning to find all instances of the vulnerable library across images, packages, and vendor copies.
• Implement defense‑in‑depth: timeouts, worker sandboxes, request throttles, and observability for decompression failures.
• If you distribute images or products that embed go-jose, publish clear guidance and timelines for customers and partners about when images are rebuilt and patched. (github.com)

CVE‑2024‑28180 is a clear reminder that resource amplification is an operationally significant risk that straddles code correctness and system design. The fix in go-jose is practical and timely, but the real work for security teams is complete inventory, coordinated patching across the supply chain, and putting runtime guards in place so a single malformed token can’t take a service offline. (github.com)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center