Where
AND
AND
-Infinity
0

Vendor Risk Score

See how xwiki compares to other vendors in security performance

View Risk Score →
Severity
9.8
SQL Injection
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Impact

It's possible for anyone to inject SQL using the parameter sort of the getdeleteddocuments.vm. It's injected as is as an ORDER BY value.

One can see the result of the injection with http://127.0.0.1:8080/xwiki/rest/liveData/sources/liveTable/entries?sourceParams.template=getdeleteddocuments.vm&sort=injected (this example does not work, but it shows that an HQL query was executed with the passed value which look nothing like an order by value, without any kind of sanitation).

Patches

This has been patched in 17.3.0-rc-1, 16.10.6.

Workarounds

There is no known workaround, other than upgrading XWiki.

References

https://jira.xwiki.org/browse/XWIKI-23093

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

Attribution

The vulnerability was identifier by Aleksey Solovev from Positive Technologies.

1 / 2
Source: GitHub
First published (updated )
Severity
9.8
EPSS
0.06%
Code Injection
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Impact Any guest can perform arbitrary remote code execution through a request to SolrSearch. This impacts the confidentiality, integrity and availability of the whole XWiki installation.

To reproduce on an instance, without being logged in, go to <host>/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28"Hello%20from"%20%2B%20"%20search%20text%3A"%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If there is an output, and the title of the RSS feed contains Hello from search text:42, then the instance is vulnerable.

Patches This vulnerability has been patched in XWiki 15.10.11, 16.4.1 and 16.5.0RC1.

Workarounds This line in Main.SolrSearchMacros can be edited to match the rawResponse macro defined here with a content type of application/xml, instead of simply outputting the content of the feed.

References

https://jira.xwiki.org/browse/XWIKI-22149 https://github.com/xwiki/xwiki-platform/commit/67021db9b8ed26c2236a653269302a86bf01ef40

Attribution This vulnerability has been reported by John Kwak for Trend Micro's Zero Day Initiative.

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

Impact

By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation.

To reproduce on a XWiki instance, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to <script>alert('XSS')</script>. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable.

Patches

This has been patched in XWiki 15.10.8 and 16.3.0RC1.

Workarounds

We're not aware of any workaround except upgrading.

References

https://jira.xwiki.org/browse/XWIKI-21626 https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc1cd9f

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
Source: GitHub
First published (updated )
Severity
9.6
CSRF
AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Impact A cross site request forgery vulnerability in the admin tool for executing shell commands on the server allows an attacker to execute arbitrary shell commands by tricking an admin into loading the URL with the shell command. A very simple possibility for an attack are comments. When the attacker can leave a comment on any page in the wiki it is sufficient to include an image with an URL like /xwiki/bin/view/Admin/RunShellCommand?command=touch%20/tmp/attacked in the comment. When an admin views the comment, the file /tmp/attacked will be created on the server. The output of the command is also vulnerable to XWiki syntax injection which offers a simple way to execute Groovy in the context of the XWiki installation and thus an even easier way to compromise the integrity and confidentiality of the whole XWiki installation.

Patches This has been patched by adding a form token check in version 4.5.1 of the admin tools.

Workarounds The patch can be applied manually to the affected wiki pages. Alternatively, the document Admin.RunShellCommand can also be deleted if the possibility to run shell commands isn't needed.

References https://jira.xwiki.org/browse/ADMINTOOL-91 https://github.com/xwiki-contrib/application-admintools/commit/03815c505c9f37006a0c56495e862dc549a39da8

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