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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 15.2-rc-1 (pre-release) or 14.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 The HTML sanitizer, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid data attributes. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki: When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Note that this vulnerability does not affect restricted cleaning in HTMLCleaner as there attributes are cleaned and thus characters like / and are removed in all attribute names. Patches This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by making sure that data attributes only contain allowed characters. Workarounds There are no known workarounds apart from upgrading to a…
Recommended action: Upgrade to 14.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 The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1 and massively improved in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid HTML comments. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). An example are anonymous comments in XWiki where the HTML macro filters HTML using restricted mode: When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Note that while all versions since 4.2-milestone-1 should be vulnerable, only starting with version 14.6-rc-1 the HTML comment is necessary for the attack to succeed due to another vulnerability that has been…
Recommended action: Upgrade to 14.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1, only escaped <script and <style-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like <iframe. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). An example are anonymous comments in XWiki where the HTML macro filters HTML using restricted mode: When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Patches This problem has been patched in XWiki 14.6 RC1 with the introduction of a filter with allowed HTML elements and attributes that is enabled in restricted mode. Workarounds There are no known workarounds apart…
Recommended action: Upgrade to 14.6-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 can edit his own profile and inject code which is going to be executed with programming right. Steps to reproduce: Set your first name to The first name appears as interpreted "Hello from groovy" instead of the expected fully escaped "{{cache id="userProfile"}}{{groovy}}println("Hello from groovy!"){{/groovy}}{{/cache}}". The same vulnerability can also be exploited in all other places where short text properties are displayed, e.g., in apps created using Apps Within Minutes that use a short text field. Patches The problem has been patched on versions 13.10.9, 14.4.4, 14.7RC1. Workarounds There are no other workarounds than upgrading XWiki or patching the xwiki-commons-xml JAR file. References https://jira.xwiki.org/browse/XWIKI-19793 https://jira.xwiki.org/browse/XWIKI-19794 https://jira.xwiki.org/browse/XCOMMONS-2498 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.7-rc-1 (pre-release), 14.4.4 or 13.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 It's possible in a script to access any file accessing to the user running XWiki application server with XML External Entity Injection through the XML script service. For example: Patches The problem has been patched on versions 12.10.10, 13.4.4 and 13.8RC1. Workarounds There's no easy workaround for fixing this vulnerability other than upgrading and being careful when giving Script rights. References https://jira.xwiki.org/browse/XWIKI-18946 For more information If you have any questions or comments about this advisory: Open an issue in Jira XWiki Email us at XWiki Security mailing-list
Recommended action: Upgrade to 13.8-rc-1 (pre-release), 13.4.4 or 12.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.