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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 17.3.0-rc-1 (pre-release) or 16.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 In getdocument.vm ; the ordering of the returned documents is defined from an unsanitized request parameter (request.sort) and can allow any user to inject HQL. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. It's possible to employ database backend dependent techniques of breaking out of HQL query context, described, for example, here: https://www.sonarsource.com/blog/exploiting-hibernate-injections. Patches This has been patched in 13.10.5 and 14.3-rc-1. Workarounds There is no known workaround, other than upgrading XWiki. References https://jira.xwiki.org/browse/XWIKI-17568 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 A user able to attach a file to a page can post a malformed TAR file by manipulating file modification times headers, which when parsed by Tika, could cause a denial of service issue via CPU consumption. Patches This vulnerability has been patched in XWiki 14.10.18, 15.5.3 and 15.8 RC1. Workarounds The workaround is to download commons-compress 1.24 and replace the one located in XWiki WEB-INF/lib/ folder. References https://jira.xwiki.org/browse/XCOMMONS-2796 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 15.8-rc-1 (pre-release), 15.5.3 or 14.10.18 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 execute javascript with the right of any user by leading him to a special URL on the wiki targeting a page which contains an attachment. To reproduce: add an attachment to a page (for example, your user profile) add ?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E to the page view URL as in https://myhost/xwiki/bin/view/XWiki/MyUser?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E Patches This has been patched in XWiki 15.0-rc-1, 14.10.4 and 14.4.8. Workarounds The easiest is to edit file <xwiki app/templates/importinline.vm and apply the modification described on https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01 References https://jira.xwiki.org/browse/XWIKI-20340 https://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK Attribution This vulnerability has been reported on Intigriti by René de Sain @renniepak.
Recommended action: Upgrade to 14.10.4 or 14.4.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 Steps to reproduce: Open <xwiki-host/xwiki/bin/view/XWiki/Notifications/Code/LegacyNotificationAdministration?since=%7B%7B%2Fhtml%7D%7D+%7B%7Basync+async%3D%22true%22+cached%3D%22false%22+context%3D%22doc.reference%22%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello+%22+%2B+%22from+groovy%21%22%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D, where <xwiki-host is the URL of your XWiki installation. This demonstrates an XWiki syntax injection attack via the since-parameter, allowing privilege escalation from view to programming rights. Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.3, 14.4.8 and 14.10.3. Workarounds For versions = 14.6-rc-1 the workaround is to modify the page XWiki.Notifications.Code.LegacyNotificationAdministration to add the missing escaping, as described on https://github.com/xwiki/xwiki-platform/commit/8e7c7f90f2ddaf067cb5b83b181af41513028754#diff-4e13f4ee4a42938bf1201b7ee71ca32edeacba22559daf0bcb89d534e0225949R70 For versions < 14.6-rc-1 the…
Recommended action: Upgrade to 14.6-rc-1 (pre-release), 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.