Where
AND
-Infinity
0
Severity
6.4
Code Injection
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N

Impact When uploading an attachment with a malicious filename, malicious JavaScript code could be executed. This requires a social engineering attack to get the victim into uploading a file with a malicious name. The malicious code is solely executed during the upload and affects only the user uploading the attachment. While this allows performing actions in the name of that user, it seems unlikely that a user wouldn't notice the malicious filename while uploading the attachment.

In order to reproduce, as any user, create a file named "><img src=1 onerror=alert(1)>.jpg. Then go to any page where you have edit rights and upload the file in the attachments tab. If alerts appear and display "1", then the instance is vulnerable.

Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0.

Workarounds We're not aware of any workaround except upgrading.

References https://jira.xwiki.org/browse/XWIKI-19611 https://jira.xwiki.org/browse/XWIKI-21769 https://jira.xwiki.org/browse/XWIKI-19602 https://github.com/xwiki/xwiki-platform/commit/910a5018a50039e8b24556573dfe342f143ef949

Attribution

This vulnerability has been independently reported by Aleksey Solovev (Positive Technologies) and Georgios Roumeliotis for TwelveSec.

1 / 2
Source: GitHub
First published (updated )
Severity
9
XSS
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

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:

html {{html}} <!--> <Details Open OnToggle=confirm("XSS")> {{/html}}

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 patched in version 14.6-rc-1.

Patches This problem has been patched in XWiki 14.10, HTML comments are now removed in restricted mode and a check has been introduced that ensures that comments don't start with >.

Workarounds There are no known workarounds apart from upgrading to a version including the fix.

References https://jira.xwiki.org/browse/XCOMMONS-2568 https://jira.xwiki.org/browse/XWIKI-20348 https://github.com/xwiki/xwiki-commons/commit/8ff1a9d7e5d7b45b690134a537d53dc05cae04ab

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

Attribution

This vulnerability was reported on Intigriti by ynoof @Ynoof5.

1 / 2
First published (updated )
Severity
9
CSRF
AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

Impact

Steps to reproduce:

It is possible to trick a user with programming rights into visiting <xwiki-host>/xwiki/bin/view/XWiki/LoggingAdmin?loggeractionset=1&loggername=%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dnew+File%28%22%2Ftmp%2Fexploit.txt%22%29.withWriter+%7B+out+-%3E+out.println%28%22created+from+notification+filter+preferences%21%22%29%3B+%7D%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D&loggerlevel=TRACE where <xwiki-host> is the URL of your XWiki installation, e.g., by embedding an image with this URL in a document that is viewed by a user with programming rights.

Expected result:

No file in /tmp/exploit.txt has been created.

Actual result:

The file /tmp/exploit.txt is been created with content "created from notification filter preferences!". This demonstrates a CSRF remote code execution vulnerability that could also be used for privilege escalation or data leaks (if the XWiki installation can reach remote hosts).

Patches The problem has been patched on XWiki 14.4.7, and 14.10.

Workarounds The issue can be fixed manually applying this patch.

References - https://jira.xwiki.org/browse/XWIKI-20291 - https://github.com/xwiki/xwiki-platform/commit/49fdfd633ddfa346c522d2fe71754dc72c9496ca

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

1 / 2
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203