CVE-2025-68698: 
Java vulnerability analysis and mitigation

CVE-2025-68698 is a cryptographic weakness in the Jervis library (a Job DSL plugin and shared Jenkins pipeline library) where RSA encryption uses PKCS#1 v1.5 padding (PKCS1Encoding) instead of the modern OAEP padding scheme, making it susceptible to Bleichenbacher padding oracle attacks. All versions of net.gleske:jervis prior to 2.2 are affected. The vulnerability was disclosed on January 13, 2026, via a GitHub Security Advisory. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (GitHub Advisory).

The root cause is classified as CWE-327 (Use of a Broken or Risky Cryptographic Algorithm). Specifically, the SecurityIO.groovy class in Jervis uses Bouncy Castle's PKCS1Encoding with RSAEngine for both encryption and decryption of AES keys, as seen at lines 463–465 and 495–497 of the vulnerable source file (GitHub Advisory). PKCS#1 v1.5 RSA padding is vulnerable to Bleichenbacher's 1998 adaptive chosen-ciphertext attack, where an attacker with access to a decryption oracle — exploitable via timing differences or distinct error messages — can iteratively decrypt RSA-encrypted ciphertext without possessing the private key. The attack requires the ability to submit crafted ciphertexts and observe the oracle's responses, making network accessibility a key precondition (GitHub Advisory, GitHub Commit).

Successful exploitation allows an attacker to decrypt RSA-encrypted AES keys stored at rest, potentially exposing the plaintext data they protect — in Jervis's default use case, these are GitHub App authentication tokens stored in local-only storage (GitHub Advisory). The confidentiality impact is rated High, with no integrity or availability impact. For Jervis's internal use, practical risk is mitigated by the short-lived nature of the stored tokens (expiring within one hour), but consumers who directly invoke Jervis's cryptographic methods in other contexts face a critical-severity exposure depending on what data is encrypted (Feedly).

1. Identify the target: Locate a deployment using net.gleske:jervis versions prior to 2.2 where the library's RSA decryption methods are exposed or accessible (e.g., via a network-accessible service that wraps Jervis cryptographic operations).
2. Obtain a ciphertext: Capture or obtain an RSA-encrypted AES key (ciphertext) produced by Jervis's rsaEncryptBytes method using PKCS#1 v1.5 padding.
3. Access a decryption oracle: Identify a mechanism — such as timing differences in decryption responses or distinct error messages returned by the application — that reveals whether a submitted ciphertext has valid PKCS#1 v1.5 padding.
4. Execute Bleichenbacher's attack: Iteratively submit crafted ciphertexts to the oracle, using the oracle's responses to narrow down the plaintext value. This adaptive chosen-ciphertext attack may require thousands to millions of queries depending on RSA key size.
5. Recover the AES key: After sufficient oracle queries, reconstruct the plaintext AES key from the accumulated oracle responses.
6. Decrypt stored data: Use the recovered AES key to decrypt the AES-encrypted data (e.g., GitHub App authentication tokens) stored by Jervis's CipherMap (GitHub Advisory).

• Network: Unusually high volume of RSA decryption requests to any service wrapping Jervis cryptographic methods; repeated requests with slightly modified ciphertexts (characteristic of oracle probing).
• Logs: Application logs showing a large number of decryption errors or padding-related exceptions (e.g., InvalidCipherTextException from Bouncy Castle) in rapid succession, which may indicate oracle probing attempts.
• Application Behavior: Anomalous patterns of decryption calls with varied inputs from a single source IP, particularly if the application exposes decryption functionality over a network interface.

Upgrade to Jervis version 2.2 or later, which replaces PKCS1Encoding with OAEP padding (OAEPEncoding) for RSA operations and migrates AES encryption from CBC mode to AES-256-GCM authenticated encryption (GitHub Advisory, GitHub Commit). Note that upgrading to 2.2 is a breaking change: existing CipherMap encrypted data will be discarded and new GitHub App tokens will be issued. No workarounds are available for the underlying cryptographic weakness; upgrading is the only remediation. Consumers directly using Jervis's RSA encryption/decryption methods in their own applications should treat this as critical priority and upgrade immediately.