#maven

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the resubmit template to perform a XSS, e.g. by using URL such as: > xwiki/bin/view/XWiki/Main?xpage=resubmit&resubmit=javascript:alert(document.domain)&xback=javascript:alert(document.domain) This vulnerability exists since XWiki 2.5-milestone-2. ### Patches The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1. ### Workarounds It's possible to workaround the vulnerability by editing the template resubmit.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets. ### References * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20343 * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583 * Commit containing the actual fix in the page: https://github.co...

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the deletespace template to perform a XSS, e.g. by using URL such as: > xwiki/bin/deletespace/Sandbox/?xredirect=javascript:alert(document.domain) This vulnerability exists since XWiki 3.4-milestone-1. ### Patches The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1. ### Workarounds It's possible to workaround the vulnerability by editing the template deletespace.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets. ### References * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20612 * Introduction of the macro used for fixing all those vulnerabilities: https://jira.xwiki.org/browse/XWIKI-20583 * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/5c20ff5e3bd...

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the restore template to perform a XSS, e.g. by using URL such as: > /xwiki/bin/view/XWiki/Main?xpage=restore&showBatch=true&xredirect=javascript:alert(document.domain) This vulnerability exists since XWiki 9.4-rc-1. ### Patches The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1. ### Workarounds It's possible to workaround the vulnerability by editing the template restore.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets. ### References * Vulnerability in restore template: https://jira.xwiki.org/browse/XWIKI-20352 * Introduction of the macro used for fixing this vulnerability: https://jira.xwiki.org/browse/XWIKI-20583 * Commit containing the actual fix in the template: https://github.com/xwiki/xwiki-platform/commit/d5472100...

### Impact It's possible to perform an XSS by forging a request to a delete attachment action with a specific attachment name. Now this XSS can be exploited only if the attacker knows the CSRF token of the user, or if the user ignores the warning about the missing CSRF token. ### Patches The vulnerability has been patched in XWiki 15.1-rc-1 and XWiki 14.10.6. ### Workarounds There's no workaround for this other than upgrading XWiki. ### References * Jira ticket: https://jira.xwiki.org/browse/XWIKI-20339 * Commit containing the fix: https://github.com/xwiki/xwiki-platform/commit/35e9073ffec567861e0abeea072bd97921a3decf ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:[email protected])

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the delete template to perform a XSS, e.g. by using URL such as: > xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=delete.vm&xredirect=javascript:alert(document.domain) This vulnerability exists since XWiki 6.0-rc-1. ### Patches The vulnerability has been patched in XWiki 14.10.6 and 15.1. Note that a partial patch has been provided in 14.10.5 but wasn't enough to entirely fix the vulnerability. ### Workarounds It's possible to workaround the vulnerability by editing the template delete.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets. ### References * Jira ticket about the original vulnerability: https://jira.xwiki.org/browse/XWIKI-20341 * Commit containing the first fix in the template: https://github.com/xwiki/xwiki-platform/comm...

## Summary The fork of `org.cyberneko.html` used by Nokogiri (Rubygem) raises a `java.lang.OutOfMemoryError` exception when parsing ill-formed HTML markup. ## Severity The maintainers have evaluated this as [**High Severity** 7.5 (CVSS3.1)](https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). ## Mitigation Upgrade to `>= 1.9.22.noko2`. ## Credit This vulnerability was reported by [이형관 (windshock)](https://www.linkedin.com/in/windshock/). ## References [CWE-400](https://cwe.mitre.org/data/definitions/400.html) Uncontrolled Resource Consumption ## Notes The upstream library `org.cyberneko.html` is no longer maintained. Nokogiri uses its own fork of this library located at https://github.com/sparklemotion/nekohtml and this CVE applies only to that fork. Other forks of nekohtml may have a similar vulnerability.

Broadleaf 5.x and 6.x (including 5.2.25-GA and 6.2.6-GA) was discovered to contain a cross-site scripting (XSS) vulnerability via a customer signup with a crafted email address. This is fixed in 6.2.6.1-GA.

### Impact It's possible to execute any wiki content with the right of the TipsPanel author by creating a tip UI extension. To reproduce: * Add an object of type UIExtensionClass * Set "Extension Point ID" to org.xwiki.platform.help.tipsPanel * Set "Extension ID" to org.xwiki.platform.user.test (needs to be unique but otherwise doesn't matter) * Set "Extension Parameters" to ``` tip={{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} ``` * Set "Extension Scope" to "Current User". * Click "Save & View" * Open the "Help.TipsPanel" document at <xwiki-host>/xwiki/bin/view/Help/TipsPanel where <xwiki-host> is the URL of your XWiki installation and press refresh repeatedly. The groovy macro is executed, after the fix you get an error instead. ### Patches This has been patched in XWiki 15.1-rc-1 and 14.10.5. ### Workarounds There are no known workarounds for it. ### References * https://jira.xwiki....

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). It's possible to exploit the previewactions template to perform a XSS, e.g. by using URL such as: > <hostname>/xwiki/bin/get/FlamingoThemes/Cerulean?xpage=xpart&vm=previewactions.vm&xcontinue=javascript:alert(document.domain) This vulnerability exists since XWiki 6.1-rc-1. ### Patches The vulnerability has been patched in XWiki 14.10.5 and 15.1-rc-1. ### Workarounds It's possible to workaround the vulnerability by editing the template previewactions.vm to perform checks on it, but note that the appropriate fix involves new APIs that have been recently introduced in XWiki. See the referenced jira tickets. ### References * Jira ticket about the vulnerability: https://jira.xwiki.org/browse/XWIKI-20342 * Introduction of the macro used for fixing this type of vulnerability: https://jira.xwiki.org/browse/XWIKI-20583 * Commit containing the actual fix in the template: http...

### Impact A stored XSS can be exploited by users with edit rights by adding a `AppWithinMinutes.FormFieldCategoryClass` class on a page and setting the payload on the page title. Then, any user visiting `/xwiki/bin/view/AppWithinMinutes/ClassEditSheet` executes the payload. See https://jira.xwiki.org/browse/XWIKI-20365 for me details. ### Patches The issue has been patched on XWiki 14.4.8, 14.10.4, and 15.0 ? ### Workarounds The issue can be fixed by updating `AppWithinMinutes.ClassEditSheet` with this [patch](https://github.com/xwiki/xwiki-platform/commit/1b87fec1e5b5ec00b7a8c3c3f94f6c5e22547392#diff-79e725ec7125cced7d302e1a1f955a76745af26ef28a148981b810e85335d302). ### References - https://github.com/xwiki/xwiki-platform/commit/1b87fec1e5b5ec00b7a8c3c3f94f6c5e22547392#diff-79e725ec7125cced7d302e1a1f955a76745af26ef28a148981b810e85335d302 - https://jira.xwiki.org/browse/XWIKI-20365 ### For more information If you have any questions or comments about this advisory: * Open an ...