CVE-2025-54887: JWE Ruby Library Information Disclosure

CVE-2025-54887 Overview

CVE-2025-54887 is a critical cryptographic vulnerability in the ruby-jwe library, a Ruby implementation of the RFC 7516 JSON Web Encryption (JWE) standard. In versions 1.1.0 and below, authentication tags of encrypted JWEs can be brute forced due to improper integrity check validation. This weakness (CWE-354: Improper Validation of Integrity Check Value) may result in loss of confidentiality for JWEs and provide attackers with the ability to craft arbitrary JWEs.

Critical Impact
Attackers can modify JWEs to decrypt to arbitrary values, extract plaintext through parsing oracle attacks, and recover the GCM internal GHASH key, compromising cryptographic integrity even for non-AES-GCM users.

Affected Products

ruby-jwe versions 1.1.0 and below
Applications using ruby-jwe for JSON Web Encryption
Ruby applications implementing RFC 7516 JWE standard with the affected library

Discovery Timeline

2025-08-08 - CVE-2025-54887 published to NVD
2025-08-08 - Last updated in NVD database

Technical Details for CVE-2025-54887

Vulnerability Analysis

The vulnerability exists in the AES-GCM decryption implementation within the ruby-jwe library. The core issue is that the library did not properly validate the byte size of authentication tags before using them in the decryption process. GCM (Galois/Counter Mode) authentication tags are critical security components that ensure the integrity and authenticity of encrypted data.

Without proper validation of tag length, an attacker can submit truncated or malformed authentication tags. This creates a brute-force opportunity where the reduced tag space dramatically decreases the computational effort required to forge valid authentication tags. The attack impacts confidentiality through multiple vectors: JWEs can be modified to decrypt to attacker-controlled values, decrypted content can be extracted by observing parsing differences (a form of oracle attack), and critically, the GCM internal GHASH key can be recovered.

The GHASH key recovery is particularly severe because even users who do not directly use AES-GCM encryption algorithms are affected. Once the GHASH key is compromised, attackers can forge authentication tags for any future or past messages encrypted with the same key, requiring mandatory key rotation after patching.

Root Cause

The root cause is the absence of authentication tag length validation in the lib/jwe/enc/aes_gcm.rb file. The original implementation accepted authentication tags of any byte size without verification, allowing attackers to supply truncated tags that are easier to brute force. According to the GCM specification, authentication tags should be exactly 16 bytes (128 bits) for full security strength.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

Intercepting encrypted JWE tokens transmitted over the network
Submitting modified JWE tokens with truncated authentication tags to the vulnerable application
Observing application responses to determine decryption success or failure
Using differential analysis to brute force valid authentication tags
Recovering the GHASH key through cryptanalytic techniques on the weakened GCM implementation

ruby

         cipher.send(direction)
         cipher.key = cek
         cipher.iv = iv
-        cipher.auth_tag = tag if direction == :decrypt
+        if direction == :decrypt
+          raise JWE::InvalidData, 'Invalid ciphertext or authentication tag' unless tag.bytesize == 16
+
+          cipher.auth_tag = tag
+        end
         cipher.auth_data = auth_data
       end

Source: GitHub Commit

The patch adds explicit validation requiring the authentication tag to be exactly 16 bytes before proceeding with decryption, raising a JWE::InvalidData exception for malformed tags.

Detection Methods for CVE-2025-54887

Indicators of Compromise

Unusual patterns of JWE decryption failures in application logs
High volume of JWE token submissions with varying authentication tag lengths
Anomalous network traffic patterns suggesting oracle-style probing attacks
Evidence of tampered JWE tokens in request logs with non-standard tag sizes

Detection Strategies

Monitor application logs for increased JWE::InvalidData or authentication tag errors after patching
Implement network-level detection for repeated JWE token submissions from single sources
Audit application dependencies to identify vulnerable ruby-jwe versions using bundle audit or similar tools
Review historical logs for patterns consistent with brute-force authentication tag attacks

Monitoring Recommendations

Enable detailed logging for JWE decryption operations including tag validation failures
Configure alerting on repeated failed decryption attempts from individual IP addresses
Implement rate limiting on endpoints that process JWE tokens
Monitor for unusual token structure anomalies in incoming JWE payloads

How to Mitigate CVE-2025-54887

Immediate Actions Required

Upgrade ruby-jwe to version 1.1.1 immediately
Rotate all encryption keys used with the affected library versions after upgrading
Audit systems for potential exploitation using application logs
Review all applications that depend on ruby-jwe for vulnerable versions

Patch Information

The vulnerability is fixed in ruby-jwe version 1.1.1. The patch adds explicit validation to ensure authentication tags are exactly 16 bytes before processing decryption operations. The fix is available in commit 1e719d79ba3d7aadaa39a2f08c25df077a0f9ff1.

For detailed information, refer to the GitHub Security Advisory GHSA-c7p4-hx26-pr73.

Workarounds

Upgrade to version 1.1.1 as the primary remediation (no practical workaround exists)
Implement application-level validation of JWE token structure before processing
Consider network-level filtering to reject malformed JWE tokens at the edge
Temporarily disable JWE-dependent functionality if patching is delayed

bash

# Upgrade ruby-jwe to patched version
bundle update jwe

# Verify installed version
bundle show jwe

# Run security audit to confirm fix
bundle audit check --update