Package Instance

XWiki Platform vulnerable to document deletion and overwrite from edit
### Impact

When a user has edit but not view right on a page in XWiki, that user can delete the page and replace it by a page with new content without having delete right. The previous version of the page is moved into the recycle bin and can be restored from there by an admin. As the user is recorded as deleter, the user would in theory also be able to view the deleted content, but this is not directly possible as rights of the previous version are transferred to the new page and thus the user still doesn't have view right on the page. From all we examined, it therefore doesn't seem to be possible to exploit this to gain any rights.

To reproduce, just replace `view` by `edit` in the URL of a page that you cannot view but edit and save. This should send the page to the recycle bin and replace it by an empty one if the XWiki installation is vulnerable. After the fix, an error is displayed when saving.

### Patches
This has been patched in XWiki 14.10.21, 15.5.5 and 15.10.6 by cancelling save operations by users when a new document shall be saved despite the document's existing already.

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

### References
* https://jira.xwiki.org/browse/XWIKI-21553
* https://github.com/xwiki/xwiki-platform/commit/c5efc1e519e710afdf3c5f40c0fcc300ad77149f

XWiki Platform allows remote code execution from user account
### Impact
When an admin disables a user account, the user's profile is executed with the admin's rights. This allows a user to place malicious code in the user profile before getting an admin to disable the user account.

To reproduce, as a user without script nor programming rights, edit the about section of your user profile and add `{{groovy}}services.logging.getLogger("attacker").error("Hello from Groovy!"){{/groovy}}`.
As an admin, go to the user profile and click the "Disable this account" button.
Then, reload the page. If the logs show `attacker - Hello from Groovy!` then the instance is vulnerable.

### Patches
This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.

### Workarounds
We're not aware of any workaround except upgrading.

### References
* https://jira.xwiki.org/browse/XWIKI-21611
* https://github.com/xwiki/xwiki-platform/commit/f89c8f47fad6e5cc7e68c69a7e0acde07f5eed5a

XWiki Platform allows XSS through XClass name in string properties
### Impact
Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript.
This requires social engineer to trick a user to follow the URL.

#### Reproduction steps

1. As a user without script or programming right, create a (non-terminal) document named `" + alert(1) + "` (the quotes need to be part of the name).
1. Edit the class.
1. Add a string property named `"test"`.
1. Edit using the object editor and add an object of the created class
1. Get an admin to open `<xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit` where `<xwiki-server>` is the URL of your XWiki installation.

### Patches
This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.

### Workarounds

We're not aware of any workaround except upgrading.

### References
- https://jira.xwiki.org/browse/XWIKI-21810
- https://github.com/xwiki/xwiki-platform/commit/27eca8423fc1ad177518077a733076821268509c