#maven

Jenkins Ansible Plugin allows the specification of extra variables that can be passed to Ansible. These extra variables are commonly used to pass secrets. Ansible Plugin 204.v8191fd551eb_f and earlier stores these extra variables unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration. These extra variables can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. Additionally, the job configuration form does not mask these extra variables, increasing the potential for attackers to observe and capture them. Ansible Plugin 205.v4cb_c48657c21 masks extra variables displayed on the configuration form, and stores them encrypted once job configurations are saved again.

Jenkins SAML Single Sign On(SSO) Plugin 2.1.0 and earlier unconditionally disables SSL/TLS certificate validation for connections to miniOrange or the configured IdP to retrieve SAML metadata. This lack of validation could be abused using a man-in-the-middle attack to intercept these connections. SAML Single Sign On(SSO) Plugin 2.2.0 performs SSL/TLS certificate validation when connecting to miniOrange or the configured IdP to retrieve SAML metadata.

Jenkins Code Dx Plugin 3.1.0 and earlier stores Code Dx server API keys unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration. These API keys can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system. Additionally, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them. Code Dx Plugin 4.0.0 no longer stores the API keys directly, instead accessing them through its newly added Credentials Plugin integration. Affected jobs need to be reconfigured.

Jenkins Azure VM Agents Plugin 852.v8d35f0960a_43 and earlier does not perform permission checks in several HTTP endpoints. This allows attackers with Overall/Read permission to connect to an attacker-specified Azure Cloud server using attacker-specified credentials IDs obtained through another method. Additionally, these HTTP endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability. Azure VM Agents Plugin 853.v4a_1a_dd947520 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

### Impact It's possible to exploit well known parameters in XWiki URLs to perform redirection to untrusted site. This vulnerability was partially fixed in the past for XWiki 12.10.7 and 13.3RC1 but there is still the possibility to force specific URLs to skip some checks, e.g. using URLs like `http:example.com` in the parameter would allow the redirect. ### Patches The issue has now been patched against all patterns that we know about for performing redirect. It also performs a real URI parsing that should protect in most cases. This has been patched in XWiki 14.10.4 and 15.0. ### Workarounds The only workaround is to upgrade XWiki. ### References * JIRA ticket: https://jira.xwiki.org/browse/XWIKI-20096 * JIRA ticket about the improvment actually fixing the vulnerability: https://jira.xwiki.org/browse/XWIKI-20549 * Previous advisory about open redirect: https://github.com/advisories/GHSA-jp55-vvmf-63mv ### For more information If you have any questions or comments abo...

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