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
15 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact It's possible using comments to inject CSS that would transform the full wiki in a link area leading to a malicious page. All versions of XWiki are impacted by this kind of attack. Patches The problem has been patched not by preventing injecting CSS in comments, which is currently a feature of XWiki, but by requiring confirmation from users when driving them to untrusted domains after clicking on a link, thus preventing any click-jacking attack. This security measure has been put in place in XWiki 17.9.0, 17.4.6, 16.10.13. Workarounds There's no out-of-the-box workaround, but it should be possible to partly reuse the javascript code provided for the security measure in a JSX object inside the wiki, to request the same kind of confirmation. References JIRA ticket: https://jira.xwiki.org/browse/XWIKI-23433 Documentation of the new security measure: https://www.xwiki.org/xwiki/bin/view/ReleaseNotes/Data/XWiki/17.9.0RC1/Entry006/ Commit for the security fix:…
Recommended action: Upgrade to 17.9.0, 17.4.6 or 16.10.13 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 13.4-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 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 14.10.12 or later, 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 13.4-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 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 14.4.8 or later, 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 Any user with edit right can execute arbitrary database select and access data stored in the database. To reproduce: In admin, rights, remove scripting rights for {{XWikiAllGroup}}. Create a new user without any special privileges. Create a page "Private.WebHome" with {{TOKEN42}} as content. Go to "page administration" and explicitly set all rights for "Admin" to remove them for all other users. Logout and login as the unprivileged user. Ensure that the previously created page cannot be viewed. Create a new page "ExploitClass.WebHome" and then open it in the class editor (first, make the user an advanced user). Add a field named {{ContentList}} of type {{Database List}} Enter in field "Hibernate Query" the following content: {noformat}select doc.content, doc.fullName from XWikiDocument as doc where doc.fullName = 'Private.WebHome'{noformat} Save the class. Open…
Recommended action: Upgrade to 14.10, 14.4.7 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 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 14.2 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.
Impact It's possible to store a JavaScript which will be executed by anyone viewing the history of an attachment containing javascript in its name. For example, attachment a file with name <img src=1 onerror=alert(1).jpg will execute the alert. Patches This issue has been patched in XWiki 13.10.6 and 14.3RC1. Workarounds It is possible to replace viewattachrev.vm, the entry point for this attack, by a patched version from the patch without updating XWiki. References https://jira.xwiki.org/browse/XWIKI-19612 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.3-rc-1 (pre-release) or 13.10.6 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 guest user without the right to view pages of the wiki can still list documents by rendering some velocity documents. Patches The problem has been patched in XWiki versions 12.10.11, 13.4.4, and 13.9-rc-1. Workarounds There is no known workaround for this problem. References https://jira.xwiki.org/browse/XWIKI-16544 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at our security mailing list
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.
XWiki Platform before 12.8 mishandles escaping in the property displayer.
Recommended action: Upgrade to 12.8 or later, 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 guess if a user has an account on the wiki by using the "Forgot your password" form, even if the wiki is closed to guest users. Patches The problem has been patched on XWiki 12.10.9, 13.4.1 and 13.6RC1. Workarounds There's no easy workaround other than applying the upgrade. References https://jira.xwiki.org/browse/XWIKI-18787 For more information If you have any questions or comments about this advisory: Open an issue in JIRA Email us at XWiki Security Mailing list
Recommended action: Upgrade to 13.4.1, 13.6RC1 (pre-release) or 12.10.9 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 reset password form reveals the email address of users just by giving their username. Patches The problem has been patched on XWiki 13.2RC1. Workarounds It's possible to manually modify the resetpasswordinline.vm to perform the changes made in https://github.com/xwiki/xwiki-platform/commit/0cf716250b3645a5974c80d8336dcdf885749dff#diff-14a3132e3986b1f5606dd13d9d8a8bb8634bec9932123c5e49e9604cfd850fc2 References https://jira.xwiki.org/browse/XWIKI-18400 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 13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact It is possible to persistently inject scripts in XWiki. For unregistred users: - By filling simple text fields For registered users: - By filling their personal information - (if they have edit rights) By filling the values of static lists using App Within Minutes That can lead to user's session hijacking, and if used in conjunction with a social engineering attack it can also lead to disclosure of sensitive data, CSRF attacks and other security vulnerabilities. That can also lead to the attacker taking over an account. If the victim has administrative rights it might even lead to code execution on the server, depending on the application and the privileges of the account. Patches It has been patched on XWiki 12.8 and 12.6.3. Workarounds There is no easy workaround except upgrading XWiki. References https://jira.xwiki.org/browse/XWIKI-17374 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at our security…
Recommended action: Upgrade to 12.8 or 12.6.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.