CVE-2025-68925: Jervis JWT Algorithm Verification Flaw

CVE-2025-68925 Overview

CVE-2025-68925 is a cryptographic vulnerability in Jervis, a library used for Job DSL plugin scripts and shared Jenkins pipeline libraries. Prior to version 2.2, the Jervis library fails to properly validate that the JWT (JSON Web Token) header specifies the expected "alg":"RS256" algorithm. This vulnerability allows attackers to potentially bypass signature verification by manipulating the algorithm specified in the JWT header, a classic JWT algorithm confusion attack.

Critical Impact

Attackers may forge authentication tokens by exploiting the missing JWT algorithm validation, potentially gaining unauthorized access to Jenkins pipelines and CI/CD workflows.

Affected Products

• Jervis library versions prior to 2.2
• Jenkins environments using vulnerable Jervis versions for Job DSL plugin scripts
• Jenkins pipeline libraries integrating unpatched Jervis components

Discovery Timeline

• 2026-01-13 - CVE CVE-2025-68925 published to NVD
• 2026-01-13 - Last updated in NVD database

Technical Details for CVE-2025-68925

Vulnerability Analysis

This vulnerability falls under CWE-347 (Improper Verification of Cryptographic Signature). The core issue stems from the Jervis library's failure to enforce strict algorithm validation when processing JWT tokens. JWT tokens contain a header that specifies which cryptographic algorithm should be used for signature verification. When a library does not validate this algorithm field, it becomes susceptible to algorithm confusion attacks.

In a typical RS256-based JWT implementation, the server uses an RSA public key to verify signatures created with the corresponding private key. However, if the algorithm validation is missing, an attacker can potentially change the algorithm in the JWT header to HS256 (HMAC-SHA256) and sign the token using the public key as the HMAC secret. Since the public key is often publicly available, this effectively allows token forgery.

The vulnerability is network-accessible and requires no user interaction or special privileges to exploit, making it a concern for any Jenkins environment utilizing the affected Jervis versions.

Root Cause

The root cause is the absence of explicit validation logic to ensure that incoming JWT tokens specify RS256 as the signing algorithm. The code path that processes JWT headers accepted any algorithm value without verification, trusting the client-provided algorithm rather than enforcing server-side expectations. This design flaw allows attackers to dictate which algorithm the server uses for signature verification.

Attack Vector

The attack leverages the network-accessible nature of Jenkins pipelines using Jervis. An attacker can craft a malicious JWT token with a manipulated algorithm header:

1. The attacker obtains the public RSA key used by the target Jervis implementation (often publicly accessible)
2. The attacker creates a forged JWT payload with desired claims
3. The attacker changes the JWT header algorithm from RS256 to HS256
4. The attacker signs the token using the public key as the HMAC secret
5. The vulnerable Jervis library accepts the forged token, granting unauthorized access

The vulnerability exploitation does not require authentication and can be performed remotely over the network. Technical details and the specific code changes addressing this issue can be found in the GitHub Security Advisory GHSA-5pq9-5mpr-jj85.

Detection Methods for CVE-2025-68925

Indicators of Compromise

• Unusual JWT tokens in authentication logs with unexpected algorithm values in the header (e.g., HS256 instead of expected RS256)
• Authentication events from unexpected sources or with anomalous timing patterns
• Pipeline executions or Job DSL script modifications by unauthorized users
• Increased failed authentication attempts followed by successful ones with different token characteristics

Detection Strategies

• Implement JWT header inspection at the application or WAF layer to flag tokens not using RS256
• Deploy monitoring rules to detect algorithm confusion patterns in authentication traffic
• Review Jenkins audit logs for unauthorized pipeline modifications or Job DSL script changes
• Perform dependency scanning to identify Jervis library versions below 2.2

Monitoring Recommendations

• Enable comprehensive logging for all JWT-based authentication events in Jenkins
• Configure alerts for authentication anomalies in CI/CD pipeline access patterns
• Monitor network traffic to Jenkins instances for unusual authentication request patterns
• Implement Software Composition Analysis (SCA) tools to continuously track Jervis library versions across your environment

How to Mitigate CVE-2025-68925

Immediate Actions Required

• Upgrade Jervis library to version 2.2 or later immediately
• Review Jenkins pipeline access logs for any signs of unauthorized access or suspicious token usage
• Rotate any secrets or credentials that may have been exposed through affected Jenkins pipelines
• Temporarily restrict network access to Jenkins instances if immediate patching is not possible

Patch Information

The vulnerability is fixed in Jervis version 2.2. The fix implements proper validation to ensure that JWT headers explicitly specify "alg":"RS256" before processing tokens. The security patch can be reviewed in the GitHub Commit. Organizations should update their Jervis dependencies to version 2.2 or higher through their standard dependency management processes.

Workarounds

• Implement network-level access controls to restrict who can send JWT tokens to Jenkins instances
• Deploy a reverse proxy or Web Application Firewall (WAF) that validates JWT algorithm headers before forwarding requests
• Consider disabling JWT-based authentication temporarily in favor of alternative authentication mechanisms until patching is complete
• Implement additional authentication layers such as IP allowlisting for sensitive Jenkins operations

# Verify current Jervis version and update
# Check Gradle dependencies
grep -r "jervis" build.gradle

# Update to patched version in build.gradle
# dependencies {
#     implementation 'net.gleske:jervis:2.2'
# }

# For Maven projects, update pom.xml
# <dependency>
#     <groupId>net.gleske</groupId>
#     <artifactId>jervis</artifactId>
#     <version>2.2</version>
# </dependency>