#jira

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

Millions of scam text messages are sent every month. The Chinese cybercriminals behind many of them are expanding their operations—and quickly innovating.

HellCat ransomware hits 4 companies by exploiting Jira credentials stolen through infostealer malware, continuing their global attack spree.

### Impact If the JIRA macro is installed, any logged in XWiki user could edit his/her user profile wiki page and use that JIRA macro, specifying a fake JIRA URL that returns an XML specifying a DOCTYPE pointing to a local file on the XWiki server host and displaying that file's content in one of the returned JIRA fields (such as the summary or description for example). For example: ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <rss version="0.92"> ... <item> <title>&xxe;</title> <link>https://jira.xwiki.org/browse/XE-307</link> <project id="10222" key="XE">{RETIRED} XWiki Enterprise</project> <description>&xxe;</description> <environment/> ... ``` ### Patches The vulnerability has been patched in the JIRA Extension v8.6.5. ### Workarounds No easy workaround except to upgrade (which is easy using the XWiki Extension Manager). ### References * https://github.com/xwiki-contrib/jira/commit/98a...

### Impact Any user can exploit the WikiManager REST API to create a new wiki, where the user could become an administrator and so performs other attacks on the farm. Note that this REST API is not bundled in XWiki Standard by default: it needs to be installed manually through the extension manager. ### Patches The problem has been patched in versions 15.10.15, 16.4.6 and 16.10.0 of the REST module. ### Workarounds There's no workaround other than upgrading the dependency. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22490 * Commit of the fix: https://github.com/xwiki/xwiki-platform/commit/82aa670106c7f5e6238ca6ed59a52d1800e05b99 ### 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 You can specify here who reported the issue.