#maven

### Impact A vulnerability exists in the synchronization configuration feature that allows users to craft specific requests to bypass permission checks. This exploit enables them to modify a namespace without the necessary permissions. ### Patches The issue was addressed with an input parameter check in #5192, which was released in version [2.3.0](https://github.com/apolloconfig/apollo/releases/tag/v2.3.0). ### Workarounds To mitigate the issue without upgrading, follow the recommended practices to prevent Apollo from being exposed to the internet. ### Credits The vulnerability was reported and reproduced by [Lakeswang](https://github.com/Lakes-bitgetsec). ### References For any questions or comments regarding this advisory: * Open an issue in [issue](https://github.com/apolloconfig/apollo/issues) * Email us at [[email protected]](mailto:[email protected])

### Impact Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL. #### Reproduction steps 1. As a user without script or programming right, create a (non-terminal) document named `" + alert(1) + "` (the quotes need to be part of the name). 1. Edit the class. 1. Add a string property named `"test"`. 1. Edit using the object editor and add an object of the created class 1. Get an admin to open `<xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit` where `<xwiki-server>` is the URL of your XWiki installation. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References - https://jira.xwiki.org/browse/XWIKI-21810 - https://github.com/xwiki/xwiki-plat...

Like many other SSH implementations, Apache MINA SSHD suffered from the issue that is more widely known as CVE-2023-48795. An attacker that can intercept traffic between client and server could drop certain packets from the stream, potentially causing client and server to consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack The mitigations to prevent this type of attack were implemented in Apache MINA SSHD 2.12.0, both client and server side. Users are recommended to upgrade to at least this version. Note that both the client and the server implementation must have mitigations applied against this issue, otherwise the connection may still be affected.

CometVisu's file system endpoints don't require authentication and additionally the endpoint to update an existing file is susceptible to path traversal. This makes it possible for an attacker to overwrite existing files on the openHAB instance. If the overwritten file is a shell script that is executed at a later time this vulnerability can allow remote code execution by an attacker. This vulnerability was discovered with the help of CodeQL's [Uncontrolled data used in path expression](https://codeql.github.com/codeql-query-help/java/java-path-injection/) query. ## Impact This issue may lead up to Remote Code Execution (RCE).

Several endpoints in the CometVisu add-on of openHAB don't require authentication. This makes it possible for unauthenticated attackers to modify or to steal sensitive data. ## Impact This issue may lead to sensitive Information Disclosure.

Reposilite is an open source, lightweight and easy-to-use repository manager for Maven based artifacts in JVM ecosystem. Reposilite v3.5.10 is affected by an Arbitrary File Read vulnerability via path traversal while serving expanded javadoc files. Reposilite has addressed this issue in version 3.5.12. There are no known workarounds for this vulnerability. This issue was discovered and reported by the GitHub Security lab and is also tracked as GHSL-2024-074.

Redisson is a Java Redis client that uses the Netty framework. Prior to version 3.22.0, some of the messages received from the Redis server contain Java objects that the client deserializes without further validation. Attackers that manage to trick clients into communicating with a malicious server can include especially crafted objects in its responses that, once deserialized by the client, force it to execute arbitrary code. This can be abused to take control of the machine the client is running in. Version 3.22.0 contains a patch for this issue. Some post-fix advice is available. Do NOT use `Kryo5Codec` as deserialization codec, as it is still vulnerable to arbitrary object deserialization due to the `setRegistrationRequired(false)` call. On the contrary, `KryoCodec` is safe to use. The fix applied to `SerializationCodec` only consists of adding an optional allowlist of class names, even though making this behavior the default is recommended. When instantiating `SerializationCodec`...

Apereo CAS is an open source multilingual single sign-on solution for the web. 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 pass...

### Summary Reposilite v3.5.10 is affected by an Arbitrary File Upload vulnerability via path traversal in expanding of Javadoc archives. ### Details Reposilite provides support for JavaDocs files, which are archives that contain documentation for artifacts. Specifically, [JavadocEndpoints.kt](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/infrastructure/JavadocEndpoints.kt#L28) controller allows to expand the javadoc archive into the server's file system and return its content. The problem is in the way how the archives are expanded, specifically how the new filename is created: [JavadocContainerService.kt#L127-L136](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocContainerService.kt#L127-L136) ```kotlin jarFile.entries().asSequence().forEach { file -> if (file.isDirectory) { ...

### Summary Reposilite v3.5.10 is affected by Stored Cross-Site Scripting (XSS) when displaying artifact's content in the browser. ### Details As a Maven repository manager, Reposilite provides the ability to view the artifacts content in the browser, as well as perform administrative tasks via API. The problem lies in the fact that the artifact's content is served via the same origin (protocol/host/port) as the Admin UI. If the artifact contains HTML content with javascript inside, the javascript is executed within the same origin. Therefore, if an authenticated user is viewing the artifacts content, the javascript inside can access the browser's local storage where the user's password (aka 'token-secret') is stored. It is especially dangerous in scenarios where Reposilite is configured to mirror third party repositories, like the Maven Central Repository. Since anyone can publish an artifact to Maven Central under its own name, such malicious packages can be used to attack the Repos...