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
44 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact The Document script API returns directly a DocumentAuthors allowing to set any authors to the document, which in consequence can allow subsequent executions of scripts since this author is used for checking rights. Example of such attack: Patches The problem has been patched in XWiki 14.10 and 14.4.7 by returning a safe script API. Workarounds There no easy workaround apart of upgrading. References https://jira.xwiki.org/browse/XWIKI-20380 https://github.com/xwiki/xwiki-platform/commit/905cdd7c421dbf8c565557cdc773ab1aa9028f83 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.10 or 14.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Rights added to a document are not taken into account for viewing it once it's deleted. Note that this vulnerability only impact deleted documents that where containing view rights: the view rights provided on a space of a deleted document are properly checked. Patches The problem has been patched in XWiki 14.10 by checking the rights of current user: only admin and deleter of the document are allowed to view it. Workarounds There is no workaround for this vulnerability other than upgrading. References Jira ticket: https://jira.xwiki.org/browse/XWIKI-16285 Commit: https://github.com/xwiki/xwiki-platform/commit/d9e947559077e947315bf700c5703dfc7dd8a8d7 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.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 It's possible to make the farm unusable by adding an object to a page with a huge number (e.g. 67108863). This will most of the time fill the memory allocated to XWiki and make it unusable every time this document is manipulated. Patches It has been patched in XWiki 14.0 Workarounds There is no workaround. References https://jira.xwiki.org/browse/XWIKI-19223 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 14.0-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 It's possible to use the right of an existing document content author to execute a text area property. To reproduce: As an admin with programming rights, create a new user without script or programming right. Login with the freshly created user. Insert the following text in source mode in the about section: Click "Save & View" Patches This has been patched in XWiki 14.10, 14.4.7, and 13.10.11. Workarounds No known workaround. References https://jira.xwiki.org/browse/XWIKI-20373 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.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 It's possible to make XWiki create many new schemas and fill them with tables just by using a crafted user identifier in the login form. Patches The problem has been patched in XWiki 13.10.8, 14.6RC1 and 14.4.2. Workarounds The only workarounds for this are: use an authenticator which does interpret the login as a reference to a document using a different database than PostgreSQL upgrade XWiki References https://jira.xwiki.org/browse/XWIKI-19886 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.6-rc-1 (pre-release), 14.4.2 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 for a user with only Script rights to enable or disable a user: this operation should be only doable for users with admin rights. Patches This problem has been patched in XWiki 13.10.7, 14.4.2 and 14.5RC1. Workarounds There is no workaround other than upgrading the wiki, but note that this only impacts users with Script rights: administrator should take care which users have such right. References https://jira.xwiki.org/browse/XWIKI-19804 https://github.com/xwiki/xwiki-platform/commit/0b732f2ef0224e2aaf10e2e1ef48dbd3fb6e10cd 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.4.2 or 13.10.7 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 exploit a bug in XWikiRights resolution of groups to obtain privilege escalation. More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right. Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights. Patches The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights. Workarounds It's possible to workaround the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it. References https://jira.xwiki.org/browse/XWIKI-18386 https://jira.xwiki.org/browse/XWIKI-15776 For more information If you have any questions or…
Recommended action: Upgrade to 14.2-rc-1 (pre-release) or 13.10.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service: so a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default: so an inactive users could perform actions for such extensions. This issue exists since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for newer versions (= 11.3RC1) since we provided the capability to disable user without deleting them, and we encouraged using that feature. Patches This issue has been patched in XWiki 14.3RC1 and XWiki 13.10.5. Workarounds There is no workaround for this other than upgrading XWiki. References https://jira.xwiki.org/browse/XWIKI-19559 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.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 All rights checks that would normally prevent a user from viewing a document on a wiki can be bypassed using the login action and directly specified templates. This exposes title, content and comments of any document and properties of objects (class and property name must be known, though). This is also exploitable on private wikis. Patches This has been patched in versions 14.2 and 13.10.4 by properly checking view rights before loading documents and disallowing non-default templates in the login, registration and skin action. Workarounds It would be possible to protect all templates individually by adding code to check access rights first, but due to the number of templates and the fact that some of them need to be used without view rights, this seems impractical. References https://jira.xwiki.org/browse/XWIKI-19549 https://jira.xwiki.org/browse/XWIKI-18602 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki.org Email…
Recommended action: Upgrade to 14.2 or 13.10.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact One can ask for any file located in the classloader using the template API and a path with ".." in it. For example To our knownledge none of the available files of the classloader in XWiki Standard contain any strong confidential data, hence the low confidentiality value of this advisory. Patches The issue is patched in versions 14.0 and 13.10.3. Workarounds There's no easy workaround for this issue, administrators should upgrade their wiki. References https://jira.xwiki.org/browse/XWIKI-19349 https://github.com/xwiki/xwiki-platform/commit/4917c8f355717bb636d763844528b1fe0f95e8e2 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at security mailing list
Recommended action: Upgrade to 13.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PreviewAction in XWiki 0.9.543 through 0.9.1252 does not set the Author field to the identity of the user who last modified a document, which allows remote authenticated users without programming rights to execute arbitrary code by selecting a document whose author has programming rights, modifying this document to contain a script, and previewing without saving the document.
Recommended action: Upgrade to 1.0B1 (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 When using default XWiki configuration, it's possible for an attacker to upload an SVG containing a script executed when executing the download action on the file. Patches This problem has been patched so that the default configuration doesn't allow to display the SVG files in the browser. Workarounds This issue can be fixed without the patch by setting properly the configuration to download or display files, see: https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentdisplayordownload References https://jira.xwiki.org/browse/XWIKI-18368 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 13.3RC1 (pre-release) or 12.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 Any user with SCRIPT right (EDIT right before XWiki 7.4) can read any file located in the XWiki WAR (for example xwiki.cfg and xwiki.properties) through XWiki#invokeServletAndReturnAsString: Patches It has been patched in XWiki versions 12.10.9, 13.4.3 and 13.7-rc-1. Workarounds The only workaround is to give SCRIPT right only to trusted users. References https://jira.xwiki.org/browse/XWIKI-18870 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.7-rc-1 (pre-release), 13.4.3 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 There's no protection against URL redirection to untrusted site, in particular some well known parameters (xredirect) can be used to perform such redirections. Patches The problem has been patched in XWiki 12.10.7 and XWiki 13.3RC1. Workarounds There's no known workaround for this issue. References https://jira.xwiki.org/browse/XWIKI-10309 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 13.3RC1 (pre-release) or 12.10.7 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 copy the content of a page it does not have access to by using it as template of a new page. Patches It has been patched in XWiki 13.2CR1 and 12.10.6 Workarounds There is no workaround beside patching. References https://jira.xwiki.org/browse/XWIKI-18430 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.2-rc-1 (pre-release) or 12.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.
XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with SCRIPT right (EDIT right before XWiki 7.4) can save a document with the right of the current user which allow accessing API requiring programming right if the current user has programming right. It has been patched in XWiki 13.0. The only workaround is to give SCRIPT right only to trusted users.
Recommended action: Upgrade to 13.0 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.
Impact Any user with SCRIPT right (EDIT right before XWiki 7.4) can gain access to the application server Servlet context which contains tools allowing to instantiate arbitrary Java objects and invoke methods that may lead to arbitrary code execution. Patches It has been patched in both version XWiki 12.5 and XWiki 11.10.6. Workarounds The only workaround is to give SCRIPT right only to trusted users. References https://jira.xwiki.org/browse/XWIKI-17423 It's been reported by the GitHub Security Lab under https://jira.xwiki.org/browse/XWIKI-17141. 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 12.5 or 11.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 Any user with SCRIPT right (EDIT right before XWiki 7.4) can gain access to the application server Servlet context which contains tools allowing to instantiate arbitrary Java objects and invoke methods that may lead to arbitrary code execution. Patches It has been patched in both version XWiki 12.2.1 and XWiki 11.10.5. Workarounds The only workaround is to give SCRIPT right only to trusted users. References https://jira.xwiki.org/browse/XWIKI-17141 https://jira.xwiki.org/browse/XWIKI-17266 It's been reported by the GitHub Security Lab under #GHSL-2020-046. 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 12.2.1 or 11.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.