#maven

EndpointRequest.to() creates a matcher for null/** if the actuator endpoint, for which the EndpointRequest has been created, is disabled or not exposed. Your application may be affected by this if all the following conditions are met: * You use Spring Security * EndpointRequest.to() has been used in a Spring Security chain configuration * The endpoint which EndpointRequest references is disabled or not exposed via web * Your application handles requests to /null and this path needs protection You are not affected if any of the following is true: * You don't use Spring Security * You don't use EndpointRequest.to() * The endpoint which EndpointRequest.to() refers to is enabled and is exposed * Your application does not handle requests to /null or this path does not need protection

### Impact Attackers could manipulate the `FileRef` parameter to access files on the system where the Jmix application is deployed, provided the application server has the necessary permissions. This can be accomplished either by modifying the `FileRef` directly in the database or by supplying a harmful value in the `fileRef` parameter of the `/files` endpoint of the generic REST API. Arbitrary file reading on the operating system where the Jmix process is running. The severity of the vulnerability is mitigated by the fact that the application UI and the generic REST API are typically accessible only to authenticated users. Additionally, the `/files` endpoint in Jmix requires specific permissions and is disabled by default. ### Workarounds A workaround for those who are unable to upgrade: [Fix Path Traversal in Jmix Application](https://docs.jmix.io/jmix/files-vulnerabilities.html#fix-path-traversal-in-jmix-application). ### Credit Cai, Qi Qi of Siemens China Cybersecurity Testing...

A stored cross-site scripting (XSS) vulnerability exists with radio button type custom fields in Liferay Portal 7.2.0 through 7.4.3.129, and Liferay DXP 2024.Q4.1 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.9, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.12, 2023.Q4.0 through 2023.Q4.10, 2023.Q3.1 through 2023.Q3.10, 7.4 GA through update 92, 7.3 GA through update 36, and 7.2 GA through fix pack 20 allows remote authenticated attackers to inject malicious JavaScript into a page.

### Impact This vulnerability impacts users of a subwiki of XWiki where Message Stream is enabled and use, if they configured their wiki to be closed by selecting "Prevent unregistered users to view pages" in the Administrations Rights. The vulnerability is that any message sent in a subwiki to "everyone" is actually sent to the farm: any visitor of the main wiki will be able to see that message through the Dashboard, even if the subwiki is configured to be private. ### Patches This problem has not been patched and is not going to be patched in the future: Message Stream has been deprecated in XWiki 16.8.0RC1 and is not maintained anymore. ### Workarounds Message Stream is disabled by default, it's advised to keep it disabled from Administration > Social > Message Stream. ### References * https://jira.xwiki.org/browse/XWIKI-17154

### Impact Starting with 6.1, HTTP Inputs can be configured to check if a specified header is present and has a specified value to authenticate HTTP-based ingestion. Unfortunately, even though in cases of a missing header or a wrong value the correct HTTP response (401) is returned, the message will be ingested nonetheless. ### Patches ### Workarounds Disabling http-based inputs and allow only authenticated pull-based inputs. ### References

Jenkins AsakusaSatellite Plugin 0.1.1 and earlier stores AsakusaSatellite API keys unencrypted in job config.xml files on the Jenkins controller as part of its configuration. These API keys can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. Additionally, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them. As of publication of this advisory, there is no fix.

Jenkins Templating Engine Plugin allows defining libraries both in the global configuration, as well as scoped to folders containing the pipelines using them. While libraries in the global configuration can only be set up by administrators and can therefore be trusted, libraries defined in folders can be configured by users with Item/Configure permission. In Templating Engine Plugin 2.5.3 and earlier, libraries defined in folders are not subject to sandbox protection. This vulnerability allows attackers with Item/Configure permission to execute arbitrary code in the context of the Jenkins controller JVM. In Templating Engine Plugin 2.5.4, libraries defined in folders are subject to sandbox protection.

Jenkins AsakusaSatellite Plugin 0.1.1 and earlier stores AsakusaSatellite API keys unencrypted in job config.xml files on the Jenkins controller as part of its configuration. These API keys can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. Additionally, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them. As of publication of this advisory, there is no fix.

### Impact A vulnerability was found in OIDC-Client. When using the elytron-oidc-client subsystem with WildFly, authorization code injection attacks can occur, allowing an attacker to inject a stolen authorization code into the attacker's own session with the client with a victim's identity. This is usually done with a Man-in-the-Middle (MitM) or phishing attack. ### Patches [2.2.9.Final](https://github.com/wildfly-security/wildfly-elytron/releases/tag/2.2.9.Final) [2.6.2.Final](https://github.com/wildfly-security/wildfly-elytron/releases/tag/2.6.2.Final) ### Workarounds Currently, no mitigation is currently available for this vulnerability. ### References https://nvd.nist.gov/vuln/detail/CVE-2024-12369 https://access.redhat.com/security/cve/CVE-2024-12369 https://bugzilla.redhat.com/show_bug.cgi?id=2331178 https://issues.redhat.com/browse/ELY-2887

BCryptPasswordEncoder.matches(CharSequence,String) will incorrectly return true for passwords larger than 72 characters as long as the first 72 characters are the same.