ghsa

There exists a vulnerability in source code transformer (exception sanitization logic) of vm2 for versions up to 3.9.15, allowing attackers to bypass `handleException()` and leak unsanitized host exceptions which can be used to escape the sandbox and run arbitrary code in host context. ### Impact A threat actor can bypass the sandbox protections to gain remote code execution rights on the host running the sandbox. ### Patches This vulnerability was patched in the release of version `3.9.16` of `vm2`. ### Workarounds None. ### References Github Issue - https://github.com/patriksimek/vm2/issues/516 PoC - https://gist.github.com/leesh3288/f05730165799bf56d70391f3d9ea187c ### For more information If you have any questions or comments about this advisory: - Open an issue in [VM2](https://github.com/patriksimek/vm2) Thanks to [Xion](https://twitter.com/0x10n) (SeungHyun Lee) of [KAIST Hacking Lab](https://kaist-hacking.github.io/) for disclosing this vulnerability.

### Impact On a node controlled by an attacker or malicious user, the lax permissions configured on `open-feature-operator-controller-manager` can be used to further escalate the privileges of any service account in the cluster. The increased privileges could be used to modify cluster state, leading to DoS, or read sensitive data, including secrets. ### Patches The patch mitigates this issue by restricting the resources the `open-feature-operator-controller-manager` can modify.

### Impact It's possible to list some users who are normally not viewable from subwiki by requesting users on a subwiki which allows only global users with `uorgsuggest.vm`. This issue only concerns hidden users from main wiki. Note that the disclosed information are the username and the first and last name of users, no other information is leaked. ### Patches The problem has been patched on XWiki 13.10.8, 14.4.3 and 14.7RC1. ### Workarounds It's possible to workaround this vulnerability by patching directly `uorgsuggest.vm ` to apply the same changes as in https://github.com/xwiki/xwiki-platform/pull/1883. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20007 * this vulnerability is actually a remaining of https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-97jg-43c9-q6pf which wasn't entirely fixed back then ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](https://jira.xwiki.org)...

### Impact There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights. ### Patches This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script right. ### Workarounds The only known workaround consists in applying [the following patch](https://github.com/xwiki/xwiki-platform/commit/fe65bc35d5672dd2505b7ac4ec42aec57d500fbb) and rebuilding and redeploying `xwiki-platform-skin-skinx`. ### References * https://jira.xwiki.org/browse/XWIKI-19514 * https://jira.xwiki.org/browse/XWIKI-9119 * https://jira.xwiki.org/browse/XWIKI-19583 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](http://jira.xwiki.org) * Email us at [Security ML](mailto:security@x...

### Impact The HTML macro does not systematically perform a proper neutralization of script-related html tags. As a result, any user able to use the html macro in XWiki, is able to introduce an XSS attack. This can be particularly dangerous since in a standard wiki, any user is able to use the html macro directly in their own user profile page. ### Patches The problem has been patched in XWiki 14.8RC1. The patch involve that the HTML macro are systematically cleaned up whenever the user does not have script right. ### Workarounds There's no workaround for this issue. ### References * https://jira.xwiki.org/browse/XWIKI-18568 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira](https://jira.xwiki.org) * Email us at [security ML](mailto:[email protected])

### Impact It is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as `//mydomain.com` (i.e. omitting the `http:`). It was also possible to bypass it when using URL such as `http:/mydomain.com`. ### Patches The problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1. ### Workarounds The only way to workaround the bug is by providing a patched jar of xwiki-platform-oldcore containing the following changes: https://github.com/xwiki/xwiki-platform/commit/e4f7f68e93cb08c25632c126356d218abf192d1e#diff-c445f288d5d63424f56ef13f65514ab4e174a72e979b53b88197c2b7def267cf. ### References * Jira ticket of the reported vulnerability: https://jira.xwiki.org/browse/XWIKI-19994 * Jira ticket of the original mechanism put in place to prevent open redirect: https://jira.xwiki.org/browse/XWIKI-10309 * Original advisory about open redirect: https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-jp55-vvmf-63mv ### For ...

### Impact The [RSS macro](https://extensions.xwiki.org/xwiki/bin/view/Extension/RSS%20Macro) that is bundled in XWiki included the content of the feed items without any cleaning in the HTML output when the parameter `content` was set to `true`. This allowed arbitrary HTML and in particular also JavaScript injection and thus cross-site scripting (XSS) by specifying an RSS feed with malicious content. With the interaction of a user with programming rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content and sabotaging the wiki. The issue can be reproduced by inserting the following XWiki syntax in any wiki page like the user account: ``` {{rss feed="https://xssrss.blogspot.com/feeds/posts/default?alt=rss" content="true" /}} ``` If an alert is displayed when viewing the page, the wiki is vulnerable. ### Patches The issue has been patched in XWiki 14.6 RC1, the con...

### Impact The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1, only escaped `<script>` and `<style>`-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like `<iframe>`. 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}} <a href='' onclick='alert(1)'>XSS</a> {{/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. ### Patches This problem has been patched in XWiki 14.6 RC1 with the introduction of a filter with allowed HTML elements and attributes th...

### Impact Any user with edit rights on a page (e.g., it's own user page), can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the section ids in `XWiki.AdminFieldsDisplaySheet`. This page is installed by default. Reproduction steps are described in https://jira.xwiki.org/browse/XWIKI-20261 ### Patches The vulnerability has been patched in XWiki 15.0-rc-1, 14.10.1, 14.4.8, and 13.10.11. ### Workarounds The issue can be fixed by applying this [patch](https://github.com/xwiki/xwiki-platform/commit/f1e310826a19acdcdecdecdcfe171d21f24d6ede) on `XWiki.AdminFieldsDisplaySheet`. ### References - https://jira.xwiki.org/browse/XWIKI-20261 - https://github.com/xwiki/xwiki-platform/commit/f1e310826a19acdcdecdecdcfe171d21f24d6ede ### 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 ...

### Impact Any user with the right to add an object on a page can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the styles properties `FlamingoThemesCode.WebHome`. This page is installed by default. #### Reproduction Steps **Steps to reproduce**: - As a user without script or programming rights, edit your user profile with the object editor (enable advanced mode if necessary to get access) and add an object of type "Theme Class" of "FlamingoThemesCode". In the field "body-bg" (all other fields should work, too) add the following text: `{{/html}} {{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}` - Click "Save & View" - Open <xwiki-host>/xwiki/bin/view/FlamingoThemesCode/WebHomeSheet where <xwiki-host> is the URL of your XWiki installation **Expected result**: The list of color themes either doesn't inc...