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
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Any user with script rights can perform arbitrary remote code execution by adding instances of XWiki.ConfigurableClass to any page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on a instance, as a user with script rights, edit your user profile and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in category" to other, "Scope" to Wiki and all spaces and "Heading" to: Save the page and view it, then add ?sheet=XWiki.AdminSheet&viewer=content§ion=other to the URL. If the logs contain "attacker - Attack from Heading succeeded!", then the instance is vulnerable. Patches This has been patched in XWiki 15.10.9 and 16.3.0. Workarounds We're not aware of any workaround except upgrading. References https://jira.xwiki.org/browse/XWIKI-21207 https://github.com/xwiki/xwiki-platform/commit/8493435ff9606905a2d913607d6c79862d0c168d For more information If…
Recommended action: Upgrade to 16.3.0 or 15.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 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…
Recommended action: Upgrade to 15.8-rc-1 (pre-release), 15.5.3 or 14.10.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance. The easiest way to reproduce this is to edit any document with the object editor and add an object of type XWiki.ConfigurableClass ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to {{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}. Click "Save". Open <xwiki-host/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin§ion=other where…
Recommended action: Upgrade to 15.7-rc-1 (pre-release), 15.5.2 or 14.10.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, in this case it is much more convenient to exploit GHSA-qj86-p74r-7wp5 which is why this attack scenario won't be further considered in the following. In contrast to GHSA-qj86-p74r-7wp5, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. Alternatively, the URL can also be embedded as image source of an image in any content of the wiki like a comment that could be left by an anonymous user. This vulnerability allows full remote code execution with programming rights and thus impacts the…
Recommended action: Upgrade to 15.7-rc-1 (pre-release), 15.5.2 or 14.10.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact XWiki doesn't properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document XWiki.AdminSheet (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance. By opening the URL <server/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet&viewer=content§ion=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D&xpage=view where <server is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message ERROR attacker - Attack succeeded! to appear in XWiki's log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated with…
Recommended action: Upgrade to 15.5.1 or 14.10.14 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, every user can add translations that are only applied to the current user. This also allows overriding existing translations. Such translations are often included in privileged contexts without any escaping which allows remote code execution for any user who has edit access on at least one document which could be the user's own profile where edit access is enabled by default. The following describes a proof of concept exploit to demonstrate this vulnerability: 1. Edit the user profile with the wiki editor and set the content to 2. Use the object editor to add an object of type XWiki.TranslationDocumentClass with scope USER. 3. Open the document WikiManager.AdminWikiDescriptorSheet. The expected result would be that a message with title {{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("hello from groovy!"){{/groovy}}{{/async}} is displayed while in fact an error that the HTML macro couldn't be executed is displayed, followed by…
Recommended action: Upgrade to 14.10.2 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 section ids in XWiki.AdminFieldsDisplaySheet. This page is installed by default. Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20261 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 XWiki.AdminFieldsDisplaySheet. 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 It's possible to know if a user has or not an account in a wiki related to an email address, and which username(s) is actually tight to that email by forging a request to the Forgot username page. Note that since this page does not have a CSRF check it's quite easy to perform a lot of those requests. Patches This issue has been patched in XWiki 12.10.5 and 13.2RC1. Two different patches are provided: - a first one to fix the CSRF problem - a more complex one that now relies on sending an email for the Forgot username process. Workarounds It's possible to fix the problem without uprading by editing the ForgotUsername page in version below 13.x, to use the following code: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123 In version after 13.x it's also possible to edit manually the forgotusername.vm file, but…
Recommended action: Upgrade to 13.2RC1 (pre-release) or 12.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 for an unprivileged user to perform a remote code execution by injecting a groovy script in her own profile and by calling the Reset password feature since the feature is performing a save of the user profile with programming rights in the impacted versions of XWiki. Patches The problem has been patched in XWiki 13.1RC1 with a complete refactoring of the Reset password feature. Workarounds There's different possible workarounds, all consisting in modifying the XWiki/ResetPassword page. - the Reset password feature can be entirely disabled by deleting the XWiki/ResetPassword page - the script in XWiki/ResetPassword can also be modified or removed: an administrator can replace it with a simple email contact to ask an administrator to reset the password. References https://jira.xwiki.org/browse/XWIKI-16661 For more information If you have any questions or comments about this advisory: Open an issue in Jira Email us at Security mailing-list
Recommended action: Upgrade to 13.1RC1 (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 It's possible for forge an URL that, when accessed by an admin, will reset the password of any user in XWiki. Patches The problem has been patched in XWiki 12.10.5, 13.2RC1. Workarounds It's possible to apply the patch manually by modifying the registermacros.vm template like in https://github.com/xwiki/xwiki-platform/commit/0a36dbcc5421d450366580217a47cc44d32f7257. References https://jira.xwiki.org/browse/XWIKI-18315 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 12.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.