See how xwiki compares to other vendors in security performance
Impact
The Blog Application is vulnerable to Stored Cross-Site Scripting (XSS) via the Blog Post Title. The vulnerability arises because the post title is injected directly into the HTML <title> tag without proper escaping.
An attacker with permissions to create or edit blog posts can inject malicious JavaScript into the title field. This script will execute in the browser of any user (including administrators) who views the blog post. This leads to potential session hijacking or privilege escalation.
To reproduce:
Log in as a user with rights to create blog posts. Create a new blog post. In the Title field, insert the following payload designed to break out of the title tag: </title><script>alert('XSS in title blog')</script> Save (Publish) the post. View the post in the blog home page
Patches The vulnerability has been patched in the blog application version 9.15.7 by adding missing escaping.
Workarounds XWiki Blog Application maintainers are not aware of any workarounds.
Resources https://jira.xwiki.org/browse/BLOG-245 https://github.com/xwiki-contrib/application-blog/commit/cca87f0a0edc2e7e049d46d51f4a4d8f78b714ba
Attribution
Łukasz Rybak reported this vulnerability.
Impact An improperly protected scripting API allows any user with script right to bypass the sandboxing of the Velocity scripting API and execute, e.g., arbitrary Python scripts, allowing full access to the XWiki instance and thereby compromising the confidentiality, integrity and availability of the whole instance. Note that script right already constitutes a high level of access that we don't recommend giving to untrusted users.
Patches The vulnerability has been patched in XWiki 17.4.8 and 17.10.1 by requiring programming right to access the affected scripting API.
Workarounds We're not aware of any workarounds except for being careful whom you grant script right.
Attribution We thank Youssef Azefzaf for discovering and reporting this vulnerability.
Impact
It's possible to get access and read configuration files by using URLs such as http://localhost:8080/bin/ssx/Main/WebHome?resource=/../../WEB-INF/xwiki.cfg&minify=false.
This can apparently be reproduced on Tomcat instances.
Patches
This has been patched in 18.0.0-rc-1, 17.10.3, 17.4.9, 16.10.17.
Workarounds
There is no known workaround, other than upgrading XWiki.
References
https://jira.xwiki.org/browse/XCOMMONS-3547 https://github.com/xwiki/xwiki-commons/commit/a979cafd89f6a9c9c0b9ab19744d672df64429bf
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
Attribution
The vulnerability was reported by Michał Kołek.
Impact
POST /wikis/{wikiName} executes a XAR import without performing any authentication or authorization checks, allowing an unauthenticated attacker to create or update documents in the target wiki
Patches
This vulnerability has been patched in XWiki 16.10.17, 17.4.9, 17.10.3, 18.0.1 and 18.1.0-rc-1.
Workarounds
XWiki is not aware of any workarounds other than adding a rule into an HTTP proxy to prevent access POST request in the /wikis/{wikiName}[/] endpoint.
Resources
https://jira.xwiki.org/browse/XWIKI-23953 https://github.com/xwiki/xwiki-platform/commit/4b7b95b79256374d487e9ece1dc48f527966990f
For more information
If there are any questions or comments about this advisory: Open an issue in Jira XWiki.org Send an email to the Security Mailing List
Attribution
Reported by Sho Odagiri (GMO Cybersecurity by Ierae, Inc.).
Impact
It's possible for an user to get access to private information through the REST API - but could also be through another API - when a sub wiki is using "Prevent unregistered users to view pages". The vulnerability only affects subwikis, and it only concerns specific right options such as "Prevent unregistered users to view pages". or "Prevent unregistered users to edit pages".
It's possible to detect the vulnerability by enabling "Prevent unregistered users to view pages" and then trying to access a page through the REST API without using any credentials.
Patches
The vulnerability has been patched in XWiki 15.10.14, 16.4.6 and 16.10.0RC1.
Workarounds
There's no workaround.
References
JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22640 Commit of the fix: https://github.com/xwiki/xwiki-platform/commit/5f98bde87288326cf5787604e2bb87836875ed0e
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
Protected pages are listed when requesting the REST endpoints /rest/wikis/[wikiName]/pages even if the user doesn't have view rights on them. It's particularly true if the entire wiki is protected with "Prevent unregistered user to view pages": the endpoint would still list the pages of the wiki (actually it only impacts the main wiki due to XWIKI-22639).
Patches
The problem has been patched in XWiki 15.10.14, 16.4.6, 16.10.0RC1. In those versions the endpoint can still be requested but the result is filtered out based on pages rights.
Workarounds
There's no workaround except upgrading or applying manually the changes of the commits (see references) in xwiki-platform-rest-server and recompiling / rebuilding it.
References
Original JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22630 Related JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22639 Commits of the patch: https://github.com/xwiki/xwiki-platform/commit/bca72f5ce971a31dba2a016d8dd8badda4475206 and https://github.com/xwiki/xwiki-platform/commit/1fb12d2780f37b34a1b4dfdf8457d97ce5cbb2df
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 user can exploit the WikiManager REST API to create a new wiki, where the user could become an administrator and so performs other attacks on the farm. Note that this REST API is not bundled in XWiki Standard by default: it needs to be installed manually through the extension manager.
Patches
The problem has been patched in versions 15.10.15, 16.4.6 and 16.10.0 of the REST module.
Workarounds
There's no workaround other than upgrading the dependency.
References
JIRA ticket: https://jira.xwiki.org/browse/XWIKI-22490 Commit of the fix: https://github.com/xwiki/xwiki-platform/commit/82aa670106c7f5e6238ca6ed59a52d1800e05b99
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
Attribution
You can specify here who reported the issue.
Impact A user that doesn't have programming rights can execute arbitrary code when creating a page using the Migration Page template. A possible attack vector is the following: Create a page and add the following content: confluencepro.job.question.advanced.input={{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} Use the object editor to add an object of type XWiki.TranslationDocumentClass with scope USER. Access an unexisting page using the MigrationTemplate http://localhost:8080/xwiki/bin/edit/Page123?template=ConfluenceMigratorPro.Code.MigrationTemplate It is expected that {{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} will be present on the page, however, hello from groovy will be printed. Patches The issue will be fixed as part of v1.2. The fix was added with commit 35cef22
Workarounds There are no known workarounds besides upgrading.
References No references.
Impact The homepage of the application is public which enables a guest to download the package which might contain sensitive information.
Patches 1.11.7
Workarounds The access to the page can be manually restricted to a specific set of users or groups.
Impact Any guest can perform arbitrary remote code execution through a request to SolrSearch. This impacts the confidentiality, integrity and availability of the whole XWiki installation.
To reproduce on an instance, without being logged in, go to <host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28"Hello%20from"%20%2B%20"%20search%20text%3A"%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If there is an output, and the title of the RSS feed contains Hello from search text:42, then the instance is vulnerable.
Patches This vulnerability has been patched in XWiki 15.10.11, 16.4.1 and 16.5.0RC1.
Workarounds This line in Main.SolrSearchMacros can be edited to match the rawResponse macro defined here with a content type of application/xml, instead of simply outputting the content of the feed.
References
https://jira.xwiki.org/browse/XWIKI-22149 https://github.com/xwiki/xwiki-platform/commit/67021db9b8ed26c2236a653269302a86bf01ef40
Attribution This vulnerability has been reported by John Kwak for Trend Micro's Zero Day Initiative.
Impact The licensor application includes the document Licenses.Code.LicenseJSON that provides information for admins regarding active licenses. This document is public and thus exposes this information publicly. The information includes the instance's id as well as first and last name and email of the license owner. This is a leak of information that isn't supposed to be public. The instance id allows associating data on the active installs data with the concrete XWiki instance. Active installs assures that "there's no way to find who's having a given UUID" (referring to the instance id). Further, the information who the license owner is and information about the obtained licenses can be used for targeted phishing attacks. Also, while user information is normally public, email addresses might only be displayed obfuscated (depending on the configuration).
Patches This has been fixed in Application Licensing 1.24.2, by https://github.com/xwikisas/application-licensing/commit/d168fb88fc0d121bf95e769ea21c55c00bebe5a6
Workarounds There are no known workarounds besides upgrading.
References Fixed by https://github.com/xwikisas/application-licensing/commit/d168fb88fc0d121bf95e769ea21c55c00bebe5a6
Impact XWiki is vulnerable to a remote code execution (RCE) attack through its user registration feature. This issue allows an attacker to execute arbitrary code by crafting malicious payloads in the "first name" or "last name" fields during user registration. This impacts all installations that have user registration enabled for guests.
To reproduce, register with any username and password and the following payload as "first name": ]]{{/html}}{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack succeeded){{/groovy}}{{/async}}. In the following page that confirms the success of the registration, the full first name should be displayed, linking to the created user. If the formatting is broken and a log message with content "ERROR attacker - Attack succeeded!" is logged, the attack succeeded.
Patches This vulnerability has been patched in XWiki 14.10.17, 15.5.3 and 15.8 RC1.
Workarounds
In the administration of your wiki, under "Users & Rights" > "Registration" set the "Registration Successful Message" to the following code:
velocity #set($message = $services.localization.render('core.register.successful', 'xwiki/2.1', ['USERLINK', $userName])) #set($userLink = $xwiki.getUserName("$userSpace$userName")) {{info}}$message.replace('USERLINK', "{{html clean=false}}$userLink{{/html}}"){{/info}}
References https://jira.xwiki.org/browse/XWIKI-21173 https://github.com/xwiki/xwiki-platform/commit/b290bfd573c6f7db6cc15a88dd4111d9fcad0d31
Impact
The rollback action is missing a right protection: it means that a user can rollback to a previous version of the page to gain rights they don't have anymore. This vulnerability impacts all version of XWiki since rollback action is available.
Patches
The problem has been patched in XWiki 14.10.16, 15.5.3 and 15.8-rc-1 by ensuring that the rights are checked before performing the rollback.
Workarounds
There's no workaround for this vulnerability, except paying attention to delete old versions of documents that could allow users to gain more rights.
References
JIRA ticket: https://jira.xwiki.org/browse/XWIKI-21257 Commit: 4de72875ca49602796165412741033bfdbf1e680
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
A user able to attach a file to a page can post a malformed TAR file by manipulating file modification times headers, which when parsed by Tika, could cause a denial of service issue via CPU consumption.
Patches This vulnerability has been patched in XWiki 14.10.18, 15.5.3 and 15.8 RC1.
Workarounds
The workaround is to download commons-compress 1.24 and replace the one located in XWiki WEB-INF/lib/ folder.
References
https://jira.xwiki.org/browse/XCOMMONS-2796
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
Improper escaping in the document SkinsCode.XWikiSkinsSheet leads to a possible privilege escalation from view right on that document to programming rights, or in other words, it is possible to execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents.
The attack works by opening a non-existing page with a name crafted to contain a dangerous payload.
It is possible to check if an existing installation is vulnerable by opening <xwiki-host>/xwiki/bin/view/%22%5D%5D%20%7B%7Basync%20async%3D%22true%22%20cached%3D%22false%22%20context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln(%22Hello%20%22%20%2B%20%22from%20groovy!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D?sheet=SkinsCode.XWikiSkinsSheet&xpage=view where <xwiki-host is the URL of the XWiki installation. The expected result are two list items with "Edit this skin" and "Test this skin" without any further text. If the installation is vulnerable, the second list item is "Test this skin Hello from groovy!.WebHome"]]". This shows that the Groovy macro has been executed.
Patches
This has been patched in XWiki 14.4.8, 14.10.4 and 15.0-rc-1.
Workarounds
The fix can also be applied manually to the impacted document SkinsCode.XWikiSkinsSheet.
References
https://jira.xwiki.org/browse/XWIKI-20457 https://github.com/xwiki/xwiki-platform/commit/d9c88ddc4c0c78fa534bd33237e95dea66003d29
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
The REST API allows executing all actions via POST requests and accepts text/plain, multipart/form-data or application/www-form-urlencoded as content types which can be sent via regular HTML forms, thus allowing cross-site request forgery. With the interaction of a user with programming rights, this allows remote code execution through script macros and thus impacts the integrity, availability and confidentiality of the whole XWiki installation.
For regular cookie-based authentication, the vulnerability is mitigated by SameSite cookie restrictions but as of March 2023, these are not enabled by default in Firefox and Safari.
Patches The vulnerability has been patched in XWiki 14.10.8 and 15.2 by requiring a CSRF token header for certain request types that are susceptible to CSRF attacks.
Workarounds
It is possible to check for the Origin header in a reverse proxy to protect the REST endpoint from CSRF attacks, see the Jira issue for an example configuration.
References
https://jira.xwiki.org/browse/XWIKI-20135 https://github.com/xwiki/xwiki-platform/commit/4c175405faa0e62437df397811c7526dfc0fbae7
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
The HTML sanitizer that is included in XWiki since version 14.6RC1 allowed form and input HTML tags. In the context of XWiki, this allows an attacker without script right to either create forms that can be used for phishing attacks or also in the context of a sheet, the attacker could add an input like {{html}}<input type="hidden" name="content" value="{{groovy}}println("Hello from Groovy!")" />{{/html}} that would allow remote code execution when it is submitted by an admin (the sheet is rendered as part of the edit form). The attacker would need to ensure that the edit form looks plausible, though, which can be non-trivial as without script right the attacker cannot display the regular content of the document.
Patches This has been patched in XWiki 14.10.6 and 15.2RC1 by removing the central form-related tags from the list of allowed tags.
Workarounds An admin can manually disallow the tags by adding form, input, select, textarea, button to the configuration option xml.htmlElementSanitizer.forbidTags in the xwiki.properties configuration file.
References https://jira.xwiki.org/browse/XCOMMONS-2634 https://github.com/xwiki/xwiki-commons/commit/99484d48e899a68a1b6e33d457825b776c6fe8c3
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
It's possible to execute any wiki content with the right of the TipsPanel author by creating a tip UI extension.
To reproduce: Add an object of type UIExtensionClass Set "Extension Point ID" to org.xwiki.platform.help.tipsPanel Set "Extension ID" to org.xwiki.platform.user.test (needs to be unique but otherwise doesn't matter) Set "Extension Parameters" to tip={{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} Set "Extension Scope" to "Current User". Click "Save & View" Open the "Help.TipsPanel" document at <xwiki-host>/xwiki/bin/view/Help/TipsPanel where <xwiki-host> is the URL of your XWiki installation and press refresh repeatedly.
The groovy macro is executed, after the fix you get an error instead.
Patches
This has been patched in XWiki 15.1-rc-1 and 14.10.5.
Workarounds
There are no known workarounds for it.
References
https://jira.xwiki.org/browse/XWIKI-20281 https://github.com/xwiki/xwiki-platform/commit/98208c5bb1e8cdf3ff1ac35d8b3d1cb3c28b3263#diff-4e3467d2ef3871a68b2f910e67cf84531751b32e0126321be83c0f1ed5d90b29L176-R178
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 Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the deletespace template to perform a XSS, e.g. by using URL such as:
xwiki/bin/deletespace/Sandbox/?xredirect=javascript:alert(document.domain)
This vulnerability exists since XWiki 3.4-milestone-1.
Patches The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the template deletespace.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20612 Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583 Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bdea50f1053fe99a27e011b8d0e4b34
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 Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the previewactions template to perform a XSS, e.g. by using URL such as: <hostname>/xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=previewactions.vm&xcontinue=javascript:alert(document.domain)
This vulnerability exists since XWiki 6.1-rc-1.
Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the template previewactions.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20342 Introduction of the macro used for fixing this type of vulnerability: https://jira.xwiki.org/browse/XWIKI-20583 Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/9f01166b1a8ee9639666099eb5040302df067e4d
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
Attribution
This vulnerability has been reported by René de Sain @renniepak.
Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the resubmit template to perform a XSS, e.g. by using URL such as:
> xwiki/bin/view/XWiki/Main?xpage=resubmit&resubmit=javascript:alert(document.domain)&xback=javascript:alert(document.domain)
This vulnerability exists since XWiki 2.5-milestone-2.
Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the template resubmit.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20343 Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583 Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/dbc92dcdace33823ffd1e1591617006cb5fc6a7f
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
Attribution
This vulnerability has been reported by René de Sain @renniepak.
Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the DeleteApplication page to perform a XSS, e.g. by using URL such as:
xwiki/bin/view/AppWithinMinutes/DeleteApplication?appName=Menu&resolve=true&xredirect=javascript:alert(document.domain)
This vulnerability exists since XWiki 6.2-milestone-1.
Patches
The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Workarounds
It's possible to workaround the vulnerability by editing the page AppWithinMinutes.DeleteApplication to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20614 Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583 Commit containing the actual fix in the page: https://github.com/xwiki/xwiki-platform/commit/8f5a889b7cd140770e54f5b4195d88058790e305
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 offering runtime services for applications built on top of it. Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the restore template to perform a XSS, e.g. by using URL such as: > /xwiki/bin/view/XWiki/Main?xpage=restore&showBatch=true&xredirect=javascript:alert(document.domain). This vulnerability exists since XWiki 9.4-rc-1. The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1.
Impact It's possible to perform an XSS by forging a request to a delete attachment action with a specific attachment name. Now this XSS can be exploited only if the attacker knows the CSRF token of the user, or if the user ignores the warning about the missing CSRF token.
Patches
The vulnerability has been patched in XWiki 15.1-rc-1 and XWiki 14.10.6.
Workarounds
There's no workaround for this other than upgrading XWiki.
References
Jira ticket: https://jira.xwiki.org/browse/XWIKI-20339 Commit containing the fix: https://github.com/xwiki/xwiki-platform/commit/35e9073ffec567861e0abeea072bd97921a3decf
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
Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the delete template to perform a XSS, e.g. by using URL such as:
xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=delete.vm&xredirect=javascript:alert(document.domain)
This vulnerability exists since XWiki 6.0-rc-1.
Patches
The vulnerability has been patched in XWiki 14.10.6 and 15.1. Note that a partial patch has been provided in 14.10.5 but wasn't enough to entirely fix the vulnerability.
Workarounds
It's possible to workaround the vulnerability by editing the template delete.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets.
References
Jira ticket about the original vulnerability: https://jira.xwiki.org/browse/XWIKI-20341 Commit containing the first fix in the template: https://github.com/xwiki/xwiki-platform/commit/e80d22d193df364b07bab7925572720f91a8984a Jira ticket about the second part of the vulnerability found after 14.10.5: https://jira.xwiki.org/browse/XWIKI-20672 Commits containing the second fix in the template: https://github.com/xwiki/xwiki-platform/commit/13875a6437d4525ac4aeea25918f2d2dffac9ee1 https://github.com/xwiki/xwiki-platform/commit/24ec12890ac7fa6daec8d0b3435cfcba11362fd5 Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583
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
Attribution
This vulnerability has been reported by René de Sain @renniepak.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). For instance, the following URL execute an alter on the browser: <xwiki-host>/xwiki/bin/view/Main/?viewer=share&send=1&target=&target=%3Cimg+src+onerror%3Dalert%28document.domain%29%3E+%3Cimg+src+onerror%3Dalert%28document.domain%29%3E+%3Crenniepak%40intigriti.me%3E&includeDocument=inline&message=I+wanted+to+share+this+page+with+you., where <xwiki-host> is the URL of your XWiki installation. The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.4, and 14.4.8.