#jira

### Impact A user without script/programming right can trick a user with elevated rights to edit a content with a malicious payload using a WYSIWYG editor. The user with elevated rights is not warned beforehand that they are going to edit possibly dangerous content. The payload is executed at edit time. ### Patches This vulnerability has been patched in XWiki 15.10RC1. ### Workarounds No workaround. It is advised to upgrade to XWiki 15.10+. ### References * https://jira.xwiki.org/browse/XWIKI-20331 * https://jira.xwiki.org/browse/XWIKI-21311 * https://jira.xwiki.org/browse/XWIKI-21481 * https://jira.xwiki.org/browse/XWIKI-21482 * https://jira.xwiki.org/browse/XWIKI-21483 * https://jira.xwiki.org/browse/XWIKI-21484 * https://jira.xwiki.org/browse/XWIKI-21485 * https://jira.xwiki.org/browse/XWIKI-21486 * https://jira.xwiki.org/browse/XWIKI-21487 * https://jira.xwiki.org/browse/XWIKI-21488 * https://jira.xwiki.org/browse/XWIKI-21489 * https://jira.xwiki.org/browse/XWIKI-21490 ### ...

### Impact Is it possible for a user without Script or Programming rights to craft a URL pointing to a page with arbitrary JavaScript. This requires social engineer to trick a user to follow the URL. #### Reproduction steps 1. As a user without script or programming right, create a (non-terminal) document named `" + alert(1) + "` (the quotes need to be part of the name). 1. Edit the class. 1. Add a string property named `"test"`. 1. Edit using the object editor and add an object of the created class 1. Get an admin to open `<xwiki-server>/xwiki/bin/view/%22%20%2B%20alert(1)%20%2B%20%22/?viewer=display&type=object&property=%22%20%2B%20alert(1)%20%2B%20%22.WebHome.test&mode=edit` where `<xwiki-server>` is the URL of your XWiki installation. ### Patches This has been patched in XWiki 14.10.21, 15.5.5, 15.10.6 and 16.0.0. ### Workarounds We're not aware of any workaround except upgrading. ### References - https://jira.xwiki.org/browse/XWIKI-21810 - https://github.com/xwiki/xwiki-plat...

Red Hat Security Advisory 2024-5365-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include double free and null pointer vulnerabilities.

Red Hat Security Advisory 2024-5364-03 - An update for kernel is now available for Red Hat Enterprise Linux 9.2 Extended Update Support. Issues addressed include double free, memory leak, and null pointer vulnerabilities.

Red Hat Security Advisory 2024-5256-03 - An update for kernel-rt is now available for Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions. Issues addressed include code execution, denial of service, and use-after-free vulnerabilities.

Black Hat presentation reveals adversaries don't need to complete all seven stages of a traditional kill chain to achieve their objectives.

The enterprise resource planning platform bug CVE-2024-38856 has a vulnerability-severity score of 9.8 out of 10 on the CVSS scale and offers a wide avenue into enterprise applications for cyberattackers.

### Impact Some of the recent development by Icinga is, under certain circumstances, susceptible to cross site request forgery. (CSRF) Affected products: * Icinga Web (>=2.12.0) * Icinga DB Web (>=1.0.0) * Icinga Notifications Web (>=0.1.0) * Icinga Web JIRA Integration (>=1.3.0) All affected products, in any version, will be unaffected by this once `icinga-php-library` is upgraded. ### Patches Version 0.10.1 will include a fix for this. It will be published as part of the `icinga-php-library` v0.14.1 release.

### Impact By creating a conflict when another user with more rights is currently editing a page, it is possible to execute JavaScript snippets on the side of the other user, which compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on a XWiki instance, a user with admin rights needs to edit a document without saving right away. Then, as another user without any other right than edit on the specific document, change the whole content to `<script>alert('XSS')</script>`. When the admin user then saves the document, a conflict popup appears. If they select "Fix each conflict individually" and see an alert displaying "XSS", then the instance is vulnerable. ### Patches This has been patched in XWiki 15.10.8 and 16.3.0RC1. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira.xwiki.org/browse/XWIKI-21626 * https://github.com/xwiki/xwiki-platform/commit/821d43ec45e67d45a6735a0717b9b77fffc...

### Impact Any user with edit right on any page can perform arbitrary remote code execution by adding instances of `XWiki.SearchSuggestConfig` and `XWiki.SearchSuggestSourceClass` to their user profile or any other page. This compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce on an instance, as a user without script nor programming rights, add an object of type `XWiki.SearchSuggestConfig` to your profile page, and an object of type `XWiki.SearchSuggestSourceClass` as well. On this last object, set both `name` and `icon` properties to `$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')")` and `limit` and `engine` to `{{/html}}{{async}}{{velocity}}$services.logging.getLogger("attacker").error("I got programming: $services.security.authorization.hasAccess('programming')"){{/velocity}}{{/async}}`. Save and display the page. If the logs contain any message `ERROR ...