CVE-2026-47424: OpenAM Authenticated Groovy Sandbox Escape to RCE
A flaw in OpenAM's server-side Groovy scripting sandbox lets an authenticated script author run operating-system commands on the host, breaking the only code-level wall between a realm administrator a
The problem
OpenAM's Groovy scripting engine enforces access control through a class allowlist and denylist checked by `GroovySandboxValueFilter`. The default denylist did not include OS-execution classes such as `java.lang.ProcessBuilder` and `java.lang.Runtime`, so a script author could call them directly to spawn arbitrary processes.
Any authenticated user who can create or edit a server-side script in an executed context (authentication, policy condition, OIDC claims) is affected. For a sub-realm admin, this crosses the documented privilege boundary and compromises the entire OpenAM process and every realm it serves.
Proof of concept
A working proof-of-concept for CVE-2026-47424 in org.openidentityplatform.openam:openam-scripting, with the exact payload below.
// Server-side Groovy script submitted via the OpenAM admin console or REST API
// Requires: authenticated session with script-create/edit permission
def cmd = ['/bin/bash', '-c', 'id > /tmp/pwned']
def proc = new ProcessBuilder(cmd)
.redirectErrorStream(true)
.start()
def out = proc.inputStream.text
logger.error('RCE output: ' + out)The `GroovySandboxValueFilter` checks each accessed class against the configured allowlist and denylist at call time. Because `java.lang.ProcessBuilder` (and `java.lang.Runtime`) were absent from the default denylist, the filter passed them as allowed, and the script executed OS commands with JVM process privileges.
The root cause is CWE-693 (Protection Mechanism Failure): the sandbox existed but its default deny rules were incomplete. The 16.1.1 patch adds the missing execution-capable classes to the default denylist so any script attempting to reference them receives a `SecurityException` before the call is made.
Note: the sandbox also cannot block calls made through an allowed class to a disallowed one (transitive calls). The fix addresses direct access; defense in depth through least-privilege OS accounts is still recommended.
The fix
Upgrade to OpenAM Community Edition 16.1.1 or later. The patch adds `java.lang.ProcessBuilder`, `java.lang.Runtime`, and related OS-execution classes to the default Groovy sandbox denylist in `openam-scripting`. Until you can upgrade, restrict script-create and script-edit permissions to fully trusted administrators only, and audit existing scripts for calls to `ProcessBuilder`, `Runtime.exec`, or similar primitives.
Related research
- highCVE-2026-46619CVE-2026-46619: OpenAM MSISDN Authentication Bypass via LDAP Injection
- highCVE-2026-46623CVE-2026-46623: OpenAM OAuth2 Module Account Takeover via Unverified Password Change
- high · 8.5CVE-2026-45048CVE-2026-45048: OpenAM Authenticated Privilege Escalation via Session RPC Token Disclosure
- high · 8.3CVE-2026-45049CVE-2026-45049: OpenAM CDCServlet Session Token Exfiltration via Unvalidated goto Redirect