ghsa

### Impact When a user with programming right edits a document in XWiki that was last edited by a user without programming right and contains an `XWiki.ComponentClass`, there is no warning that this will grant programming right to this object. An attacker who created such a malicious object could use this to gain programming right on the wiki. For this, the attacker needs to have edit right on at least one page to place this object and then get an admin user to edit that document. To reproduce the problem, as a user without programming right, add an object of type `XWiki.ComponentClass` to any page and then edit the page as a user with programming right. There should be warning displayed, if not, the XWiki installation is vulnerable. While such a warning didn't exist in any version of XWiki, only in XWiki 15.9 RC1 these kinds of warnings have been introduced which is why this is considered the first version that has this vulnerability. Before that, the advice was to be careful when ...

### 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 The Solr script service that is accessible in XWiki's scripting API normally requires programming right to be called. Due to using the wrong API for checking rights, it doesn't take the fact into account that programming rights might have been dropped by calling `$xcontext.dropPermissions()`. If some code relies on this for the safety of executing Velocity code with the wrong author context, this could allow a user with script right to either cause a high load by indexing documents or to temporarily remove documents from the search index. We're not aware that this is exploitable in XWiki itself. To reproduce, a user with programming right can add the following XWiki syntax to a page: ``` {{velocity}} $xcontext.dropPermissions() $services.solr.index('document:xwiki:Main.WebHome') {{/velocity}} ``` This should trigger an error in XWiki's log, otherwise the installation is vulnerable. ### Patches This has been patched in XWiki 15.10.13, 16.8.0RC1, and 16.4.4. ### Workaroun...

### 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.

A Regular Expression Denial of Service (ReDoS) vulnerability was identified in the huggingface/transformers library, specifically in the file `tokenization_gpt_neox_japanese.py` of the GPT-NeoX-Japanese model. The vulnerability occurs in the SubWordJapaneseTokenizer class, where regular expressions process specially crafted inputs. The issue stems from a regex exhibiting exponential complexity under certain conditions, leading to excessive backtracking. This can result in high CPU usage and potential application downtime, effectively creating a Denial of Service (DoS) scenario. The affected version is v4.48.1 (latest).

Improper Input Validation vulnerability in Apache Tomcat. Incorrect error handling for some invalid HTTP priority headers resulted in incomplete clean-up of the failed request which created a memory leak. A large number of such requests could trigger an OutOfMemoryException resulting in a denial of service. This issue affects Apache Tomcat: from 9.0.76 through 9.0.102, from 10.1.10 through 10.1.39, from 11.0.0-M2 through 11.0.5. Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6 which fix the issue.

A vulnerability was found in inclusionAI AWorld up to 8c257626e648d98d793dd9a1a950c2af4dd84c4e. It has been rated as critical. This issue affects the function subprocess.run/subprocess.Popen of the file AWorld/aworld/virtual_environments/terminals/shell_tool.py. The manipulation leads to os command injection. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable.

Improper Neutralization of Escape, Meta, or Control Sequences vulnerability in Apache Tomcat. For a subset of unlikely rewrite rule configurations, it was possible for a specially crafted request to bypass some rewrite rules. If those rewrite rules effectively enforced security constraints, those constraints could be bypassed. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.5, from 10.1.0-M1 through 10.1.39, from 9.0.0.M1 through 9.0.102. Users are recommended to upgrade to version 9.0.104, 10.1.40 or 11.0.6, which fix the issue.

### Impact n8n workflows can store and serve binary files, which are accessible to authenticated users. However, there was no restriction on the MIME type of uploaded files, and the MIME type could be controlled via a GET parameter. This allowed the server to respond with any MIME type, potentially enabling malicious content to be interpreted and executed by the browser. An authenticated attacker with member-level permissions could exploit this by uploading a crafted HTML file containing malicious JavaScript. When another user visits the binary data endpoint with the MIME type set to text/html, the script executes in the context of the user’s session. This script could, for example, send a request to change the user’s email address in their account settings, effectively enabling account takeover. ### Patches - [[email protected]](https://github.com/n8n-io/n8n/releases/tag/n8n%401.90.0) ### Credit We would like to thank @Mahmoud0x00 for reporting this issue.

# Issue Snowflake discovered and remediated a vulnerability in the NodeJS Driver for Snowflake (“Driver”). When using the Easy Logging feature on Linux and macOS the Driver didn’t correctly verify the permissions of the logging configuration file, potentially allowing an attacker with local access to overwrite the configuration and gain control over logging level and output location. This vulnerability affects Driver versions 1.10.0 through 2.0.3. Snowflake fixed the issue in version 2.0.4. # Vulnerability Details When using the Easy Logging feature on Linux and macOS the Driver reads logging configuration from a user-provided file. On Linux and macOS the Driver verifies that the configuration file can be written to only by its owner. That check was vulnerable to a Time-of-Check to Time-of-Use (TOCTOU) race condition and failed to verify that the file owner matches the user running the Driver. This could allow a local attacker with write access to the configuration file or the direct...