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.WebHome vulnerable to Improper Privilege Management in XWiki resolving groups
### Impact

It's possible to exploit a bug in XWikiRights resolution of groups to obtain privilege escalation. 

More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right.

Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights. 

### Patches

The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights. 

### Workarounds

It's possible to workaround the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it. 

### References

* https://jira.xwiki.org/browse/XWIKI-18386
* https://jira.xwiki.org/browse/XWIKI-15776

### 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 Platform Old Core vulnerable to Authentication Bypass Using the Login Action
### Impact
All rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects (class and property name must be known, though). This is also exploitable on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki).

### Patches
This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action.

### Workarounds
It would be possible to protect all templates individually by adding code to check access rights first, but due to the number of templates and the fact that some of them need to be used without view rights, this seems impractical.

### References
* https://jira.xwiki.org/browse/XWIKI-19549
* https://jira.xwiki.org/browse/XWIKI-18602

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