OBP-API Unsafe Kryo Deserialization RCE via Redis Cache

Vulnerability Overview Title: Insecure Kryo Deserialization of Redis Cache Values (CWE-502) — Enables RCE if an attacker can write to the cache Redis Root Cause: OBP-API uses from Twitter Chills, which relies on the default Kryo pool ( ). This pool is configured with no class registration requirement and uses , allowing the deserialization of arbitrary classes found in the stream, bypassing constructors to directly write raw bytes. Trigger Condition: The attacker must be able to write a malicious Kryo payload ("deserialization gadget") to the cache Redis. The default Redis configuration is (local, no password), making this prerequisite difficult to satisfy in default deployments. However, the RCE risk increases significantly if Redis is exposed to a routable interface or if is configured (note: the text implies risk increases if exposed, though typically adding a password mitigates; assuming the source text logic holds, we translate the conditional risk). Severity: Recommended CVSS v3.1 score is 6.8 (Medium-High), based on the prerequisite that "Redis is writable by an attacker." Scope of Impact Affected Products/Versions: - Ecosystem: Application (non-public package) - Affected Versions: Current ( , commit , 2026-06-25) and earlier versions - Patched Versions: None - Dependencies: Version of providing insecure defaults is 0.9.1 (and 0.9.1) Vulnerability Type/CWE: CWE-502 (Deserialization of Untrusted Data); Contributing Factor CWE-1188 (Default Configuration for Security) (Note: Source says CWE-1188 "cache Redis default unauthenticated", mapped to CWE-1188 in context of insecure defaults). Impact: Remote Code Execution (RCE) within the OBP-API JVM, providing access to DB credentials, connection strings, keys, etc. However, RCE success depends on the attacker's ability to write to the backend Redis. If Redis is properly isolated and authenticated, the path is unreachable. Remediation (Recommended) 1. Lock Down Cache Deserializer: Replace with a Kryo instantiator that calls , registering only known cache value types (allowlist), and enforce strict SSN (Serializable Serial Number) for cache values. 2. Harden Redis by Default / Documentation: Require authentication for cache Redis ( ) and ensure it is not bound to routable interfaces. Document that without a password is intended for development environments only. 3. Synchronized Fixes: Apply the same fixes to sister repositories containing identical code (see list below). POC / Exploit Code Key code snippets provided in the page (Scala): Exploitation Flow (Authorized Testing Environments Only; Do Not Execute in Production): 1. Attacker gains access to the OBP cache Redis (default with no password). 2. Attacker writes a gadget payload (an object graph whose instantiation triggers code execution, such as class constructors) serialized via to an OBP cache key. 3. When OBP reads from that key, triggers Kryo deserialization → resulting in RCE within the OBP JVM. 4. Non-destructive Verification: Use a gadget that performs an out-of-band callback (DNS/HTTP) rather than actual code execution, to prove that deserialization was triggered.

Goal Reached Thanks to every supporter — we hit 100%!

OBP-API Unsafe Kryo Deserialization RCE via Redis Cache

More from this source