#maven

Improper Restriction of XML External Entity Reference vulnerability in bonigarcia webdrivermanager on Windows, MacOS, Linux (XML parsing components modules) allows Data Serialization External Entities Blowup. This vulnerability is associated with program files src/main/java/io/github/bonigarcia/wdm/WebDriverManager.java. This issue affects webdrivermanager: from 1.0.0 before 6.1.0.

Uncontrolled Resource Consumption vulnerability in Apache Commons Configuration 1.x. There are a number of issues in Apache Commons Configuration 1.x that allow excessive resource consumption when loading untrusted configurations or using unexpected usage patterns. The Apache Commons Configuration team does not intend to fix these issues in 1.x. Apache Commons Configuration 1.x is still safe to use in scenarios where you only load trusted configurations. Users that load untrusted configurations or give attackers control over usage patterns are recommended to upgrade to the 2.x version line, which fixes these issues. Apache Commons Configuration 2.x is not a drop-in replacement, but as it uses a separate Maven groupId and Java package namespace they can be loaded side-by-side, making it possible to do a gradual migration.

### Impact Two minor vulnerabilities were identified in the Graylog2 enterprise server, which can be combined to carry out a stored cross-site scripting attack. An attacker with the permission `FILES_CREATE` can exploit these vulnerabilities to upload arbitrary Javascript code to the Graylog2 server, which - upon requesting of the file by a user of the API browser - results in the execution of this Javascript code in the context of the Graylog frontend application. This enables the attacker to carry out authenticated API requests with the permissions of the logged-in user, thereby taking over the user session. ### Patches The generic API has been removed in 6.2.0 rendering the attack vector unreachable and additional escaping has been added. Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd

Memory Allocation with Excessive Size Value vulnerability in Apache ActiveMQ. During unmarshalling of OpenWire commands the size value of buffers was not properly validated which could lead to excessive memory allocation and be exploited to cause a denial of service (DoS) by depleting process memory, thereby affecting applications and services that rely on the availability of the ActiveMQ broker when not using mutual TLS connections. This issue affects Apache ActiveMQ: from 6.0.0 before 6.1.6, from 5.18.0 before 5.18.7, from 5.17.0 before 5.17.7, before 5.16.8. ActiveMQ 5.19.0 is not affected. Users are recommended to upgrade to version 6.1.6+, 5.19.0+, 5.18.7+, 5.17.7, or 5.16.8 or which fixes the issue. Existing users may implement mutual TLS to mitigate the risk on affected brokers.

An XML External Entity (XXE) vulnerability exists in the gateway component of WSO2 API Manager due to insufficient validation of XML input in crafted URL paths. User-supplied XML is parsed without appropriate restrictions, enabling external entity resolution. This vulnerability can be exploited by an unauthenticated remote attacker to read files from the server’s filesystem or perform denial-of-service (DoS) attacks. * On systems running JDK 7 or early JDK 8, full file contents may be exposed. * On later versions of JDK 8 and newer, only the first line of a file may be read, due to improvements in XML parser behavior. * DoS attacks such as "Billion Laughs" payloads can cause service disruption.

### Impact A user who can access pages located in the XWiki space (by default, anyone) can access the page `XWiki.Authentication.Administration` and (unless an authenticator is set in `xwiki.cfg`) switch to another installed authenticator. Note that, by default, there is only one authenticator available (`Standard XWiki Authenticator`). So, if no authenticator extension was installed, it's not really possible to do anything for an attacker. Also, in most cases, if you have installed and are using an SSO authenticator (like OIDC or LDAP for example), the worst an attacker can do is break authentication by switching back to the standard authenticator (that's because it's impossible to login to a user which does not have a stored password, and that's usually what SSO authenticator produce). ### Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1. ### Workarounds You can very easily fix this vulnerability in your instance through right configuration: * access the page...

### Impact Anyone can access the metadata of any attachment in the wiki using the wiki attachment REST endpoint. It's not filtering the result depending on current user rights, a not authenticated user could exploit this even in a totally private wiki. To reproduce: * remove view from guest on the whole wiki * logout * access http://127.0.0.1:8080/xwiki/rest/wikis/xwiki/attachments You get a list of attachments, while the expected result should be an empty list. ### Patches This vulnerability has been fixed in XWiki 14.10.22, 15.10.12, 16.7.0-rc-1 and 16.4.3. ### Workarounds We're not aware of any workaround except upgrading. ### 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:security@xwiki.org) ### Attribution Issue reported by Lukas Monert.

# Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-5jfq-x6xp-7rw2. This link is maintained to preserve external references. # Original Description A flaw was found in Keycloak. The org.keycloak.authorization package may be vulnerable to circumventing required actions, allowing users to circumvent requirements such as setting up two-factor authentication.

### Impact The script API of the LESS compiler in XWiki is incorrectly checking for rights when calling the cache cleaning API, making it possible to clean the cache without having programming right. The only impact of this is a slowdown in XWiki execution as the caches are re-filled. As this vulnerability requires script right to exploit, and script right already allows unlimited execution of scripts, the additional impact due to this vulnerability is low. ### Patches This has been patched in XWiki 15.10.12, 16.4.3 and 16.8.0 RC1. ### Workarounds We're not aware of any workaround except for being careful whom to give script right, which is a general recommendation.

### Impact An open redirect vulnerability in the HTML conversion request filter allows attackers to construct URLs on an XWiki instance that redirect to any URL. To reproduce, open `<xwiki-host>/xwiki/bin/view/Main/?foo=bar&foo_syntax=invalid&RequiresHTMLConversion=foo&xerror=https://www.example.com/` where `<xwiki-host>` is the URL of your XWiki installation. ### Patches This bug has been fixed in XWiki 15.10.13, 16.4.4 and 16.8.0 by validating the domain of the redirect URL against the configured safe domains and the current request's domain. ### Workarounds A web application firewall could be configured to reject requests with the `xerror` parameter as from our analysis this parameter isn't used anymore. For requests with the `RequiresHTMLConversion` parameter set, the referrer URL should be checked if it points to the XWiki installation. Apart from that, we're not aware of any workarounds.