Go JOSE DoS Vulnerability: Fixing JWE Object Exploitation in Rclone

Introduction

Cryptographic libraries sit at the heart of modern application security. When they fail, the consequences ripple outward — affecting every application that trusts them. That's exactly the scenario at play with CVE-2026-34986, a high-severity Denial of Service (DoS) vulnerability discovered in github.com/go-jose/go-jose/v4, a widely-used Go library for JSON Object Signing and Encryption (JOSE) operations.

Rclone — the popular open-source cloud storage sync tool — was among the affected projects, as it relies on go-jose/v4 for cryptographic operations. This post breaks down the vulnerability, explains how it could be exploited, and walks through the surgical fix that closes the security gap.

CVE at a Glance
- CVE ID: CVE-2026-34986
- Severity: HIGH
- Affected Package: github.com/go-jose/go-jose/v4 ≤ v4.1.3
- Fixed In: v4.1.4
- Impact: Denial of Service via crafted JSON Web Encryption (JWE) object

What Is JSON Web Encryption (JWE)?

Before diving into the vulnerability, it's worth understanding the attack surface.

JSON Web Encryption (JWE) is a standard (RFC 7516) for representing encrypted content using JSON-based data structures. It's commonly used in:

• OAuth 2.0 / OpenID Connect flows for encrypting tokens
• API authentication systems that pass sensitive claims securely
• Secure messaging between microservices

A JWE object looks like this (compact serialization):

BASE64URL(JWE Protected Header) . BASE64URL(JWE Encrypted Key) . BASE64URL(JWE Initialization Vector) . BASE64URL(JWE Ciphertext) . BASE64URL(JWE Authentication Tag)

The go-jose library is responsible for parsing and processing these objects in Go applications. And that parsing step — specifically how the library handles crafted, malformed, or adversarially constructed JWE objects — is where the vulnerability lives.

The Vulnerability Explained

What Goes Wrong?

CVE-2026-34986 is a Denial of Service vulnerability triggered by processing a specially crafted JWE object. When the vulnerable versions of go-jose/v4 (≤ v4.1.3) parse a malicious JWE payload, they can be forced into an expensive or unbounded computation — consuming excessive CPU or memory resources.

This class of vulnerability is sometimes called an algorithmic complexity attack or resource exhaustion attack. The attacker doesn't need to break the encryption — they just need to make the server work so hard trying to process the input that it becomes unavailable to legitimate users.

How Could It Be Exploited?

The attack scenario is straightforward:

1. Identify a target endpoint that accepts JWE tokens — such as an API that processes encrypted JWTs, an OAuth callback, or any service that decrypts user-supplied tokens.
2. Craft a malicious JWE object — specifically constructed to trigger the expensive code path in the parser.
3. Send the payload repeatedly — even a moderate request rate can exhaust server resources if each request triggers the vulnerable path.
4. Service becomes unavailable — legitimate users are denied access while the server struggles to process the flood of malicious inputs.

Attacker                          Vulnerable Server
   |                                     |
   |-- POST /api/auth (crafted JWE) ---->|
   |                                     | [CPU/Memory spike]
   |-- POST /api/auth (crafted JWE) ---->|
   |                                     | [Resources exhausted]
   |-- POST /api/auth (crafted JWE) ---->|
                                         | ❌ Service unavailable
                                         | ❌ Legitimate users denied

Why Is This Particularly Dangerous?

Several factors amplify the risk:

• No authentication required: An attacker typically doesn't need valid credentials to submit a JWE token for processing. The vulnerability triggers before authentication succeeds.
• Low attack complexity: Crafting a malicious JWE object requires knowledge of the standard format, not advanced cryptographic skills.
• Broad impact: Any Go application using go-jose/v4 ≤ v4.1.3 that processes externally-supplied JWE tokens is potentially vulnerable.
• Supply chain exposure: Even if your code doesn't directly call go-jose, a transitive dependency might — making this a classic supply chain vulnerability.

The Fix

What Changed?

The fix is elegantly simple: a one-line version bump in go.mod.

Before (vulnerable):

// go.mod
github.com/go-jose/go-jose/v4 v4.1.3 // indirect

After (fixed):

// go.mod
github.com/go-jose/go-jose/v4 v4.1.4 // indirect

The corresponding go.sum entries were also updated to reflect the new cryptographic hashes for the fixed version:

# Removed (vulnerable):
github.com/go-jose/go-jose/v4 v4.1.3 h1:CVLmWDhDVRa6Mi/IgCgaopNosCaHz7zrMeF9MlZRkrs=
github.com/go-jose/go-jose/v4 v4.1.3/go.mod h1:x4oUasVrzR7071A4TnHLGSPpNOm2a21K9Kf04k1rs08=

# Added (fixed):
github.com/go-jose/go-jose/v4 v4.1.4 h1:moDMcTHmvE6Groj34emNPLs/qtYXRVcd6S7NHbHz3kA=
github.com/go-jose/go-jose/v4 v4.1.4/go.mod h1:x4oUasVrzR7071A4TnHLGSPpNOm2a21K9Kf04k1rs08=

How Does the Fix Work?

The v4.1.4 release of go-jose patches the vulnerable parsing logic to add proper input validation and bounds checking before performing expensive cryptographic operations. This typically involves one or more of the following mitigations:

• Size limits: Rejecting JWE objects that exceed reasonable size thresholds before processing begins.
• Complexity caps: Limiting the computational work performed on any single input, regardless of its structure.
• Early rejection: Failing fast on malformed inputs rather than attempting to process them fully.

The result is that a crafted JWE object is rejected quickly and cheaply, rather than causing the server to spiral into resource exhaustion.

Why Is a Dependency Upgrade the Right Fix?

It's worth noting that this fix happens entirely at the dependency layer — no application code needed to change. This is by design:

• The vulnerability exists in library internals, not in how Rclone calls the library.
• The go-jose maintainers are best positioned to fix their own parsing logic.
• Upgrading the dependency gets the fix for all call sites simultaneously.

This is a great example of why keeping dependencies up to date is a security practice, not just a maintenance chore.

Conclusion

CVE-2026-34986 is a reminder that security is a supply chain problem. You can write perfectly secure application code and still be vulnerable because of what's hiding in your go.mod file. The go-jose vulnerability required no sophisticated cryptographic attack — just a crafted input and an unpatched library.

The key takeaways from this incident:

1. Transitive dependencies matter — go-jose was an indirect dependency of Rclone, yet it represented a real attack surface.
2. DoS is a real threat — Availability is part of the CIA triad. A service that's down is a service that's breached from a business continuity perspective.
3. The fix was simple — One line in go.mod. The hardest part is knowing you're vulnerable, which is why automated scanning is non-negotiable.
4. Defense in depth applies — Even after patching, rate limiting, input validation, and timeouts provide additional resilience.

Security isn't a destination — it's a continuous process of monitoring, updating, and improving. Tools like automated vulnerability scanners and services like OrbisAI Security exist precisely to make that process less burdensome, so your team can focus on building great software while staying secure.

Stay patched. Stay vigilant. Ship secure code. 🔒

This vulnerability was detected and fixed automatically by OrbisAI Security. Automated security fixes help teams respond to CVEs faster, reducing the window of exposure from weeks to hours.