CVE-2026-91842 in OBP-API
Summary
by MITRE • 09/15/2026
A vulnerability has been found in OpenBankProject OBP-API up to 1.10.1. This impacts the function KryoInjection.invert of the file obp-api/src/main/scala/code/api/cache/Redis.scala of the component Kryo Handler. Such manipulation leads to deserialization. The attack can be launched remotely. A high complexity level is associated with this attack. The exploitability is said to be difficult. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in OpenBankProject OBP-API versions up to 1.10.1 represents a critical security flaw rooted in improper handling of serialized data within the application's caching layer. Specifically, the defect resides in the KryoInjection.invert function located in the Redis.scala file under the obp-api/src/main/scala/code/api/cache directory. This component serves as the handler for interactions with Redis, an in-memory data structure store often used for session management and caching sensitive banking information. The core issue is a lack of validation or sanitization when processing objects that are deserialized using the Kryo library. In Java-based ecosystems, libraries like Kryo allow for efficient serialization and deserialization of complex object graphs. However, if an attacker can control the input stream passed to these deserialization methods without adequate safeguards, they may trigger unintended side effects during the reconstruction of objects in memory.
This specific flaw is classified as a Remote Code Execution vulnerability via insecure deserialization, which aligns with CWE-502: Deserialization of Untrusted Data. The technical mechanism involves manipulating the serialized data stream such that when the Kryo library attempts to invert or reconstruct the object state, it executes arbitrary code defined within maliciously crafted classes embedded in the payload. Because OpenBankProject is designed for financial institutions and handles sensitive banking operations, this vulnerability poses a severe risk to confidentiality, integrity, and availability of critical systems. An attacker who successfully exploits this flaw could gain full control over the server hosting the OBP-API instance, potentially leading to data exfiltration, unauthorized transactions, or complete system compromise.
The attack vector for this vulnerability is remote, meaning it can be exploited by an adversary with network access to the target application without requiring prior authentication in some configurations, although exploitability is noted as difficult due to high complexity requirements. This difficulty likely stems from the need to craft a valid Kryo serialized payload that bypasses any existing type filters or security constraints implemented within the framework. Despite this complexity, public disclosure of proof-of-concept exploits indicates that skilled attackers can leverage known techniques to construct such payloads effectively. The ATT&CK framework categorizes this behavior under T1059: Command and Scripting Interpreter and potentially T1203: Exploitation for Client Execution if the deserialized objects trigger further client-side actions, though in a server context it primarily falls under initial access or privilege escalation vectors depending on the service account privileges.
The operational impact of this vulnerability is significant given the nature of OpenBankProject as an open-source API framework for banking systems. Successful exploitation could allow attackers to read sensitive customer data stored in Redis caches, modify transaction states, or inject malicious logic into subsequent requests processed by the application server. Since the project maintainers have not yet responded to early issue reports, users running affected versions are exposed to this risk without official patches or workarounds provided directly from the source. This lack of immediate remediation support increases the burden on system administrators and security teams responsible for securing these deployments.
Mitigation strategies must focus on isolating the vulnerable component and restricting network access until an upgrade is feasible. Organizations should immediately review their Redis configurations to ensure that only trusted internal services can communicate with the cache backend, thereby limiting the attack surface available to remote adversaries. Implementing strict input validation at the API gateway level before requests reach the OBP-API logic can also help filter out malformed or suspicious payloads characteristic of deserialization attacks. Additionally, upgrading to a patched version once released is essential for long-term security posture. Until then, deploying Web Application Firewalls with rules specifically tuned to detect anomalies in serialized data streams may provide an additional layer of defense against exploitation attempts leveraging this high-complexity vulnerability.