Artsploit

**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** Reposilite versions 3.5.10 through 3.5.11 **Description** The issue is related to an Arbitrary File Read vulnerability via path traversal while serving expanded javadoc files. This occurs because the `GET /javadoc/{repository}/<gav>/raw/<resource>` route uses the `<resource>` path parameter to find the file in the `javadocUnpackPath` directory and returns its content to the user. The `<resource>` path parameter can contain path traversal characters, allowing an attacker to read files outside the `javadocUnpackPath` directory. This may lead to the exposure of sensitive information, including passwords and hashes of issued tokens stored in the `reposilite.db` file or other sensitive properties in the `configuration.cdn` file. **Recommendations** For versions 3.5.10 through 3.5.11, update to version 3.5.12 to resolve the issue. As a temporary workaround, consider normalizing the `<resource>` path parameter by removing all occurrences of `/../` before using it to read the file. This can be achieved by changing `resource.toString()` to `resource.toPath()` in the `JavadocFacade.kt` file.

**Name of the Vulnerable Software and Affected Versions** Reposilite versions prior to 3.5.12 **Description** The issue lies in the fact that the artifact's content is served via the same origin as the Admin UI. If the artifact contains HTML content with javascript inside, the javascript is executed within the same origin. This allows access to the browser's local storage where the user's password is stored. The attack can be performed from the admin browser, even if the Reposilite instance is located in an isolated environment. This issue may lead to the full Reposilite instance compromise, and in the worst case scenario, an attacker would be able to obtain Remote code execution on all systems that use artifacts from Reposilite. **Recommendations** For versions prior to 3.5.12, consider the following options to remediate this vulnerability: * Use the "Content-Security-Policy: sandbox;" header when serving artifact's content to restrict javascript execution. * Use the "Content-Disposition: attachment" header to prevent the browser from displaying the content entirely. Additionally, reconsider how the website authentication works for Reposilite, and consider issuing a one-time session ID or a token to the browser after checking the login/password on the server. These session IDs or tokens should have limited validity time. Upgrade to version 3.5.12 to address this issue.

Name of the Vulnerable Software and Affected Versions: Reposilite versions prior to 3.5.12 Description: The issue is related to the expansion of Javadoc archives in Reposilite, where the `file.name` taken from the archive can contain path traversal characters, allowing an attacker to overwrite any local file on the Reposilite instance. This could lead to remote code execution, for example by placing a new plugin into the '$workspace$/plugins' directory. Alternatively, an attacker can overwrite the content of any other package. The attacker can use its own malicious package from Maven Central to overwrite any other package on Reposilite. Recommendations: For versions prior to 3.5.12, upgrade to version 3.5.12 or later to resolve the issue. As a temporary workaround, consider normalizing the `file.name` variable before concatenating it with `javadocUnpackPath` to prevent path traversal attacks. For example, use `val path = Paths.get(javadocUnpackPath.toString() + "/" + Paths.get(file.name).normalize().toString())` in the `JavadocContainerService.kt` file.

**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** DataHub versions prior to 0.8.45 **Description** The issue concerns authentication checks using the `AuthUtils.hasValidSessionCookie()` method, which could be bypassed by using a cookie from a logged out session. This is because session cookies are only cleared on new sign-in events and not on logout events. As a result, any logged out session cookie may be accepted as valid, leading to an authentication bypass to the system. **Recommendations** For versions prior to 0.8.45, upgrade to version 0.8.45 or later to resolve the issue. As a temporary workaround, consider disabling the use of session cookies or restricting access to sensitive areas of the system until the upgrade can be applied.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The DataHub frontend proxy does not properly construct URLs when forwarding data to the DataHub Metadata Store (GMS), allowing external users to reroute requests to arbitrary hosts. This enables attackers to redirect requests from the frontend proxy to other servers and return the results. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The DataHub frontend, when configured to authenticate via SSO, processes the `id token` in an unsafe manner. This issue arises because the pac4j library deserializes values starting with the `{#sb64}` prefix as serialized Java objects. Although a `RestrictedObjectInputStream` is in place, it still allows deserialization of a broad range of Java packages, potentially leading to Remote Code Execution (RCE) with different gadget chains. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The issue concerns the Metadata service (GMS) in DataHub, where the X-DataHub-Actor HTTP header is used to infer the user on whose behalf the frontend is sending a request. The header's name is retrieved in a case-insensitive manner, which can be exploited by an attacker to smuggle an X-DataHub-Actor header with different casing. This can lead to an authorization bypass, allowing any user to impersonate the system user account and perform actions on its behalf. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub (affected versions not specified) **Description** The issue concerns the AuthServiceClient in DataHub, which is responsible for managing accounts and authentication. It crafts JSON strings using format strings with user-controlled data, potentially allowing an attacker to manipulate these strings and send them to the backend. This could lead to an authentication bypass, creation of system accounts, and potentially full system compromise. **Recommendations** At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** DataHub versions prior to 0.8.45 **Description** The `StatelessTokenService` of the DataHub metadata service does not verify the signature of JWT tokens, allowing an attacker to connect to DataHub instances as any user if Metadata Service authentication is enabled. This occurs because the `StatelessTokenService` uses the `parse` method of `io.jsonwebtoken.JwtParser`, which does not perform a verification of the cryptographic token signature, accepting JWTs regardless of the used algorithm. This issue may lead to an authentication bypass. **Recommendations** For versions prior to 0.8.45, update to version 0.8.45 to resolve the issue. As a temporary workaround, consider disabling the `StatelessTokenService` function until a patch is available. Restrict access to the Metadata service to minimize the risk of exploitation. Avoid using JWT tokens in the affected DataHub instances until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** MITREid Connect versions 1.3.3 and earlier **Description** The OpenID Connect server implementation contains a Server Side Request Forgery (SSRF) vulnerability due to unsafe usage of the `logo uri` parameter in the Dynamic Client Registration request. An unauthenticated attacker can make an HTTP request from the vulnerable server to any address in the internal network and obtain its response, potentially leading to bypassing network boundaries, obtaining sensitive data, or attacking other hosts in the internal network. **Recommendations** For versions 1.3.3 and earlier, as a temporary workaround, consider restricting the usage of the `logo uri` parameter in the Dynamic Client Registration request to minimize the risk of exploitation. At the moment, there is no information about a newer version that contains a fix for this vulnerability.