OpenAM Unauthenticated RCE via Class.forName in AuthXMLUtils.createCustomCallback (CVE-2026-62379)
OpenAM (org.openidentityplatform.openam:openam-core) versions <= 16.1.1 are vulnerable to unauthenticated remote code execution. The XML-based authentication callback handler AuthXMLUtils.createCustomCallback passes attacker-controlled class names from the authentication request XML directly into Class.forName() and subsequently instantiates the resolved class, allowing an unauthenticated attacker to load and instantiate arbitrary classes on the classpath (CWE-470 Unsafe Reflection) leading to RCE, and reflecting CWE-94 Code Injection. Exploitation requires no authentication and only network access to the OpenAM authentication XML endpoint. A public PoC/advisory exists (GHSA-wg5r-wc3x-39vc). Fixed in OpenAM 16.1.2.
Vulnerability Intelligence
Public PoCAffected Software
- Vendor
- maven
- Product
- org.openidentityplatform.openam:openam-core
- Versions
- <= 16.1.1
Timeline
- Disclosed
- July 24, 2026
References & Proof of Concept
CVSS
What is CVE-2026-62379 OpenAM Unauthenticated RCE via Class.forName in AuthXMLUtils.createCustomCallback (CVE-2026-62379)?
OpenAM Unauthenticated RCE via Class.forName in AuthXMLUtils.createCustomCallback (CVE-2026-62379) (CVE-2026-62379) maps to the Initial Access and Execution tactics — the adversary is trying to get into your network in MITRE ATT&CK.
This page provides production-ready detection logic for OpenAM Unauthenticated RCE via Class.forName in AuthXMLUtils.createCustomCallback (CVE-2026-62379), covering the data sources and telemetry it touches: OpenAM application/access logs ingested via AMA connector, Web Application Firewall logs, Reverse proxy access logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.
MITRE ATT&CK
- Tactic
- Initial Access Execution
let SuspiciousClasses = dynamic(["javax.naming","com.sun.org.apache","org.apache.commons.collections","java.lang.Runtime","java.lang.ProcessBuilder","org.springframework"]);
OpenAMAuthXMLLogs
| where TimeGenerated > ago(1h)
| where RequestPath has_any ("/openam/json/authenticate", "/openam/UI/Login", "/auth/AuthXMLUtils")
| where RequestBody has "createCustomCallback" or RequestBody has "className"
| extend ExtractedClass = extract(@"className=[\"']?([A-Za-z0-9_.\$]+)", 1, RequestBody)
| where isnotempty(ExtractedClass)
| where ExtractedClass has_any (SuspiciousClasses) or ExtractedClass !startswith "org.forgerock" and ExtractedClass !startswith "org.openidentityplatform"
| summarize Attempts=count(), SampleClasses=make_set(ExtractedClass,10) by SourceIP=RemoteIP, Uri=RequestPath, bin(TimeGenerated,5m)
| where Attempts >= 1
| project TimeGenerated, SourceIP, Uri, Attempts, SampleClassesDetects unauthenticated requests to OpenAM authentication endpoints that embed a className parameter consistent with the AuthXMLUtils.createCustomCallback Class.forName injection, flagging classes outside the expected ForgeRock/OpenIdentityPlatform namespace.
Data Sources
Required Tables
False Positives
- Legitimate custom authentication module development/testing in non-prod environments
- Security scanners intentionally probing the endpoint (should be tagged and excluded)
- Load balancer health checks replaying cached authentication payloads with benign classNames
Sigma rule & cross-platform mapping
The detection logic for OpenAM Unauthenticated RCE via Class.forName in AuthXMLUtils.createCustomCallback (CVE-2026-62379) (CVE-2026-62379) above is provided in a vendor-neutral
form so you can deploy it on any SIEM. The same logic is shipped here as native
KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the
following logsource:
logsource:
category: network_connection
product: windowsBrowse the community-maintained Sigma rules for this technique:
Platform-specific guides for CVE-2026-62379
References (4)
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate malicious className parameter in OpenAM authentication POST
Expected signal: HTTP POST request logged in OpenAM access logs / reverse proxy logs containing the className=javax.naming.InitialContext string.
- Test 2Unauthenticated request without valid session/authentication headers
Expected signal: 200/500-level HTTP response captured in access logs alongside the crafted className payload, with no Authorization or session cookie header present.
- Test 3Windows-hosted OpenAM proxy log replay test
Expected signal: IIS/reverse proxy log entry on the Windows collector showing the POST body with the className parameter forwarded to the SIEM.
Response Playbook
Triage
- Confirm the affected OpenAM/OpenIdentityPlatform deployment version via /openam/json/serverinfo/version or artifact manifest; versions <= 16.1.1 are vulnerable and 16.1.2 contains the fix.
- Review the flagged request(s) for the className parameter value and cross-reference against the known-good org.forgerock/org.openidentityplatform namespace to assess intent (recon vs. exploitation).
- Check whether the source IP has a history of scanning or prior malicious activity in threat intel feeds and internal SIEM history.
- Inspect OpenAM server process for unexpected child processes, newly loaded JAR/class files, or outbound network connections spawned immediately after the suspicious request.
Containment
- Immediately restrict or block network access to the OpenAM authentication endpoints (JSON REST /json/authenticate and legacy XML endpoints) from untrusted source IPs via WAF/firewall while remediation is staged.
- Isolate the affected OpenAM instance from sensitive downstream systems (LDAP/AD backends, session stores) to limit lateral movement if compromise is confirmed.
Evidence Collection
- Preserve full HTTP request/response logs (including raw XML/JSON authentication payloads) from the WAF, reverse proxy, and OpenAM application logs covering the incident window.
- Capture a memory/process snapshot and disk forensic image of the OpenAM host if RCE is suspected, prior to remediation actions that would overwrite volatile evidence.
Escalation Criteria
- ! Escalate to incident response if any evidence of successful class instantiation, unexpected process spawning, or outbound C2-like connections is found on the OpenAM host.
- ! Escalate immediately if the OpenAM instance fronts production identity/SSO infrastructure with access to high-value downstream applications, given the unauthenticated 9.8 CVSS RCE nature of this vulnerability.
Investigation Guide
Forensic Artifacts
- >
OpenAM application/access logs showing className parameters in authentication XML/JSON requests - >
JVM heap dump or GC logs showing anomalous class loading events around the time of the suspicious request - >
Process creation logs (Sysmon Event ID 1 / auditd execve) on the OpenAM host correlated to the java process shortly after the malicious request
Tuning Guidance
Build an allowlist of legitimate custom callback class names used by the organization's OpenAM deployment (if any) and exclude them from alerting; tune the 'suspicious' regex/namespace check to match your actual OpenAM package structure, since forks or rebrands may use different base packages. Increase the time window and lower the count threshold in high-security environments given this is a single-shot RCE (no brute force required), and consider alerting on any non-standard className value rather than only a curated suspicious list, since attackers can use arbitrary classpath gadgets not enumerated here. After upgrading to OpenAM 16.1.2+, keep the detection active to catch exploitation attempts against any remaining unpatched instances.
Hunting Queries
Historical hunt across all OpenAM authentication logs to baseline every distinct className value ever submitted, surfacing rare or anomalous classes that warrant manual review even if they weren't caught by the real-time detection thresholds.
OpenAMAuthXMLLogs
| where RequestBody has "className"
| extend ExtractedClass = extract(@"className=[\"']?([A-Za-z0-9_.\$]+)", 1, RequestBody)
| summarize Count=count(), Sources=make_set(RemoteIP) by ExtractedClass
| order by Count descindex=web sourcetype=openam:access
| rex field=_raw "className=(?<className>[A-Za-z0-9_.\$]+)"
| stats count, values(src_ip) as sources by className
| sort -countAtomic Red Team Tests
Sends a crafted POST request to a lab OpenAM authentication endpoint with a className parameter pointing to a non-OpenAM class, simulating the Class.forName injection technique without requiring an actual RCE payload.
Command
curl -s -X POST 'http://LAB_OPENAM_HOST:8080/openam/json/authenticate' -H 'Content-Type: application/json' -d '{"callbacks":[{"type":"CustomCallback","className":"javax.naming.InitialContext"}]}'Cleanup
No persistent changes made; clear any temporary lab logs with: truncate -s 0 /var/log/openam/access.log (lab only)Expected Telemetry
HTTP POST request logged in OpenAM access logs / reverse proxy logs containing the className=javax.naming.InitialContext string.
Expected Detection
KQL, SPL, and Elastic EQL rules fire on the className parameter matching a suspicious/non-OpenAM namespace class.
Verifies that the vulnerable endpoint is reachable and processes the crafted callback without any prior authentication, confirming pre-auth exposure in a lab environment.
Command
curl -s -i -X POST 'http://LAB_OPENAM_HOST:8080/openam/json/authenticate' -H 'Content-Type: application/json' --data '{"callbacks":[{"type":"CustomCallback","className":"com.sun.org.apache.xalan.internal.xsltc.trax.TrustedTransformerFactoryImpl"}]}' | head -n 20Cleanup
No persistent state changes; rotate/clear lab access logs if needed.Expected Telemetry
200/500-level HTTP response captured in access logs alongside the crafted className payload, with no Authorization or session cookie header present.
Expected Detection
SIEM rule confirms alert fires even absent authentication headers, validating unauthenticated exposure detection logic.
Replays a captured (sanitized) malicious authentication payload against a Windows-hosted reverse proxy/log collector to validate that Windows-based log forwarding pipelines correctly surface the className field for detection.
Command
Invoke-WebRequest -Uri 'http://LAB_OPENAM_HOST:8080/openam/json/authenticate' -Method POST -ContentType 'application/json' -Body '{"callbacks":[{"type":"CustomCallback","className":"org.apache.commons.collections.functors.InvokerTransformer"}]}'Cleanup
No system changes persist on the Windows test host; clear PowerShell history entry for this command if required by lab policy.Expected Telemetry
IIS/reverse proxy log entry on the Windows collector showing the POST body with the className parameter forwarded to the SIEM.
Expected Detection
QRadar AQL and Sumo Logic queries match the forwarded log entry, confirming cross-platform log pipeline coverage for the detection.