#xss

### Impact Users are able to forge an URL with a payload allowing to inject Javascript in the page (XSS). For instance, the following URL execute an `alter` on the browser: `<xwiki-host>/xwiki/bin/view/Main/?viewer=share&send=1&target=&target=%3Cimg+src+onerror%3Dalert%28document.domain%29%3E+%3Cimg+src+onerror%3Dalert%28document.domain%29%3E+%3Crenniepak%40intigriti.me%3E&includeDocument=inline&message=I+wanted+to+share+this+page+with+you.`, where `<xwiki-host>` is the URL of your XWiki installation. See https://jira.xwiki.org/browse/XWIKI-20370 for me details. ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.4, and 14.4.8. ### Workarounds The fix is only impacting Velocity templates and page contents, so applying this [patch](https://github.com/xwiki/xwiki-platform/commit/ca88ebdefb2c9fa41490959cce9f9e62404799e7) is enough to fix the issue. ### References https://jira.xwiki.org/browse/XWIKI-20370 ### For more information If you have any questions or comm...

### 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 ...

### Impact Any user who can edit a document in a wiki like the user profile can create a stored XSS attack by putting plain HTML code into that document and then tricking another user to visit that document with the `displaycontent` or `rendercontent` template and plain output syntax. For example, edit any document with the wiki editor and set the content to `<script>alert(1)</script>` , save and then append the parameters `?viewer=displaycontent&sheet=&outputSyntax=plain`. If this displays an alert, the installation is vulnerable. If a user with programming rights is tricked into visiting such a URL, arbitrary actions be performed with this user's rights, impacting the confidentiality, integrity, and availability of the whole XWiki installation. ### Patches This has been patched in XWiki 14.4.8, 14.10.5 and 15.1RC1 by setting the content type of the response to plain text when the output syntax is not an HTML syntax. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platfo...

Cross Site Scripting vulnerability in Alluxio v.1.8.1 allows a remote attacker to executea arbitrary code via the path parameter in the browse board component.

Cross Site Scripting vulnerability in khodakhah NodCMS v.3.0 allows an attacker with administrative privileges to execute arbitrary code and gain access to sensitive information via a crafted script to the address parameter.

Cross Site Scripting vulnerability in YiiCMS v.1.2.0 and prior allows a remote attacker to execute arbitrary code via the news function. A fix is available at commit 4a9d68564eb78d9f64e3f5dd77186a154093615b.

Cross Site Scripting vulnerability in taogogo taoCMS v.2.5 beta5.1 allows remote attacker to execute arbitrary code via the name field in admin.php.

Cross Site Scripting vulnerability in EasySoft ZenTao v.11.6.4 allows a remote attacker to execute arbitrary code via the lastComment parameter.

Cross Site Scripting vulnerability found in wkeyuan DWSurvey 1.0 allows a remote attacker to execute arbitrary code via thequltemld parameter of the qu-multi-fillblank!answers.action file.

Cross Site Scripting vulnerability in zrlog zrlog v.2.1.3 allows a remote attacker to execute arbitrary code via the nickame parameter of the /post/addComment function.