CVE-2026-105115 in OpenAM
Summary
by MITRE • 10/03/2026
OpenAM before 16.1.3 contains an unauthenticated arbitrary class instantiation vulnerability in the legacy JAX-RPC SOAP interface that allows remote attackers to load classes without authentication. Attackers can send SOAP requests to /jaxrpc/* with an unverified session identifier and a chosen class name, crashing the server, probing the classpath, or potentially reaching code execution via gadget chains.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in OpenAM versions prior to 16.1.3 represents a critical security flaw within its legacy JAX-RPC SOAP interface architecture. This issue stems from an unauthenticated arbitrary class instantiation mechanism that allows remote attackers to load Java classes without requiring valid authentication credentials. The core of the problem lies in how the application handles incoming SOAP requests directed at the /jaxrpc/* endpoint path. Specifically, the system fails to properly validate session identifiers or enforce access controls before processing the request payload, which includes a chosen class name provided by the attacker. This lack of strict input validation and authentication checks creates a direct pathway for exploitation against systems that have not yet applied the necessary patches or upgrades.
From a technical perspective, this vulnerability is classified under CWE-284, Improper Access Control, as it allows unauthorized actors to interact with internal system components. Furthermore, because it involves loading arbitrary classes which can lead to remote code execution through gadget chains, it aligns closely with CWE-94, Improper Control of Generation of Code (Code Injection), and specifically the technique described in MITRE ATT&CK T1059 as Command and Scripting Interpreter via Java. The attacker constructs a SOAP request containing an unverified session identifier alongside a payload designed to instantiate specific classes within the application's classpath. By manipulating these parameters, the malicious actor bypasses standard security boundaries that are typically enforced by authentication modules or servlet filters.
The operational impact of this vulnerability is severe and multifaceted. Initially, successful exploitation can lead to denial of service conditions where the server crashes due to invalid class loading attempts or resource exhaustion. More critically, attackers can use this vector for reconnaissance purposes by probing the application's classpath to identify available libraries and dependencies. This information gathering phase is often a precursor to more destructive actions. The most significant risk arises from the potential for remote code execution through gadget chains. If specific vulnerable libraries are present in the environment, such as those commonly targeted by deserialization attacks like Apache Commons Collections or Spring Framework gadgets, an attacker can chain these classes together to execute arbitrary commands on the underlying operating system with the privileges of the application process.
Mitigation strategies must prioritize immediate remediation through software updates. Administrators should upgrade OpenAM to version 16.1.3 or later, where this flaw has been addressed by implementing stricter validation for session identifiers and restricting class instantiation capabilities within the legacy SOAP interface. In environments where upgrading is not immediately feasible, network-level controls such as web application firewalls can be configured to block requests targeting the /jaxrpc/* endpoint unless they originate from trusted sources with valid authentication tokens. Additionally, reviewing and minimizing the set of available Java libraries in the deployment environment reduces the attack surface by removing potential gadgets that could be leveraged for code execution. Regular security audits and penetration testing should also be conducted to ensure no other legacy interfaces remain exposed without adequate protection mechanisms.