Michael Stepankin

**Name of the Vulnerable Software and Affected Versions** pac4j versions prior to 4.0.0 **Description** The vulnerability is a Java deserialization issue that affects systems storing externally controlled values in attributes of the `UserProfile` class from pac4j-core. It can be exploited by providing an attribute containing a serialized Java object with a special prefix `{#sb64}` and Base64 encoding, potentially leading to Remote Code Execution (RCE). Although a `RestrictedObjectInputStream` is in place, it still allows a broad range of Java packages and is potentially exploitable with different gadget chains. **Recommendations** To resolve the issue, upgrade to pac4j version 4.0.0 or later. As a temporary workaround, consider restricting the use of the `UserProfile` class from pac4j-core to minimize the risk of exploitation. Avoid using the `pac4j-core` version prior to 4.0.0 until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Kafka UI versions prior to 0.7.2 **Description** The issue is related to the deserialization mechanism in the Kafka UI web interface for Apache Kafka management. It allows a remote attacker to execute arbitrary code by exploiting the vulnerability in the JMX protocol, which is based on the RMI protocol and is susceptible to deserialization attacks. This can be done by connecting the Kafka UI backend to a malicious broker or by having access to the Kafka cluster connected to Kafka UI. The vulnerability can lead to post-authentication remote code execution, which is particularly dangerous since Kafka UI does not have authentication enabled by default. **Recommendations** For versions prior to 0.7.2, upgrade to version 0.7.2 or later to address the issue. As a temporary workaround, consider disabling the dynamic.config.enabled property in settings to minimize the risk of exploitation. Restrict access to the Kafka cluster connected to Kafka UI to prevent attackers from expanding their access and executing code on Kafka UI. Avoid using the JMX ports feature until the issue is resolved. At the moment, there are no known workarounds for this vulnerability other than upgrading to a fixed version.

**Name of the Vulnerable Software and Affected Versions** Apereo CAS versions prior to 6.6.6 **Description** The issue concerns Apereo CAS, an open source single sign-on solution. It can be configured to use authentication based on client X509 certificates, which 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, the system fetches URLs from the "CRL Distribution Points" extension of the certificate. If the CAS server is configured to use an LDAP server for x509 authentication with a password, it can lead to a password leak when making requests to LDAP URLs from the certificate, as it uses the same password as for the initially configured LDAP server. This allows an unauthenticated user to leak the password used for the LDAP connection configured on the server. **Recommendations** For versions prior to 6.6.6, upgrade to version 6.6.6 to address the issue. As a temporary workaround, consider restricting access to the LDAP server or changing the password used for the LDAP connection to minimize the risk of exploitation. Avoid using the same password for multiple LDAP connections until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Apache Solr versions prior to 8.2.0 **Description** The DataImportHandler module in Apache Solr has a feature that allows the whole DIH configuration to come from a request's `dataConfig` parameter. This parameter is a security risk since a DIH config can contain scripts. The debug mode of the DIH admin screen uses this feature, allowing convenient debugging and development of a DIH config. Exploitation of this issue may allow a remote attacker to impact the confidentiality, integrity, and availability of protected information. **Recommendations** For versions prior to 8.2.0, consider disabling the use of the `dataConfig` parameter until a patch is available. As a temporary workaround, restrict access to the DataImportHandler module to minimize the risk of exploitation. Starting with version 8.2.0, use of the `dataConfig` parameter requires setting the Java System property `enable.dih.dataConfigParam` to true, which should be done with caution and only when necessary.

**Name of the Vulnerable Software and Affected Versions** Apache Solr versions prior to 5.5.5 Apache Solr versions prior to 6.6.2 Apache Solr versions prior to 7.1.0 Apache Lucene versions prior to 7.1.0 **Description** The issue is related to the incorrect restriction of XML external entity references in the implementation of the RunExecutableListener class in Apache Solr and the Apache Lucene library for full-text search. This can be exploited by a remote attacker to execute arbitrary code. The XML external entity expansion vulnerability occurs in the XML Query Parser, which is available by default for any query request with parameters `deftype=xmlparser`. This can be exploited to upload malicious data to the `/upload` request handler or as Blind XXE using an ftp wrapper to read arbitrary local files from the Solr server. The vulnerability can also be exploited using the RunExecutableListener class, available on all affected versions of Solr. **Recommendations** For Apache Solr versions prior to 5.5.5, update to version 5.5.5 or later. For Apache Solr versions prior to 6.6.2, update to version 6.6.2 or later. For Apache Solr versions prior to 7.1.0, update to version 7.1.0 or later. As a temporary workaround, consider disabling the `RunExecutableListener` class until a patch is available. Restrict access to the XML Query Parser to minimize the risk of exploitation. Avoid using the `deftype=xmlparser` parameter in query requests until the issue is resolved.