Summary
openEQUELLA before 2026.1.0 contains an authenticated remote code execution vulnerability in its HTTP invoker endpoint. An authenticated non-guest user may bypass deserialization filtering and cause arbitrary code execution when crafted serialized data reaches an unsafe object-processing and JNDI execution path.
Affected context
The vulnerability occurs in openEQUELLA deployments that expose the HTTP invoker functionality under /invoker/* and permit access by authenticated non-guest users. Risk is present when serialized Java objects are processed through a filtering mechanism that can be bypassed, allowing nested data to reach a separate deserialization stream without equivalent class restrictions.
Exploit preconditions
- Attack surface: The HTTP invoker endpoint under
/invoker/* - Required access: Valid authentication as a non-guest user
- Trigger point: Processing of attacker-controlled serialized Java data by the invoker service
- Why exploitation is possible: A class-name denylist applied by
PluginAwareObjectInputStreamdoes not consistently constrain nested deserialization performed by anotherObjectInputStream, allowing unsafe object processing to reach a JNDI-related execution sink
Why this happens
The issue combines unsafe Java deserialization with incomplete enforcement of a class-name restriction policy. Although the initial stream applies a denylist, nested serialized content can be encapsulated in an object whose internal data is later processed by a separate stream without the same restrictions. This inconsistent trust boundary maps primarily to CWE-502: Deserialization of Untrusted Data and is related to CWE-184: Incomplete List of Disallowed Inputs, because a denylist does not comprehensively constrain all deserialization paths.
Potential impact
- An authenticated user may execute arbitrary code in the application process
- The application host may be compromised
- Confidential application data could be accessed or altered
- Server-side credentials and tokens could be exposed
- The compromised service could be used for lateral movement or further attacks
General mitigation guidance
Mitigation generally focuses on eliminating unsafe native Java deserialization from network-facing interfaces and ensuring that every nested or delegated parsing path applies the same trust controls.
Common defensive patterns include:
- Prefer typed, schema-validated data formats that do not instantiate arbitrary Java classes
- Avoid relying solely on denylist-based deserialization filters
- Apply allowlisted class constraints consistently across all object streams and wrapper types
- Restrict or remove unnecessary HTTP invoker and JNDI functionality
- Run the application with least-privilege accounts and tightly scoped outbound network access
- Isolate the service from sensitive management interfaces and internal resources
- Treat authenticated users and serialized request data as untrusted
How teams detect issues like this
Organizations can look for:
- Static analysis findings involving
ObjectInputStream, native Java serialization, and deserialization of request data - Code paths that create secondary object streams or deserialize nested wrapper objects
- Review signals showing denylist-only filtering or inconsistent filter propagation
- HTTP invoker endpoints exposed beyond intended administrative boundaries
- Unexpected JNDI lookups, outbound naming-service connections, or unusual child processes from the application
- Policy checks requiring schema-based serialization and restricting network-accessible Java deserialization
Automated application security and code review tools may help identify unsafe deserialization APIs, incomplete filtering, and reachable JNDI sinks.
