#maven

XXE injection in `/rtc/post/ endpoint` in OpenMNS Horizon 31.0.8 and versions earlier than 32.0.2 on multiple platforms is vulnerable to XML external entity (XXE) injection, which can be used for instance to force Horizon to make arbitrary HTTP requests to internal and external services. The solution is to upgrade to Meridian 2023.1.6, 2022.1.19, 2021.1.30, 2020.1.38 or Horizon 32.0.2 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet.

Cross Site Request Forgery (CSRF) vulnerability in `xxl-job-admin/user/add` in xuxueli xxl-job version 2.2.0 allows remote attackers to execute arbitrary code and esclate privileges via crafted .html file.

Apache NiFi 0.0.2 through 1.22.0 include Processors and Controller Services that support HTTP URL references for retrieving drivers, which allows an authenticated and authorized user to configure a location that enables custom code execution. The resolution introduces a new Required Permission for referencing remote resources, restricting configuration of these components to privileged users. The permission prevents unprivileged users from configuring Processors and Controller Services annotated with the new Reference Remote Resources restriction. Upgrading to Apache NiFi 1.23.0 is the recommended mitigation.

## Impact The mail obfuscation configuration was not fully taken into account and is was still possible by obfuscated emails. See https://jira.xwiki.org/browse/XWIKI-20601 for the reproduction steps. ## Patches This has been patched in XWiki 14.10.9, and XWiki 15.3-rc-1. ## Workarounds The workaround is to modify the page XWiki.LiveTableResultsMacros following this [patch](https://github.com/xwiki/xwiki-platform/commit/1dfb6804d4d412794cbe0098d4972b8ac263df0c). ## References - https://jira.xwiki.org/browse/XWIKI-20601 - https://github.com/xwiki/xwiki-platform/commit/1dfb6804d4d412794cbe0098d4972b8ac263df0c ## For more information If you have any questions or comments about this advisory: - Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) - Email us at [Security Mailing List](mailto:[email protected])

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