#jira

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

### Impact When editing a page, XWiki warns since version 15.9 when there is content on the page like a script macro that would gain more rights due to the editing. This analysis doesn't consider certain kinds of properties, allowing a user to put malicious scripts in there that will be executed after a user with script, admin, or programming rights edited the page. Such a malicious script could impact the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, as a user without script right, create a class with a `TextArea` property, create page with an object of that class and a Velocity macro in its content. Then, as an admin, try editing that page. Normally, there should be a warning but in vulnerable versions of XWiki, there is no warning. ### Patches This vulnerability has been patched in XWiki 15.10.8 and 16.2.0. ### Workarounds We're not aware of any workarounds apart from not editing pages that might have been edited by untrusted users as ...

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

### Impact It is possible for a remote unauthenticated user to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend, including when "Prevent unregistered users from viewing pages, regardless of the page rights" and "Prevent unregistered users from editing pages, regardless of the page rights" options are enabled. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers. An example query, which leads to SQL injection with MySQL/MariaDB backend is shown below: ``` time curl "http://127.0.0.1:8080/rest/wikis/xwiki/query?q=where%20doc.name=length('a')*org.apache.logging.log4j.util.Chars.SPACE%20or%201%3C%3E%271%5C%27%27%20union%20select%20...

### Impact It is possible for a user with SCRIPT right to escape from the HQL execution context and perform a blind SQL injection to execute arbitrary SQL statements on the database backend. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. The vulnerability may be tested in a default installation of XWIki Standard Flavor, including using the official Docker containers. For example, with a MySQL or MariaDB database, you can use the following script (which a user having SCRIPT right but not PROGRAMMING right) to get the content of the xwikistrings table (which contain all the short string fields stored in objects, including passwords): ``` {{velocity}} $services.query.hql("where 1<>'1\'' union select concat(XWS_NAME, XWS_VALUE) from xwikistrings #'").execute() {{/velocity}} ``` ### Patches This has been patched in 16.10.1, 16.4.6 and...

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

Mattermost versions 10.4.x <= 10.4.2, 10.5.x <= 10.5.0, 9.11.x <= 9.11.9 fail to restrict domains the LLM can request to contact upstream which allows an authenticated user to exfiltrate data from an arbitrary server accessible to the victim via performing a prompt injection in the AI plugin's Jira tool.