Michael Hamann

Name of the Vulnerable Software and Affected Versions: XWiki Remote Macros versions 1.0 through 1.26.5 Description: XWiki Remote Macros provides XWiki rendering macros used for migrating content from Confluence. A missing escaping mechanism in the `ac:type` parameter within the `ConfluenceLayoutSection` macro allows for remote code execution. The `classes` parameter is used without proper escaping in XWiki syntax, enabling XWiki syntax injection, which also leads to remote code execution. Recommendations: Update to version 1.26.5 or later.

Name of the Vulnerable Software and Affected Versions: XWiki Platform versions 14.4.2 through 16.4.7 XWiki Platform versions 16.5.0-rc-1 through 16.10.6 XWiki Platform versions 17.0.0-rc-1 through 17.4.0-rc-1 Description: The PDF export jobs store sensitive cookies unencrypted in job statuses. This includes the encrypted username and password, which effectively exposes the plain text password if the encryption key is compromised. The encryption key is stored in the same data directory as the job status, making it accessible. The vulnerability exists because the job status includes cookies from the HTTP request that triggered the export. Recommendations: Upgrade to XWiki Platform version 16.4.8 or later. Upgrade to XWiki Platform version 16.10.7 or later. Upgrade to XWiki Platform version 17.4.0-rc-1 or later.

The platform contains reflected cross-site scripting (XSS) vulnerabilities in two templates. An attacker can execute malicious JavaScript code in the context of a victim's session by getting the victim to visit a crafted URL. This allows the attacker to perform actions using the victim's permissions. The issue is exploitable through URLs such as `/xwiki/bin/view/Main/?xpage=job status json&jobId=asdf&translationPrefix=<img src=1 onerror=alert(document.domain)>` and `/xwiki/bin/view/Main/?xpage=distribution&extensionId=%3Cimg src=x onerror=alert(document.domain)%3E&extensionVersionConstraint=%3Cimg src=x onerror=alert(document.domain)%3E`.

The issue allows any user with edit rights on a page to execute code, including Groovy, Python, and Velocity, with programming rights by defining a wiki macro. This can grant full access to the whole XWiki installation. The problem arises when a wiki macro parameter allows wiki syntax, and its default value is executed with the rights of the author of the document where it is used. This can be exploited by overriding a macro, such as the children macro, allowing arbitrary script macros.

The XWiki Platform, a generic wiki platform, contains a flaw in the REST search URL. The `orderField` parameter is susceptible to HQL injection. The value provided for this parameter is included twice in the query, requiring careful manipulation to exploit. Specifically, enclosing the query segment between the two instances of the field in single quotes can bypass the constraints, but the query must remain valid with the parameter appearing twice. This issue affects versions starting from 4.3-milestone-1 and is addressed in versions 16.10.9, 17.4.2, and 17.5.0. The API endpoint involved is the REST search URL. The vulnerable parameter is `orderField`.

The issue allows any user to embed Javascript code using Markdown syntax, which can be executed on the browser of other users visiting the document or comment containing it. This compromises the confidentiality, integrity, and availability of the entire XWiki installation, especially if the code is executed by a user with administrative or programming rights.

XWiki is a generic wiki platform that warns about the execution of "dangerous" macros like malicious script macros authored by a user with fewer rights since XWiki 15.9RC1. However, the required rights analyzers that trigger these warnings are incomplete, allowing an attacker to hide malicious content. The existing analyzers do not consider non-lowercase parameters, and most macro parameters that can contain XWiki syntax were not analyzed. This could allow a malicious user to add malicious script macros, including Groovy or Python macros, to a page that are then executed after another user with programming rights edits the page, thus allowing remote code execution.

The issue is related to a bug in the implementation of required rights in XWiki, allowing any user with edit right on a document to set programming right as required right. This could lead to remote code execution if a user with programming right edits the document. The impact is considered low, as the vulnerability provides no additional attack surface unless all documents in the wiki enforce required rights. However, gaining programming right could have a high impact.

XWiki Platform Legacy Old Core and XWiki Platform Old Core allows any user with editing rights to create an XClass with a database list property that references a password property. When adding an object of that XClass, the content of the password property is displayed, potentially exposing password hashes of all users and other password properties to any user with an account on the wiki.

XWiki Platform Legacy Old Core and XWiki Platform Old Core are affected by an issue where the XML export of a page, accessible to any user with view rights by appending `?xpage=xml` to the URL, includes `password` and `email` properties stored on a document – even if these properties are not explicitly named `password` or `email`.

The issue affects XWiki, a generic wiki platform, where an attacker can access the title of every single page whose reference is known through the REST API, as long as an XClass with a page property is accessible. This is the default for an XWiki installation. The impact on confidentiality depends on the strategy for page names, with low impact if page names match the title, but potentially high impact if page names are intentionally obfuscated because the titles are sensitive.

XWiki Platform is a generic wiki platform. Starting in version 9.7-rc-1 and prior to versions 15.10.11, 16.4.1, and 16.5.0, any user with an account can perform arbitrary remote code execution by adding instances of `XWiki.WikiMacroClass` to any page. This compromises the confidentiality, integrity, and availability of the whole XWiki installation. The vulnerability has been fixed in XWiki 15.10.11, 16.4.1, and 16.5.0.

The issue allows any user with an account on the main wiki to run scheduling operations on subwikis. To reproduce, a user on the main wiki without any special right can view the document `Scheduler.WebHome` in a subwiki, then click on any operation (e.g., Trigger) on any job. If the operation is successful, the instance is vulnerable.

XWiki Platform is a generic wiki platform. On instances where `Extension Repository Application` is installed, any user can execute any code requiring `programming` rights on the server. This issue has been fixed in XWiki 15.10.9 and 16.3.0. Since `Extension Repository Application` is not mandatory, it can be safely disabled on instances that do not use it as a workaround. It is also possible to manually apply the patches from commit 8659f17d500522bf33595e402391592a35a162e8 to the page `ExtensionCode.ExtensionSheet` and to the page `ExtensionCode.ExtensionAuthorsDisplayer`.

The issue arises when a user without script rights creates a document containing an XWiki.Notifications.Code.NotificationDisplayerClass object. If an admin later edits and saves this document, the potentially malicious content of the object is output as raw HTML, allowing cross-site scripting (XSS) attacks. The notification displayer executes Velocity code, and while a generic analyzer warns admins about editing Velocity code, warnings for editing documents with dangerous properties were only introduced in XWiki 15.9.

The issue affects XWiki, a generic wiki platform. It occurs when a user without script right creates a document with an `XWiki.Notifications.Code.NotificationEmailRendererClass` object. If an admin later edits and saves that document, the email templates in this object will be used for notifications. Although no malicious code can be executed due to the existing generic analyzer warning admins before editing Velocity code, the main impact could be to send spam, such as phishing links to other users, or to hide notifications about other attacks.

A user without script or programming rights can trick a user with elevated rights to edit content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time.

The issue allows a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript, which requires a social engineer to trick a user into following the URL.

The issue allows any user with edit rights on any page to perform arbitrary remote code execution by adding instances of `XWiki.SearchSuggestConfig` and `XWiki.SearchSuggestSourceClass` to their user profile or any other page. This compromises the confidentiality, integrity, and availability of the whole XWiki installation.

The issue allows an attacker to execute JavaScript snippets on the side of another user, compromising the confidentiality, integrity, and availability of the whole XWiki installation. This can be achieved by creating a conflict when another user with more rights is currently editing a page. The estimated number of potentially affected devices is not specified. To exploit this issue, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to `<script>alert('XSS')</script>`. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable.