Summary
A pre-authentication remote code execution vulnerability affects OpenAM. The
remote authentication endpoint (/authservice, PLL) accepts an XML element
that names an arbitrary Java class, which the server then loads and
instantiates without validation. On a default configuration this is reachable
without authentication and allows an attacker to run code on the server.
Impact
Unauthenticated remote code execution / full server compromise on any OpenAM
instance with default settings.
Affected
All releases up to and including 16.1.1 (the defect predates the Open Identity
Platform fork).
Remediation
Upgrade to 16.1.2. The fix resolves the class named in a <CustomCallback>
element without running its static initialisers and rejects it unless it
implements DSAMECallbackInterface, and it constrains deserialisation of the
serialised Subject value to a class allowlist.
Interim mitigation
If you cannot upgrade immediately:
- Restrict or block external network access to
/authservice. This is the
only reliable mitigation.
- Optionally, block PLL requests carrying a
<CustomCallback className="...">
element at the reverse proxy or WAF. That element is only produced for custom
DSAMECallbackInterface callbacks, so most deployments never send it — confirm
against your own traffic before enforcing.
- Enabling
sunRemoteAuthSecurityEnabled does not mitigate this issue. The
remote-auth security token is checked in AuthXMLHandler.processAuthXMLRequest,
which runs only after AuthXMLRequest.parseXML has already parsed the request
and instantiated the class named in the <CustomCallback className="...">
element. Do not rely on it as a substitute for upgrading or for network
restriction.
Credit
Vulnerability discovered by Zhixi "Jace" Sun of ASM/VI at TikTok.
Correction of the interim mitigation guidance contributed by @BarakSrour.
References
manus-use Reporter
BarakSrour Analyst
Summary
A pre-authentication remote code execution vulnerability affects OpenAM. The
remote authentication endpoint (
/authservice, PLL) accepts an XML elementthat names an arbitrary Java class, which the server then loads and
instantiates without validation. On a default configuration this is reachable
without authentication and allows an attacker to run code on the server.
Impact
Unauthenticated remote code execution / full server compromise on any OpenAM
instance with default settings.
Affected
All releases up to and including 16.1.1 (the defect predates the Open Identity
Platform fork).
Remediation
Upgrade to
16.1.2. The fix resolves the class named in a<CustomCallback>element without running its static initialisers and rejects it unless it
implements
DSAMECallbackInterface, and it constrains deserialisation of theserialised
Subjectvalue to a class allowlist.Interim mitigation
If you cannot upgrade immediately:
/authservice. This is theonly reliable mitigation.
<CustomCallback className="...">element at the reverse proxy or WAF. That element is only produced for custom
DSAMECallbackInterfacecallbacks, so most deployments never send it — confirmagainst your own traffic before enforcing.
sunRemoteAuthSecurityEnableddoes not mitigate this issue. Theremote-auth security token is checked in
AuthXMLHandler.processAuthXMLRequest,which runs only after
AuthXMLRequest.parseXMLhas already parsed the requestand instantiated the class named in the
<CustomCallback className="...">element. Do not rely on it as a substitute for upgrading or for network
restriction.
Credit
Vulnerability discovered by Zhixi "Jace" Sun of ASM/VI at TikTok.
Correction of the interim mitigation guidance contributed by @BarakSrour.
References