Package Instance

org.xwiki.platform:xwiki-platform-oldcore allows SQL injection in short form select requests through the script query API
### 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 15.10.16.

### Workarounds

There is no known workaround, other than upgrading XWiki.

The protection added to this REST API is the same as the one used to validate complete select queries, making it more consistent. However, while the script API always had this protection for complete queries, it's important to note that it's a very strict protection and some valid, but complex, queries might suddenly require the author to have programming right.

### References

https://jira.xwiki.org/browse/XWIKI-22718

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

XWiki leaks password hashes and other accessible password properties
### Impact
Any user with edit right on a page of the wiki can create an XClass with a database list property that references a password property, for example the password hash that is stored for users. When adding an object of that XClass, the content of that password property is displayed. In practice, with a standard rights setup, this means that any user with an account on the wiki can access password hashes of all users, and possibly other password properties (with hashed or plain storage) that are on pages that the user can view.

### Patches
This vulnerability has been pached in XWiki 16.4.7, 16.10.5, and 17.2.0 by disallowing the use of password properties in database list properties. Additionally, queries for email properties are disallowed, too, when email obfuscation is enabled.

### Workarounds
We're not aware of any workarounds.

XWiki allows remote code execution through preview of XClass changes in AWM editor
### Impact
Any XWiki user with edit right on at least one App Within Minutes application (the default for all users XWiki) can obtain programming right/perform remote code execution by editing the application. The detailed reproduction steps can be found in the [original bug report](https://jira.xwiki.org/browse/XWIKI-22719).

### Patches
This vulnerability has been fixed in XWiki 17.0.0, 16.4.7, and 16.10.3.

### Workarounds
Restricting edit rights on all existing App Within Minutes applications to trusted users mitigates at least the PoC exploit, but we can't exclude that there are other ways to exploit this vulnerability.

XWiki allows SQL injection in query endpoint of REST API with Oracle
### Impact

It's possible to execute any SQL query in Oracle by using the function like [DBMS_XMLGEN or DBMS_XMLQUERY](https://docs.oracle.com/en/database/oracle/oracle-database/19/arpls/DBMS_XMLGEN.html).

The XWiki query validator does not sanitize functions that would be used in a simple `select` and Hibernate allows using any native function in an HQL query.

### Patches

This has been patched in 16.10.2, 16.4.7 and 15.10.16.

### Workarounds

There is no known workaround, other than upgrading XWiki.

### References

https://jira.xwiki.org/browse/XWIKI-22734

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

XWiki exposes passwords and emails stored in fields not named password/email in xml.vm
### Impact
The XML export of a page in XWiki that can be triggered by any user with view rights on a page by appending `?xpage=xml` to the URL includes password and email properties stored on a document that aren't named `password` or `email`. This allows any user to obtain the salted and hashed user account validation or password reset token. As those tokens are randomly generated strings, the immediate impact of this should be low. The user's password and email itself aren't exposed as those fields are named `password` and `email` and thus aren't affected. However, depending on how the wiki is used, there could be extensions or custom code that store passwords in plain text in such password properties that would be exposed by this vulnerability.

### Patches
This vulnerability has been fixed by completely removing the output of password and email fields in this XML export in versions 17.2.0 RC1, 16.10.5 and 16.4.7.

### Workarounds
If this XML export isn't needed, the file `templates/xml.vm` in the deployed WAR can be deleted. There isn't any feature in XWiki itself that depends on this XML export.