#maven

### Impact A Vert.x STOMP server processes client STOMP frames without checking that the client send an initial CONNECT frame replied with a successful CONNECTED frame. The client can subscribe to a destination or publish message without prior authentication. Any Vert.x STOMP server configured with an authentication handler is impacted. ### Patches The issue is patched in Vert.x 4.4.2 and Vert.x 3.9.16 ### Workarounds No trivial workaround.

### Impact HTML rendering didn't check for dangerous attributes/attribute values. This allowed cross-site scripting (XSS) attacks via attributes and link URLs, e.g., supported in XWiki syntax. ### Patches This has been patched in XWiki 14.6 RC1. ### Workarounds There are no known workarounds apart from upgrading to a fixed version. ### References * https://github.com/xwiki/xwiki-rendering/commit/c40e2f5f9482ec6c3e71dbf1fff5ba8a5e44cdc1 * https://jira.xwiki.org/browse/XRENDERING-663 ### 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 It's possible for a user to execute anything with the right of the author of the XWiki.ClassSheet document. **Steps to Reproduce:** 1. Edit your user profile with the object editor and add an object of type `DocumentSheetBinding` with value `Default Class Sheet` 1. Edit your user profile with the wiki editor and add the syntax `{{async}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}}` 1. Click "Save & View" **Expected result:** An error is displayed as the user doesn't have the right to execute the Groovy macro. **Actual result:** The text "Hello from groovy!" is displayed at the top of the document. ### Patches This has been patched in XWiki 15.0-rc-1 and 14.10.4. ### Workarounds There are no known workarounds for it. ### References https://jira.xwiki.org/browse/XWIKI-20566 https://github.com/xwiki/xwiki-platform/commit/de72760d4a3e1e9be64a10660a0c19e9534e2ec4 ### For more information If you have any questions or comments about this advisory:...

### Impact There is an issue with the implementation of fine-grained access control rules (document-level security, field-level security and field masking) where they are not correctly applied to the queries during extremely rare race conditions potentially leading to incorrect access authorization. For this issue to be triggered, two concurrent requests need to land on the same instance exactly when query cache eviction happens, once every four hours. ### Affected versions OpenSearch 1.0.0-1.3.9 and 2.0.0-2.6.0 ### Patched versions OpenSearch 1.3.10 and 2.7.0 ### For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do not create a public GitHub issue.

### Impact The HTML sanitizer, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid data attributes. This can be exploited, e.g., via the link syntax in any content that supports XWiki syntax like comments in XWiki: ``` [[Link1>>https://XWiki.example.com||data-x/onmouseover="alert('XSS1')"]]. ``` When a user moves the mouse over this link, the malicious JavaScript code is executed in the context of the user session. When this user is a privileged user who has programming rights, this allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. Note that this vulnerability does not affect restricted cleaning in HTMLCleaner as there attributes are cleaned and thus characters like `/` and `>` are removed in all attribute names. ### Patches This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by making sure that data attributes only c...

### Impact It's possible to execute javascript with the right of any user by leading him to a special URL on the wiki targeting a page which contains an attachment. To reproduce: * add an attachment to a page (for example, your user profile) * add `?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E` to the page view URL as in `https://myhost/xwiki/bin/view/XWiki/MyUser?xpage=importinline&editor=%22%3E%3Cimg%20src%20onerror=alert(document.domain)%3E` ### Patches This has been patched in XWiki 15.0-rc-1, 14.10.4 and 14.4.8. ### Workarounds The easiest is to edit file `<xwiki app>/templates/importinline.vm` and apply the modification described on https://github.com/xwiki/xwiki-platform/commit/28905f7f518cc6f21ea61fe37e9e1ed97ef36f01 ### References https://jira.xwiki.org/browse/XWIKI-20340 https://app.intigriti.com/company/submissions/e95a7ad5-7029-4627-abf0-3e3e3ea0b4ce/XWIKI-E93DFEYK ### Attribution This vulnerability has been reported on Intigrit...

Cross Site Request Forgery (CSRF) vulnerability in FlyCms 1.0 allows attackers to add arbitrary administrator accounts via system/admin/admin_save.

OS Command injection vulnerability in mblog 3.5.0 allows attackers to execute arbitrary code via crafted theme when it gets selected.

File upload vulnerability in MCMS 5.0 allows attackers to execute arbitrary code via a crafted thumbnail. A different vulnerability than CVE-2022-31943.

The Apache Spark UI offers the possibility to enable ACLs via the configuration option spark.acls.enable. With an authentication filter, this checks whether a user has access permissions to view or modify the application. If ACLs are enabled, a code path in HttpSecurityFilter can allow someone to perform impersonation by providing an arbitrary user name. A malicious user might then be able to reach a permission check function that will ultimately build a Unix shell command based on their input, and execute it. This will result in arbitrary shell command execution as the user Spark is currently running as. This issue was disclosed earlier as CVE-2022-33891, but incorrectly claimed version 3.1.3 (which has since gone EOL) would not be affected. NOTE: This vulnerability only affects products that are no longer supported by the maintainer. Users are recommended to upgrade to a supported version of Apache Spark, such as version 3.4.0.