CVE-2025-68931
Padding Oracle Vulnerability in Jervis Library AES/CBC Encryption
Publication date: 2026-01-13
Last updated on: 2026-01-13
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| samrocketman | jervis | to 2.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
| CWE-327 | The product uses a broken or risky cryptographic algorithm or protocol. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability involves a lack of authentication in AES/CBC/PKCS5Padding encryption, making encrypted data vulnerable to padding oracle attacks and ciphertext manipulation, which can compromise confidentiality and integrity. Since the encrypted data primarily consists of short-lived GitHub App authentication tokens, the exposure is limited. However, the lack of strong encryption and integrity checks could potentially impact compliance with standards like GDPR and HIPAA that require protection of sensitive data. The issue is fixed in version 2.2 by switching to AES-GCM, which provides built-in authentication and integrity, thus improving compliance posture. Users are advised to upgrade to mitigate risks. No explicit compliance impact is detailed, but the cryptographic weaknesses could be considered non-compliant with best practices required by such regulations. [1]
Can you explain this vulnerability to me?
The vulnerability in Jervis prior to version 2.2 involves the use of AES encryption in CBC mode with PKCS5 padding (AES/CBC/PKCS5Padding) without any authentication mechanism. This lack of authentication makes the encryption susceptible to padding oracle attacks and ciphertext manipulation, which can compromise the confidentiality and integrity of the encrypted data. Specifically, the encryption uses a 256-bit AES key and an initialization vector (IV) but does not verify the integrity of the ciphertext, allowing attackers to exploit the padding scheme to decrypt or alter data. This issue is fixed in version 2.2 by switching to AES in Galois/Counter Mode (AES/GCM/NoPadding), which provides built-in authentication and integrity checks. [1]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to perform padding oracle attacks and manipulate ciphertext, potentially compromising the confidentiality and integrity of encrypted data handled by Jervis. Although the risk is considered low for internal library use, it becomes critical if you directly use the vulnerable encryption methods. The encrypted data mainly consists of GitHub App authentication tokens that expire within one hour, which limits exposure. However, exploitation could lead to unauthorized access or tampering with sensitive authentication tokens. Upgrading to Jervis version 2.2 mitigates this risk by implementing authenticated encryption. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by checking the version of the Jervis library in use. Versions prior to 2.2 are vulnerable. Since the issue is related to the use of AES/CBC/PKCS5Padding encryption without authentication in the Jervis library, you can detect vulnerable instances by identifying Jervis versions below 2.2 in your environment. There are no specific network or system commands provided to detect the vulnerability directly. However, you can check the installed Jervis version using commands relevant to your environment, for example, if using Maven: `mvn dependency:list | grep jervis` or inspecting the version in your build files or dependency management tools. No direct commands for detecting the vulnerability on the network or system are provided. [1]
What immediate steps should I take to mitigate this vulnerability?
The immediate step to mitigate this vulnerability is to upgrade the Jervis library to version 2.2 or later. Version 2.2 replaces the vulnerable AES/CBC/PKCS5Padding encryption with AES/GCM/NoPadding, which provides built-in authentication and integrity checks, effectively fixing the padding oracle attack vulnerability. No workarounds are provided, so upgrading is the recommended and necessary action. [1]