Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
23 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A reflected cross-site scripting vulnerability (XSS) in the compare view between revisions of a page allows executing JavaScript code in the user's browser. If the current user is an admin, this can not only affect the current user but also the confidentiality, integrity and availability of the whole XWiki instance. Patches The problem has been patched by properly escaping the URL parameters. Workarounds The patch can be applied manually to templates/changesdoc.vm in the deployed WAR. Attribution XWiki thanks Mike Cole @mikecole-mg for discovering and reporting this vulnerability.
Recommended action: Upgrade to 17.10.1, 17.4.8 or 16.10.16 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A reflected cross site scripting (XSS) vulnerability in XWiki allows an attacker to execute arbitrary actions in XWiki with the rights of the victim if the attacker manages to trick a victim into visiting a crafted URL. If the victim has administrative or programming rights, those rights can be exploited to gain full access to the XWiki installation. Patches This vulnerability has been patched in XWiki 17.8.0RC1, 17.4.5 and 16.10.12. Workarounds The patch can be applied manually, only a single line in templates/loggingmacros.vm needs to be changed, no restart is required. References https://github.com/xwiki/xwiki-platform/commit/8337ac8c3b19c37f306723b638b2cae8b0a57dbf https://jira.xwiki.org/browse/XWIKI-23462 Attribution We thank Mike Cole @mikecole-mg for discovering and reporting this vulnerability.
Recommended action: Upgrade to 17.8.0-rc-1 (pre-release), 17.4.5 or 16.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A reflected XSS vulnerability in XWiki allows an attacker to send a victim to a URL with a deletion confirmation message on which the attacker-supplied script is executed when the victim clicks the "No" button. When the victim has admin or programming right, this allows the attacker to execute basically arbitrary actions on the XWiki installation including remote code execution. Patches This vulnerability has been patched in XWiki 16.10.10, 17.4.2 and 17.5.0 by using the affected URL parameter only in the intended context. Workarounds The patch can be manually applied to the templates that are present in the WAR. A restart of XWiki is needed for the changes to be applied.
Recommended action: Upgrade to 17.4.2 or 16.10.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Reflected XSS vulnerabilities in two templates allow an attacker to execute malicious JavaScript code in the context of the victim's session by getting the victim to visit an attacker-controlled URL. PoC URLs are /xwiki/bin/view/Main/?xpage=jobstatusjson&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. This allows the attacker to perform arbitrary actions using the permissions of the victim. Patches The problem has been patched in XWiki 16.4.8, 16.10.6 and 17.3.0RC1 by adding escaping in the affected templates. Workarounds The affected templates can be patched manually in the WAR by applying the same changes as in the patch. Attribution The vulnerability involving jobstatusjson has been reported as "Unauth Reflected XSS" vulnerability by Aleksey Solovev (Positive Technologies),…
Recommended action: Upgrade to 17.3.0-rc-1 (pre-release), 16.10.6 or 16.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A user without script/programming right can trick a user with elevated rights to edit a 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. Patches This vulnerability has been patched in XWiki 15.10RC1. Workarounds No workaround. It is advised to upgrade to XWiki 15.10+. References https://jira.xwiki.org/browse/XWIKI-20331 https://jira.xwiki.org/browse/XWIKI-21311 https://jira.xwiki.org/browse/XWIKI-21481 https://jira.xwiki.org/browse/XWIKI-21482 https://jira.xwiki.org/browse/XWIKI-21483 https://jira.xwiki.org/browse/XWIKI-21484 https://jira.xwiki.org/browse/XWIKI-21485 https://jira.xwiki.org/browse/XWIKI-21486 https://jira.xwiki.org/browse/XWIKI-21487 https://jira.xwiki.org/browse/XWIKI-21488 https://jira.xwiki.org/browse/XWIKI-21489 https://jira.xwiki.org/browse/XWIKI-21490 For more information If you have any questions or…
Recommended action: Upgrade to 15.10-rc-1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on a XWiki instance, 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 <scriptalert('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. Patches This has been patched in XWiki 15.10.8 and 16.3.0RC1. Workarounds We're not aware of any workaround except upgrading. References https://jira.xwiki.org/browse/XWIKI-21626 https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc1cd9f For more information If…
Recommended action: Upgrade to 16.3.0-rc-1 (pre-release) or 15.10.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When trying to create a document that already exists, XWiki displays an error message in the form for creating it. Due to missing escaping, this error message is vulnerable to raw HTML injection and thus XSS. The injected code is the document reference of the existing document so this requires that the attacker first creates a non-empty document whose name contains the attack code. To reproduce, the following steps can be used: 1. Go to <xwiki-host/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22 where <xwiki-host is the URL of your XWiki installation. 2. Create the page and add some content. 3. Go again to <xwiki-host/xwiki/bin/create/Main/WebHome?parent=&templateprovider=&spaceReference=&name=%3Cimg%20onerror=%22alert(1)%22%20src=%22test%22 where <xwiki-host is the URL of your XWiki installation. If an alert with content "1" is displayed, the installation is vulnerable. This allows an attacker to…
Recommended action: Upgrade to 15.5-rc-1 (pre-release) or 14.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When document names are validated according to a name strategy (disabled by default), XWiki is vulnerable to a reflected XSS attack in the page creation form. To reproduce, make sure that "Validate names before saving" is enabled in the administration under "Editing" - "Name strategies" and then open <xwiki-host/xwiki/bin/create/Main/%3Cscript%3Ealert%28%27Test%20Test%20Test%20Test%20Test%27%29%3C%2Fscript%3E where <xwiki-host is the URL of your XWiki installation. This displays an alert if the installation is vulnerable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation. Patches This has been patched in XWiki 14.10.12 and 15.5-RC-1 by adding appropriate escaping. Workarounds The vulnerable template file createinline.vm is part of XWiki's WAR and can be patched by manually applying…
Recommended action: Upgrade to 15.5-rc-1 (pre-release) or 14.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In XWiki, it is possible to pass a title to the page creation action that isn't displayed at first but then executed in the second step. This can be used by an attacker to trick a victim to execute code, allowing script execution if the victim has script right or remote code execution including full access to the XWiki instance if the victim has programming right. For the attack to work, the attacker needs to convince the victim to visit a link like <xwiki-host/xwiki/bin/create/NonExistingSpace/WebHome?title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22) where <xwiki-host is the URL of the Wiki installation and to then click on the "Create" button on that page. The page looks like a regular XWiki page that the victim would also see when clicking the button to create a page that doesn't exist yet, the malicious code is not displayed anywhere on that page. After clicking the "Create" button, the malicious title would be displayed but at this point, the…
Recommended action: Upgrade to 15.5-rc-1 (pre-release) or 14.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can create a template provider on any document that is part of the wiki (could be the attacker's user profile) that contains malicious code. This code is executed when this template provider is selected during document creation which can be triggered by sending the user to a URL. For the attacker, the only requirement is to have an account as by default the own user profile is editable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation. For reproduction, the following steps can be used: 1. As a simple user with no script right, edit the user profile with the object editor and add an object of type "Template Provider Class". Set the name to "My Template", set template to any page on the wiki. In "Creation Restrictions", enter <img onerror="alert(1)"…
Recommended action: Upgrade to 15.5-rc-1 (pre-release) or 14.10.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any registered user can exploit a stored XSS through their user profile by setting the payload as the value of the time zone user preference. Even though the time zone is selected from a drop down (no free text value) it can still be set from JavaScript (using the browser developer tools) or by calling the save URL on the user profile with the right query string. Once the time zone is set it is displayed without escaping which means the payload gets executed for any user that visits the malicious user profile, allowing the attacker to steal information and even gain more access rights (escalation to programming rights). The problem is present since version 4.1M2 when the time zone user preference was introduced. Patches The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/d11ca5d781f8a42a85bc98eb82306c1431e764d4 . The main fix is in the displayertimezone.vm precisely at this line: $!escapetool.xml($value) By escaping the…
Recommended action: Upgrade to 14.10.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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:…
Recommended action: Upgrade to 15.1-rc-1 (pre-release) or 14.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 15.1-rc-1 (pre-release) or 14.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any user who can edit a document in a wiki like the user profile can create a stored XSS attack by putting plain HTML code into that document and then tricking another user to visit that document with the displaycontent or rendercontent template and plain output syntax. For example, edit any document with the wiki editor and set the content to <scriptalert(1)</script , save and then append the parameters ?viewer=displaycontent&sheet=&outputSyntax=plain. If this displays an alert, the installation is vulnerable. If a user with programming rights is tricked into visiting such a URL, arbitrary actions be performed with this user's rights, impacting the confidentiality, integrity, and availability of the whole XWiki installation. Patches This has been patched in XWiki 14.4.8, 14.10.5 and 15.1RC1 by setting the content type of the response to plain text when the output syntax is not an HTML syntax. Workarounds The patch can be manually applied to the rendercontent.vm template in an…
Recommended action: Upgrade to 15.1-rc-1 (pre-release), 14.10.5 or 14.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If a guest has view rights on any document, it's possible to create a new user using the distribution/firstadminuser.wiki in the wrong context. To reproduce: On a wiki with view rights for guests but user registration disabled, open as guest <server/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%2F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7Btemplate+name%3D%22distribution%2Ffirstadminuser.wiki%22+%2F%7D%7D where <server is the URL of your XWiki installation. Enter username and password of your choice. Click "Register and login" Patches The vulnerability has been patched in XWiki 15.0-rc-1 and 14.10.1. Workarounds There is no known workaround other than upgrading. References https://jira.xwiki.org/browse/XWIKI-19852 https://jira.xwiki.org/browse/XWIKI-20400 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
Recommended action: Upgrade to 14.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Any user with edit rights on a page (e.g., it's own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the information loaded from attachments in imported.vm, importinline.vm, and packagelist.vm. This page is installed by default. Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20267 Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. Workarounds The issue can be fixed by applying this patch on imported.vm, importinline.vm, and packagelist.vm. References - https://github.com/xwiki/xwiki-platform/commit/e4bbdc23fea0be4ef1921d1a58648028ce753344 - https://jira.xwiki.org/browse/XWIKI-20267 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
Recommended action: Upgrade to 14.10.1, 14.4.8 or 13.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Livetable Macro wasn't properly sanitizing column names, thus allowing the insertion of raw HTML code including JavaScript. This vulnerability was also exploitable via the Documents Macro that is included since XWiki 3.5M1 and doesn't require script rights, this can be demonstrated with the syntax {{documents id="example" count="5" actions="false" columns="doc.title, before<scriptalert(1)</scriptafter"/}}. Therefore, this can also be exploited by users without script right and in comments. With the interaction of a user with more rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content. Patches This has been patched in XWiki 14.9, 14.4.6, and 13.10.10. Workarounds It is possible to apply the patch to existing installations without upgrading. Only the files skins/flamingo/macros.vm and templates/macros.vm in the web application directory need to be…
Recommended action: Upgrade to 14.9, 14.4.6 or 13.10.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's possible to list some users who are normally not viewable from subwiki by requesting users on a subwiki which allows only global users with uorgsuggest.vm. This issue only concerns hidden users from main wiki. Note that the disclosed information are the username and the first and last name of users, no other information is leaked. Patches The problem has been patched on XWiki 13.10.8, 14.4.3 and 14.7RC1. Workarounds It's possible to workaround this vulnerability by patching directly uorgsuggest.vm to apply the same changes as in https://github.com/xwiki/xwiki-platform/pull/1883. References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20007 this vulnerability is actually a remaining of https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-97jg-43c9-q6pf which wasn't entirely fixed back then For more information If you have any questions or comments about this advisory: Open an issue in Jira Email us at security ML
Recommended action: Upgrade to 14.7-rc-1 (pre-release), 14.4.3 or 13.10.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It's possible to perform a CSRF attack for adding or removing tags on XWiki pages. Patches The problem has been patched in XWiki 13.10.5 and 14.3. Workarounds It's possible to fix the issue without upgrading by locally modifying the documentTags.vm template in your filesystem, to apply the changes exposed there: https://github.com/xwiki/xwiki-platform/commit/7ca56e40cf79a468cea54d3480b6b403f259f9ae. References https://jira.xwiki.org/browse/XWIKI-19550 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at security ML
Recommended action: Upgrade to 14.3 or 13.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on private wikis at least for string properties. Patches The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. Workarounds The template file suggest.vm can be replaced by a patched version without upgrading or restarting XWiki unless it has been overridden, in which case the overridden template should be patched, too. This might need adjustments for older versions, though. References https://jira.xwiki.org/browse/XWIKI-18849 For more…
Recommended action: Upgrade to 13.10.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact By passing a template of the distribution wizard to the xpart template, user accounts can be created even when user registration is disabled. This also circumvents any email verification. Before versions 14.2 and 13.10.4, this can also be exploited on a private wiki, thus potentially giving the attacker access to the wiki. Depending on the configured default rights of users, this could also give attackers write access to an otherwise read-only public wiki. Users can also be created when an external authentication system like LDAP is configured, but authentication fails unless the authentication system supports a bypass/local accounts are enabled in addition to the external authentication system. Patches This issue has been patched in XWiki 13.10.5 and 14.3RC1. Workarounds It is possible to replace xpart.vm, the entry point for this attack, by a patched version from the patch without updating XWiki. References https://jira.xwiki.org/browse/XWIKI-19558 For more information If…
Recommended action: Upgrade to 14.3-rc-1 (pre-release) or 13.10.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A guest user without the right to view pages of the wiki can still list documents related to users of the wiki. The problem has been patched in XWiki versions 12.10.11, 13.4.4, and 13.9-rc-1. There is no known workaround for this problem.
Recommended action: Upgrade to 13.9, 13.4.4 or 12.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact We found a possible XSS vector in the registerinline.vm template related to the xredirect hidden field. This template is only used in the following conditions: - the wiki must be open to registration for anyone - the wiki must be closed to view for Guest users (more specifically the XWiki.Registration page must be forbidden in View for guest user) A way to obtain the second condition is when administrators checked the "Prevent unregistered users from viewing pages, regardless of the page rights" box in the administration rights. Patches The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3. Workarounds There are two main ways for protecting against this vulnerability, the easiest and the best one is by applying a patch in the registerinline.vm template, the patch consists in checking the value of the xredirect field to ensure it matches the following: If for some reason it's not possible to patch this file, another workaround is to ensure "Prevent unregistered…
Recommended action: Upgrade to 13.10.3, 13.4.7 or 12.10.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.