Effect Any user with edit rights can edit all pages in the CKEditor' space. This makes it possible to perform a variety of harmful actions, such as - removing technical documents, leading to loss of service - Editing the javascript configuration of CKEditor, leading to persistent XSS
Patches This issue has been patched in XWiki 14.10.6 and XWiki 15.1. This issue has been patched on the CKEditor Integration extension 1.64.9 for XWiki version older than 14.6RC1.
Workarounds The issue can be fixed manually by restricting the edit and delete rights to a trusted user or group (e.g. the XWiki.XWikiAdminGroup group), implicitly disabling those rights for all other users. See https://github.com/xwiki/xwiki-platform/commit/9d9d86179457cb8dc48b4491510537878800be4f
References - https://jira.xwiki.org/browse/XWIKI-20590 - https://jira.xwiki.org/browse/CKEDITOR-508 - https://github.com/xwiki/xwiki-platform/commit/9d9d86179457cb8dc48b4491510537878800be4f
For more information
If you have any questions or comments about this advisory:
Open an issue in Jira XWiki.org Email us at Security Mailing List
Impact By either creating a new or editing an existing document with an icon set, an attacker can inject XWiki syntax and Velocity code that is executed with programming rights and thus allows remote code execution. There are different attack vectors, the simplest is the Velocity code in the icon set's HTML or XWiki syntax definition. The icon picker can be used to trigger the rendering of any icon set. The XWiki syntax variant of the icon set is also used without any escaping in some documents, allowing to inject XWiki syntax including script macros into a document that might have programming right, for this the currently used icon theme needs to be edited. Further, the HTML output of the icon set is output as JSON in the icon picker and this JSON is interpreted as XWiki syntax, allowing again the injection of script macros into a document with programming right and thus allowing remote code execution. This impacts the confidentiality, integrity and availability of the whole XWiki instance.
Patches
This has been patched in XWiki 14.10.6 and 15.1. Icon themes now require script right and the code in the icon theme is executed within the context of the icon theme, preventing any rights escalation. A macro for displaying icons has been introduced to avoid injecting the raw wiki syntax of an icon set into another document.
Workarounds There are no workarounds apart from upgrading to a version containing the fix.
References
https://jira.xwiki.org/browse/XWIKI-20524 https://github.com/xwiki/xwiki-platform/commit/b0cdfd893912baaa053d106a92e39fa1858843c7 https://github.com/xwiki/xwiki-platform/commit/46b542854978e9caa687a5c2b8817b8b17877d94 https://github.com/xwiki/xwiki-platform/commit/79418dd92ca11941b46987ef881bf50424898ff4
Impact
When an XWiki installation is upgraded and that upgrade contains a fix for a bug in a document, just a new version of that document is added. In some cases, it's still possible to exploit the vulnerability that was fixed in the new version. The severity of this depends on the fixed vulnerability, for the purpose of this advisory take CVE-2022-36100 as example - it is easily exploitable with just view rights and critical. When XWiki is upgraded from a version before the fix for it (e.g., 14.3) to a version including the fix (e.g., 14.4), the vulnerability can still be reproduced by adding rev=1.1 to the URL used in the reproduction steps so remote code execution is possible even after upgrading. Therefore, this affects the confidentiality, integrity and availability of the whole XWiki installation. This vulnerability also affects manually added script macros that contained security vulnerabilities that were later fixed by changing the script macro without deleting the versions with the security vulnerability from the history.
This vulnerability doesn't affect freshly installed versions of XWiki. Further, this vulnerability doesn't affect content that is only loaded from the current version of a document like the code of wiki macros or UI extensions.
Patches
This vulnerability has been patched in XWiki 14.10.7 and 15.2RC1 by forcing old revisions to be executed in a restricted mode that disables all script macros.
Workarounds
As a workaround, admins can manually delete old revisions of affected documents. A script could be used to identify all installed documents and delete the history for them. However, also manually added and later corrected code may be affected by this vulnerability so it is easy to miss documents.
References
https://jira.xwiki.org/browse/XWIKI-20594 https://github.com/xwiki/xwiki-platform/commit/15a6f845d8206b0ae97f37aa092ca43d4f9d6e59
Impact
Any user who can edit their own user profile and notification settings can execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. This can be reproduced with the following steps:
1. Login as a user without script or programming right. 2. Go to the notifications preferences in your user profile. 3. Disable the "Own Events Filter" and enable notifications in the notification menu for "Like". 4. Set your first name to {{cache id="security" timeToLive="1"}}{{groovy}}println("Hello from groovy!"){{/groovy}}{{/cache}} 5. Click on the like button at the bottom left of the user profile. 6. Click on the notifications bell in the top bar and then on "RSS Feed".
If the text "Profile of Hello from groovy!" and/or "liked by Hello from groovy!" is displayed, the attack succeeded. The expected result would have been that the entered first name is displayed as-is in the description of the feed.
Patches This has been patched in XWiki 14.10.6 and 15.2RC1.
Workarounds The main security fix can be manually applied by patching the affected document XWiki.Notifications.Code.NotificationRSSService as shown in the patch. This will break the link to the differences, though as this requires additional changes to Velocity templates as shown in the patch. While the default template is available in the instance and can be easily patched, the template for mentions is contained in a .jar-file and thus cannot be fixed without replacing that jar.
References https://jira.xwiki.org/browse/XWIKI-20610 https://github.com/xwiki/xwiki-platform/commit/217e5bb7a657f2991b154a16ef4d5ae9c29ad39c
Impact Any user can call a REST endpoint and obtain the obfuscated passwords (even when the mail obfuscation is activated).
For instance, by calling http://localhost:8080/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/U1/objects/XWiki.XWikiUsers/0 when user U1 exists on wiki xwiki.
Patches The issue has been patched on XWiki 14.4.8, 14.10.6, and 15.1
Workarounds There is no known workaround. It is advised to upgrade to one of the patched versions.
References - https://jira.xwiki.org/browse/XWIKI-16138 - https://github.com/xwiki/xwiki-platform/commit/824cd742ecf5439971247da11bfe7e0ad2b10ede
For more information
If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
Impact Any logged in user can add dangerous content in their first name field and see it executed with programming rights. Leading to rights escalation.
Patches The vulnerability has been fixed on XWiki 14.4.8, 14.10.6, and 15.1.
Workarounds The vulnerability can be fixed by applying this patch.
On versions before 13.4-rc-1, the fix needs to be applied on XWiki.Like.Code.LiveTableResultPage.
References - The reported issue https://jira.xwiki.org/browse/XWIKI-20611, fixed by https://jira.xwiki.org/browse/XWIKI-19900 - The patch https://github.com/xwiki/xwiki-platform/commit/6ce2d04a5779e07f6d3ed3f37d4761049b4fc3ac#diff-ef7f8b911bb8e584fda22aac5876a329add35ca0d1d32e0fdb62a439b78cfa49 For more information
If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email us at Security Mailing List
XWiki Platform is a generic wiki platform. Starting in version 5.4.4 and prior to versions 14.4.8, 14.10.4, and 15.0, a stored cross-site scripting vulnerability can be exploited by users with edit rights by adding a AppWithinMinutes.FormFieldCategoryClass class on a page and setting the payload on the page title. Then, any user visiting /xwiki/bin/view/AppWithinMinutes/ClassEditSheet executes the payload. The issue has been patched in XWiki 14.4.8, 14.10.4, and 15.0. As a workaround, update AppWithinMinutes.ClassEditSheet with a patch.