#jira

In this post I will go through how you can integrate and send policy alert notifications from Red Hat Advanced Cluster Security for Kubernetes (RHACS) to ServiceNow.

Red Hat Security Advisory 2022-6536-01 - Red Hat OpenShift Container Platform is Red Hat's cloud computing Kubernetes application platform solution designed for on-premise or private cloud deployments. This advisory contains the container images for Red Hat OpenShift Container Platform 4.11.5.

### Impact It's possible to exploit a bug in XWikiRights resolution of groups to obtain privilege escalation. More specifically, editing a right with the object editor leads to adding a supplementary empty value to groups which is then resolved as a reference to XWiki.WebHome page. Adding an XWikiGroup xobject to that page then transforms it to a group, any user put in that group would then obtain the privileges related to the edited right. Note that this security issue is normally mitigated by the fact that XWiki.WebHome (and XWiki space in general) should be protected by default for edit rights. ### Patches The problem has been patched in XWiki 13.10.4 and 14.2RC1 to not consider anymore empty values in XWikiRights. ### Workarounds It's possible to workaround the problem by setting appropriate rights on XWiki.WebHome page to prevent users to edit it. ### References * https://jira.xwiki.org/browse/XWIKI-18386 * https://jira.xwiki.org/browse/XWIKI-15776 ### For more infor...

### Impact A bug in the security cache is storing rules associated to document Page1.Page2 and space Page1.Page2 in the same cache entry. That means that it's possible to overwrite the rights of a space or a document by creating the page of the space with the same name and checking the right of the new one first so that they end up in the security cache and are used for the other too. ### Patches The problem has been patched in XWiki 12.10.11, 13.10.1, 13.4.6. ### Workarounds No workaround other than patching. ### References https://jira.xwiki.org/browse/XWIKI-14075 https://jira.xwiki.org/browse/XWIKI-18983 ### 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:security@xwiki.org)

The Netic Group Export add-on before 1.0.3 for Atlassian Jira does not perform authorization checks. This might allow an unauthenticated user to export all groups from the Jira instance by making a groupexport_download=true request to a plugins/servlet/groupexportforjira/admin/ URI.

### Impact It's possible to perform a CSRF attack for adding or removing tags on XWiki pages. ### Patches The problem has been patched in XWiki 13.10.5 and 14.3. ### Workarounds It's possible to fix the issue without upgrading by locally modifying the documentTags.vm template in your filesystem, to apply the changes exposed there: https://github.com/xwiki/xwiki-platform/commit/7ca56e40cf79a468cea54d3480b6b403f259f9ae. ### References https://jira.xwiki.org/browse/XWIKI-19550 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security ML](mailto:security@xwiki.org)

### Impact Some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service: so a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default: so an inactive users could perform actions for such extensions. This issue exists since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for newer versions (>= 11.3RC1) since we provided the capability to disable user without deleting them, and we encouraged using that feature. ### Patches This issue has been patched in XWiki 14.3RC1 and XWiki 13.10.5. ### Workarounds There is no workaround for this other than upgrading XWiki. ### References * https://jira.xwiki.org/browse/XWIKI-19559 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.x...

### Impact Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) at least for string properties. ### Patches The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. ### Workarounds The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been [overridden](https://extensions.xwiki.org/xwiki/bin/view/Extension/Skin%20Application#HHowtoo...

### Impact It's possible to store a JavaScript which will be executed by anyone viewing the deleted attachments index with an attachment containing javascript in its name. For example, attachment a file with name `><img src=1 onerror=alert(1)>.jpg` will execute the alert. ### Patches This issue has been patched in XWiki 13.10.6 and 14.3. ### Workarounds It is possible to modify fix the vulnerability by editing the wiki page `XWiki.DeletedAttachments` with the object editor, open the `JavaScriptExtension` object and apply on the content the changes that can be found on the commit https://github.com/xwiki/xwiki-platform/commit/6705b0cd0289d1c90ed354bd4ecc1508c4b25745. ### References * https://jira.xwiki.org/browse/XWIKI-19613 ### 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:security@xwiki.org)

### Impact It's possible to store JavaScript in an attachment name, which will be executed by anyone trying to move the corresponding attachment. For example, an attachment with name `><img src=1 onerror=alert(1)>.jpg` will execute the alert. ### Patches This issue has been patched in XWiki 14.4RC1. ### Workarounds It is possible to fix the vulnerability by copying [moveStep1.vm](https://raw.githubusercontent.com/xwiki/xwiki-platform/xwiki-platform-14.0-rc-1/xwiki-platform-core/xwiki-platform-attachment/xwiki-platform-attachment-api/src/main/resources/templates/attachment/moveStep1.vm) to `webapp/xwiki/templates/moveStep1.vm` and replace ``` #set($titleToDisplay = $services.localization.render('attachment.move.title', [$attachment.name, $escapetool.xml($doc.plainTitle), $doc.getURL()])) ``` by ``` #set($titleToDisplay = $services.localization.render('attachment.move.title', [ $escapetool.xml($attachment.name), $escapetool.xml($doc.plainTitle), $escapetool.xml($doc.g...