CVE-2026-47424 in OpenAM
Summary
by MITRE • 09/15/2026
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, GroovySandboxValueFilter permits an authenticated server-side script author to escape the scripting sandbox despite the default class allow and deny lists. A user such as a sub-realm RealmAdmin who can create or edit a script in an executed context can invoke operating-system commands as the OpenAM application server account, crossing the realm-scoped administration boundary and compromising the JVM and every realm it serves. This issue is fixed in version 16.1.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified involves a critical flaw within the GroovySandboxValueFilter component of Oracle's Open Access Management solution, specifically affecting versions prior to 16.1.1. This filter is designed to enforce security boundaries by restricting server-side scripts executed within specific contexts, ensuring that such scripts operate within a confined sandbox environment. The core technical failure lies in the inability of the default class allow and deny lists to effectively contain Groovy script execution. Despite these predefined restrictions, an authenticated user with the ability to create or edit scripts can exploit parsing ambiguities or implementation gaps to escape the intended sandbox constraints. This bypass allows the execution of arbitrary code outside the restricted environment, fundamentally undermining the security model that relies on isolation between different administrative realms and operational contexts.
From a technical perspective, this flaw represents a classic server-side request forgery combined with insecure deserialization or script injection characteristics, often categorized under CWE-94 as Improper Control of Generation of Code (Code Injection). The attacker leverages their existing authentication credentials to manipulate the scripting engine, effectively bypassing the sandbox's protective mechanisms. By escaping the sandbox, the malicious script gains access to underlying Java classes and methods that are normally restricted. This escalation enables the execution of operating-system commands directly on the host machine running the OpenAM application server. The severity is compounded by the fact that this exploitation does not require additional authentication or privilege escalation beyond what a standard RealmAdmin possesses within their assigned realm, making it an accessible vector for insiders or compromised accounts with moderate privileges.
The operational impact of this vulnerability is severe and far-reaching. Once the sandbox escape is achieved, the attacker can execute commands as the user account under which the OpenAM application server operates. This typically grants access to sensitive system resources, configuration files, and potentially other applications running on the same host. Furthermore, because OpenAM often serves multiple realms in a centralized deployment, compromising the JVM through this vulnerability allows an attacker from one sub-realm to impact every realm served by that instance. This crosses administrative boundaries, effectively neutralizing the multi-tenancy isolation model intended by the product architecture. An adversary could use this access to exfiltrate sensitive identity data, modify authentication policies, install persistent backdoors, or pivot further into the internal network using the compromised server as a foothold.
In terms of threat modeling and industry standards, this vulnerability aligns with MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse (T1059) and potentially Privilege Escalation if the application server runs with elevated privileges. The scenario also reflects CWE-284 Improper Access Control, as the system fails to properly restrict access to critical functions based on user roles or context boundaries. Defense in depth strategies are compromised because the sandbox mechanism, which serves as a secondary control layer for script execution integrity, is rendered ineffective by this flaw.
To mitigate this risk, organizations must immediately upgrade OpenAM to version 16.1.1 or later, where the GroovySandboxValueFilter has been patched to correctly enforce class allow and deny lists. Until patching can be performed, administrators should review access controls strictly limiting who holds RealmAdmin privileges in executed script contexts. Additionally, running the application server with minimal necessary permissions using principle of least privilege can reduce the impact if exploitation occurs. Monitoring for unusual process creation or command execution originating from the OpenAM service account is also recommended to detect potential active exploitation attempts.