#maven

An attacker can use SnakeYAML to deserialize java.net.URLClassLoader and make it load a JAR from a specified URL, and then deserialize javax.script.ScriptEngineManager to load code using that ClassLoader. This unbounded deserialization can likely lead to remote code execution. The code can be run in Helix REST start and Workflow creation. Affect all the versions lower and include 1.2.0. Affected products: helix-core, helix-rest Mitigation: Short term, stop using any YAML based configuration and workflow creation.                   Long term, all Helix version bumping up to 1.3.0 

Armeria is a microservice framework Spring supports Matrix variables. When Spring integration is used, Armeria calls Spring controllers via `TomcatService` or `JettyService` with the path that may contain matrix variables. Prior to version 1.24.3, the Armeria decorators might not invoked because of the matrix variables. If an attacker sends a specially crafted request, the request may bypass the authorizer. Version 1.24.3 contains a patch for this issue.

### Impact Spring supports [Matrix variables](https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller/ann-methods/matrix-variables.html). When Spring integration is used, Armeria calls Spring controllers via `TomcatService` or `JettyService` with the path that may contain matrix variables. In this situation, the Armeria decorators might not invoked because of the matrix variables. Let's see the following example: ``` // Spring controller @GetMapping("/important/resources") public String important() {...} // Armeria decorator ServerBuilder sb = ... sb.decoratorUnder("/important/", authService); ``` If an attacker sends a request with `/important;a=b/resources`, the request would bypass the authrorizer ### Patches - https://github.com/line/armeria-ghsa-wvp2-9ppw-337j/commit/9b0ec3e099cc05fbff11d7f1012a1dddb0000d0c ### Workarounds Users can add decorators using regex. `e.g. "regex:^/important.*"`

### Impact The module creates a system user that is used to perform internal module-to-module operations. Credentials for this user are hard-coded in the source code. This makes it trivial to authenticate as this user, allowing unauthorized read access to these mod-inventory-storage records: instances, holdings, items, contributor-types, identifier-types. This includes records marked as suppressed from discovery. ### Patches Upgrade mod-remote-storage to >=2.0.3, or a 1.7.x version >=1.7.1. ### Workarounds No known workarounds. ### References https://wiki.folio.org/x/hbMMBw - FOLIO Security Advisory with Upgrade Instructions https://github.com/folio-org/mod-remote-storage/commit/57df495f76e9aa5be9ce7ce3a65f89b6dbcbc13b - Fix

### Impact The module creates a system user that is used to perform internal module-to-module operations. Credentials for this user are hard-coded in the source code. This makes it trivial to authenticate as this user, resulting in unauthorized access to potentially dangerous APIs, allowing to view and modify configuration including single-sign-on configuration, to read, add and modify user data, and to read and transfer fees/fines in a patron's account. ### Patches Upgrade mod-data-export-spring to >=2.0.2, or a 1.5.x version >=1.5.4. ### Workarounds No known workarounds. ### References https://wiki.folio.org/x/hbMMBw - FOLIO Security Advisory with Upgrade Instructions https://github.com/folio-org/mod-data-export-spring/commit/93aff4566bff59e30f4121b5a2bda5b0b508a446 - Fix

### Impact OpenAM up to version 14.7.2 does not properly validate the signature of SAML responses received as part of the SAMLv1.x Single Sign-On process. Attackers can use this fact to impersonate any OpenAM user, including the administrator, by sending a specially crafted SAML response to the SAMLPOSTProfileServlet servlet. ### Patches This problem has been patched in OpenAM 14.7.3-SNAPSHOT and later ### Workarounds One should comment servlet `SAMLPOSTProfileServlet` in web.xml or disable SAML in OpenAM ```xml <servlet> <description>SAMLPOSTProfileServlet</description> <servlet-name>SAMLPOSTProfileServlet</servlet-name> <servlet-class>com.sun.identity.saml.servlet.SAMLPOSTProfileServlet</servlet-class> </servlet> ... <servlet-mapping> <servlet-name>SAMLSOAPReceiver</servlet-name> <url-pattern>/SAMLSOAPReceiver</url-pattern> </servlet-mapping> ``` ### References #624

### Impact In Hazelcast Platform, 5.0 through 5.0.4, 5.1 through 5.1.6, and 5.2 through 5.2.3, and Hazelcast IMDG (all versions up to 4.2.z), Executor Services don't check client permissions properly, allowing authenticated users to execute tasks on members without the required permissions granted. ### Patches Fix versions: 5.3.0, 5.2.4, 5.1.7, 5.0.5 ### Workarounds Users are only affected when they already use executor services (i.e., an instance exists as a distributed data structure).

A potential vulnerability has been identified in the Micro Focus Dimensions CM Plugin for Jenkins. The vulnerability allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. See the following Jenkins security advisory for details: * https://www.jenkins.io/security/advisory/2023-06-14/ https://www.jenkins.io/security/advisory/2023-06-14/

Red Hat Security Advisory 2023-4200-01 - A new release for Red Hat Build of OptaPlanner 8.38.0 for Quarkus 2.13.8 including security updates is now available. The purpose of this text-only errata is to inform you about the security issues fixed. Red Hat Product Security has rated this update as having an impact of Important. A Common Vulnerability Scoring System base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link in the References section. Issues addressed include a denial of service vulnerability.

Deserialization of Untrusted Data vulnerability in Apache ShardingSphere-Agent, which allows attackers to execute arbitrary code by constructing a special YAML configuration file. The attacker needs to have permission to modify the ShardingSphere Agent YAML configuration file on the target machine, and the target machine can access the URL with the arbitrary code JAR. An attacker can use SnakeYAML to deserialize java.net.URLClassLoader and make it load a JAR from a specified URL, and then deserialize javax.script.ScriptEngineManager to load code using that ClassLoader. When the ShardingSphere JVM process starts and uses the ShardingSphere-Agent, the arbitrary code specified by the attacker will be executed during the deserialization of the YAML configuration file by the Agent. This issue affects ShardingSphere-Agent: through 5.3.2. This vulnerability is fixed in Apache ShardingSphere 5.4.0.