[GHSA-wg5r-wc3x-39vc] OpenAM: Unauthenticated Remote Code Execution via Class.forName in AuthXMLUtils.createCustomCallback

[BarakSrour]

Updates

• Description

Comments

This corrects one factual error in the Interim mitigation section. It does not change the affected
range, severity, or any other field, and it is not a report of a new vulnerability —
CVE-2026-62379 is genuinely fixed in 16.1.2.

The problem. The advisory's first interim mitigation recommends enabling
sunRemoteAuthSecurityEnabled, described as rejecting unauthenticated /authservice calls. That
flag is only consulted after the unsafe class load has already occurred, so it does not protect
against this vector. Anyone still on ≤ 16.1.1 who enabled the flag and deferred upgrading may
believe they are protected when they are not — which is the specific harm the section exists to
prevent.

Evidence. All line numbers from the published org.openidentityplatform.openam:openam-core
16.1.2 sources jar on Maven Central; the same ordering holds in 16.1.1.

The class load happens inside AuthXMLHandler.processRequest line 194:

AuthXMLRequest.parseXML                                     AuthXMLRequest.java:139
  → new AuthXMLRequestParser(xml, req)                                        :145
  → authParser.parseXML()                                                     :148
    → parseSubmitReqElements(submitReqNode, …)         AuthXMLRequestParser.java:258
      → AuthXMLUtils.getCallbacks(callbacksNode, true, recdCallbacks)         :412
        → AuthXMLUtils.createCustomCallback(childNode, …)   AuthXMLUtils.java:299/304
          → Class.forName(className)                                         :1612

The flag is not read until processAuthXMLRequest, which processRequest does not call until line
246:

• AuthXMLHandler:246 — processAuthXMLRequest(...) invoked
• AuthXMLHandler:306 — securityEnabled = AuthUtils.getRemoteSecurityEnabled();
• AuthXMLHandler:316-317 — if (requestType != 0) { if (securityEnabled != null && securityEnabled.equals("true")) { … } }, the app-SSO-token requirement

There is also an earlier return at AuthXMLHandler:299-303 on
authXMLRequest.getValidSessionNoUpgrade(), before the flag is read at all.

There is no earlier enforcement point. sunRemoteAuthSecurityEnabled appears in exactly five
places in the repository: the constant at ISAuthConstants:642, the getter
AuthUtils.getRemoteSecurityEnabled:1456, the single consumer at AuthXMLHandler:306, the service
schema in openam-server-only/src/main/resources/services/amAuth.xml, and the reference
documentation. Nothing gates the request before parseXML.

The suggested WAF rule matches the literal element the parser looks for:
AuthXMLTags.CUSTOM_CALLBACK is "CustomCallback" and AuthXMLTags.ATTRIBUTE_CLASS_NAME is
"className". In the tree that element is produced only by AuthXMLUtils.getCustomCallbackXML for
DSAMECallbackInterface callbacks, which suggests it is rare in normal traffic — the OpenAM
maintainers will know the deployed reality better than I do, and I would defer to them on whether to
keep that bullet.

Scope of what I am claiming. I am not adding to the reachability analysis — the advisory already
establishes pre-authentication reachability on a default configuration and credits the original
reporter, and I take that as given. What I verified is only the ordering: the flag is consulted
after parseXML returns, and the class load happens inside parseXML. This is static analysis
against the published 16.1.1 and 16.1.2 artifacts. I did not stand up an OpenAM instance and did not
attempt to exploit anything.

[github]

Hi there @vharseko! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory