Grafana Data source and plugin proxy endpoints could leak the authentication cookie to some destination plugins

[Severity: HIGH]

Today we are releasing Grafana 9.2. Alongside with new features and other bug fixes, this release includes a Moderate severity security fix for CVE-2022-39201

We are also releasing security patches for Grafana 9.1.8 and Grafana 8.5.14 to fix these issues.

Release 9.2, latest release, also containing security fix:

- [Download Grafana 9.2](https://grafana.com/grafana/download/9.2)

Release 9.1.8, only containing security fix:

- [Download Grafana 9.1.8](https://grafana.com/grafana/download/9.1.8)

Release 8.5.14, only containing security fix:

- [Download Grafana 8.5.14](https://grafana.com/grafana/download/8.5.14)

Appropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud) and as always, we closely coordinated with all cloud providers licensed to offer Grafana Pro. They have received early notification under embargo and confirmed that their offerings are secure at the time of this announcement. This is applicable to Amazon Managed Grafana and Azure's Grafana as a service offering.

## CVE-2022-39201

### Summary
On September 7th as a result of an internal security audit we have discovered that Grafana could leak the authentication cookie of users to plugins. After further analysis the vulnerability impacts data source and plugin proxy endpoints under certain conditions.

We believe that this vulnerability is rated at CVSS 6.8 (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H)

### Impact
The destination plugin could receive a Grafana authentication cookie of the user.

### Impacted versions

All installations for Grafana versions >= v5.0.0-beta1

### Solutions and mitigations

To fully address CVE-2022-39201 please upgrade your Grafana instances.
Appropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud).

### Reporting security issues

If you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of Grafana Labs' open source and commercial products (including, but not limited to Grafana, Grafana Cloud, Grafana Enterprise, and grafana.com). We can accept only vulnerability reports at this address. We would prefer that you encrypt your message to us by using our PGP key. The key fingerprint is

F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA

The key is available from keyserver.ubuntu.com.

### Security announcements

We maintain a [security category](https://community.grafana.com/c/support/security-announcements) on our blog, where we will always post a summary, remediation, and mitigation details for any patch containing security fixes.

You can also subscribe to our [RSS feed](https://grafana.com/tags/security/index.xml).


Grafana Data source and plugin proxy endpoints leaking authentication tokens to some destination plugins

[Severity: MEDIUM]

Today we are releasing Grafana 9.2. Alongside with new features and other bug fixes, this release includes a Moderate severity security fix for CVE-2022-31130

We are also releasing security patches for Grafana 9.1.8 and Grafana 8.5.14 to fix these issues.

Release 9.2, latest release, also containing security fix:

- [Download Grafana 9.2](https://grafana.com/grafana/download/9.2)

Release 9.1.8, only containing security fix:

- [Download Grafana 9.1.8](https://grafana.com/grafana/download/9.1.8)

Release 8.5.14, only containing security fix:

- [Download Grafana 8.5.14](https://grafana.com/grafana/download/8.5.14)

Appropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud) and as always, we closely coordinated with all cloud providers licensed to offer Grafana Pro. They have received early notification under embargo and confirmed that their offerings are secure at the time of this announcement. This is applicable to Amazon Managed Grafana and Azure's Grafana as a service offering.

## CVE-2022-31130

### Summary
On June 26 a security researcher contacted Grafana Labs to disclose a vulnerability with the GitLab data source plugin that could leak the API key to GitLab. After further analysis the vulnerability impacts data source and plugin proxy endpoints with authentication tokens but under some conditions.

We believe that this vulnerability is rated at CVSS 4.9 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N)

### Impact
The destination plugin could receive a Grafana authentication token of the user.

### Impacted versions

All installations for Grafana versions <=9.x, <=8.x, <=7.x

### Solutions and mitigations

To fully address CVE-2022-31130 please upgrade your Grafana instances.
Appropriate patches have been applied to [Grafana Cloud](https://grafana.com/cloud).

As a workaround do not use API keys, JWT authentication or any HTTP Header based authentication.

### Reporting security issues

If you think you have found a security vulnerability, please send a report to security@grafana.com. This address can be used for all of Grafana Labs' open source and commercial products (including, but not limited to Grafana, Grafana Cloud, Grafana Enterprise, and grafana.com). We can accept only vulnerability reports at this address. We would prefer that you encrypt your message to us by using our PGP key. The key fingerprint is

F988 7BEA 027A 049F AE8E 5CAA D125 8932 BE24 C5CA

The key is available from keyserver.ubuntu.com.

### Security announcements

We maintain a [security category](https://community.grafana.com/c/support/security-announcements) on our blog, where we will always post a summary, remediation, and mitigation details for any patch containing security fixes.

You can also subscribe to our [RSS feed](https://grafana.com/tags/security/index.xml).


Uptime Kuma's authenticated path traversal via plugin repository name may lead to unavailability or data loss

[Severity: MEDIUM]

### Summary
A path traversal vulnerability via the plugin repository name allows an authenticated attacker to delete files on the server leading to unavailability and potentially data loss.

### Details
Uptime Kuma allows authenticated users to install plugins from an official list of plugins. This feature is currently disabled in the web interface, but the corresponding API endpoints are still available after login.
Before a plugin is downloaded, the plugin installation directory is checked for existence. If it exists, it's removed before the plugin installation.

Because the plugin is not validated against the official list of plugins or sanitized, the check for existence and the removal of the plugin installation directory are prone to path traversal.

### Impact
This vulnerability allows an authenticated attacker to delete files from the server Uptime Kuma is running on.
Depending on which files are deleted, Uptime Kuma or the whole system may become unavailable due to data loss.


WildFly Elytron: OIDC app attempting to access the second tenant, the user should be prompted to log

[Severity: HIGH]

A flaw was found in JBoss EAP. When an OIDC app that serves multiple tenants attempts to access the second tenant, it should prompt the user to log in again since the second tenant is secured with a different OIDC configuration. The underlying issue is in OidcSessionTokenStore when determining if a cached token should be used or not. This logic needs to be updated to take into account the new "provider-url" option in addition to the "realm" option.


Storefront user can access history and most viewed data from matching back-office user with the same ID

[Severity: MEDIUM]

### Impact

Navigation history, most viewed and favorite navigation items are returned to storefront user in JSON navigation response if ID of storefront user matches ID of back-office user.


Liferay Portal Document and Media widget and Liferay DXP vulnerable to stored Cross-site Scripting

[Severity: CRITICAL]

Stored cross-site scripting (XSS) vulnerability in the Document and Media widget in Liferay Portal 7.4.3.18 through 7.4.3.101, and Liferay DXP 2023.Q3 before patch 6, and 7.4 update 18 through 92 allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into a document's “Title” text field.


Liferay Portal Language Override edit screen and Liferay DXP vulnerable to reflected Cross-site Scripting

[Severity: CRITICAL]

Reflected cross-site scripting (XSS) vulnerability in the Language Override edit screen in Liferay Portal 7.4.3.8 through 7.4.3.97, and Liferay DXP 2023.Q3 before patch 5, and 7.4 update 4 through 92 allows remote attackers to inject arbitrary web script or HTML via the `_com_liferay_portal_language_override_web_internal_portlet_PLOPortlet_key` parameter.


Liferay Portal and Liferay DXP Vulnerable to Open Redirect in Countries Management's Edit Region Page

[Severity: MEDIUM]

Open redirect vulnerability in the Countries Management’s edit region page in Liferay Portal 7.4.3.45 through 7.4.3.101, and Liferay DXP 2023.Q3 before patch 6, and 7.4 update 45 through 92 allows remote attackers to redirect users to arbitrary external URLs via the _com_liferay_address_web_internal_portlet_CountriesManagementAdminPortlet_redirect parameter.


Rancher permissions on 'namespaces' in any API group grants 'edit' permissions on namespaces in 'core'

[Severity: HIGH]

### Impact
A vulnerability has been identified when granting a `create` or `*` **global role** for a resource type of "namespaces"; no matter the API group, the subject will receive `*` permissions for core namespaces. This can lead to someone being capable of accessing, creating, updating, or deleting a namespace in the project. This includes reading or updating a namespace in the project so that it is available in other projects in which the user has the "manage-namespaces" permission or updating another namespace in which the user has normal "update" permissions to be moved into the project.

The expected behavior is to not be able to create, update, or delete a namespace in the project or move another namespace into the project since the user doesn't have any permissions on namespaces in the core API group.

Moving a namespace to another project could lead to leakage of secrets, in case the targeted project has secrets. And also can lead to the namespace being able to abuse the resource quotas of the targeted project.

### Patches
Patched versions include releases `2.6.14`, `2.7.10` and `2.8.2`.

### Workarounds
There is no direct mitigation besides updating Rancher to a patched version.

### References
If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security-related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).


Apache ServiceComb Service-Center Exposure of Sensitive Information to an Unauthorized Actor vulnerability

[Severity: MEDIUM]

Exposure of Sensitive Information to an Unauthorized Actor in Apache ServiceComb Service-Center. This issue affects Apache ServiceComb Service-Center before 2.1.0 (included). Users are recommended to upgrade to version 2.2.0, which fixes the issue.


Quarkus Improper Handling of Insufficient Permissions or Privileges and Improper Handling of Exceptional Conditions vulnerability

[Severity: HIGH]

A flaw was found in the json payload. If annotation based security is used to secure a REST resource, the JSON body that the resource may consume is being processed (deserialized) prior to the security constraints being evaluated and applied. This does not happen with configuration based security.


Apache Airflow CNCF Kubernetes provider, Apache Airflow: Kubernetes configuration file saved without encryption in the Metadata and logged as plain text in the Triggerer service

[Severity: MEDIUM]

Since version 5.2.0, when using deferrable mode with the path of a Kubernetes configuration file for authentication, the Airflow worker serializes this configuration file as a dictionary and sends it to the triggerer by storing it in metadata without any encryption. Additionally, if used with an Airflow version between 2.3.0 and 2.6.0, the configuration dictionary will be logged as plain text in the triggerer service without masking. This allows anyone with access to the metadata or triggerer log to obtain the configuration file and use it to access the Kubernetes cluster.

This behavior was changed in version 7.0.0, which stopped serializing the file contents and started providing the file path instead to read the contents into the trigger. Users are recommended to upgrade to version 7.0.0, which fixes this issue.


Record titles for restricted records can be viewed if exposed by GridFieldAddExistingAutocompleter

[Severity: MEDIUM]

### Impact
If a user should not be able to see a record, but that record can be added to a `GridField` using the `GridFieldAddExistingAutocompleter` component, the record's title can be accessed by that user.

**Base CVSS:** [4.3](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N/E:F/RL:O/RC:C&version=3.1)
**Reported by:** Nick K - LittleMonkey, [littlemonkey.co.nz](http://littlemonkey.co.nz/)

### References
- https://www.silverstripe.org/download/security-releases/CVE-2023-48714


tj-actions/changed-files has Potential Actions command injection in output filenames (GHSL-2023-271)

[Severity: HIGH]

### Summary
The `tj-actions/changed-files` workflow allows for command injection in changed filenames, allowing an attacker to execute arbitrary code and potentially leak secrets.

### Details
The [`changed-files`](https://github.com/tj-actions/changed-files) action returns a list of files changed in a commit or pull request which provides an `escape_json` input [enabled by default](https://github.com/tj-actions/changed-files/blob/94549999469dbfa032becf298d95c87a14c34394/action.yml#L136), only escapes `"` for JSON values.

This could potentially allow filenames that contain special characters such as `;` and \` (backtick) which can be used by an attacker to take over the [GitHub Runner](https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners) if the output value is used in a raw fashion (thus being directly replaced before execution) inside a `run` block. By running custom commands an attacker may be able to steal **secrets** such as `GITHUB_TOKEN` if triggered on other events than `pull_request`. For example on `push`.

#### Proof of Concept

1. Submit a pull request to a repository with a new file injecting a command. For example `$(whoami).txt` which is a valid filename.
2. Upon approval of the workflow (triggered by the pull request), the action will get executed and the malicious pull request filename will flow into the `List all changed files` step below.

```yaml
      - name: List all changed files
        run: |
          for file in ${{ steps.changed-files.outputs.all_changed_files }}; do
            echo "$file was changed"
          done
```

Example output:

```yaml
##[group]Run for file in $(whoami).txt; do
    for file in $(whoami).txt; do
        echo "$file was changed"
    done
shell: /usr/bin/bash -e {0}
##[endgroup]
runner.txt was changed
```

### Impact

This issue may lead to arbitrary command execution in the GitHub Runner.

### Resolution
- A new `safe_output` input would be enabled by default and return filename paths escaping special characters like ;, ` (backtick), $, (), etc for bash environments.

- A safe recommendation of using environment variables to store unsafe outputs.

```yaml
- name: List all changed files
  env:
    ALL_CHANGED_FILES: ${{ steps.changed-files.outputs.all_changed_files }}
  run: |
    for file in "$ALL_CHANGED_FILES"; do
      echo "$file was changed"
    done
```

### Resources

* [Keeping your GitHub Actions and workflows secure Part 2: Untrusted input](https://securitylab.github.com/research/github-actions-untrusted-input/)
* [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)


`serde` deserialization for `FamStructWrapper` lacks bound checks that could potentially lead to out-of-bounds memory access

[Severity: MEDIUM]

### Impact

An issue was discovered in the FamStructWrapper::deserialize implementation provided by the crate for vmm_sys_util::fam::FamStructWrapper, which can lead to out of bounds memory accesses. The deserialization does not check that the length stored in the header matches the flexible array length. Mismatch in the lengths might allow out of bounds memory access through Rust-safe methods.

Impacted versions: >= 0.5.0

### Patches

The issue was corrected in version 0.12.0 by inserting a check that verifies the lengths of compared flexible arrays are equal for any deserialized header and aborting deserialization otherwise. Moreover, the API was changed so that header length can only be modified through Rust-unsafe code. This ensures that users cannot trigger out-of-bounds memory access from Rust-safe code.


 Infinispan REST Server's cache retrieval endpoints do not properly evaluate the necessary admin permissions

[Severity: HIGH]

A flaw was found in Infinispan's REST, Cache retrieval endpoints do not properly evaluate the necessary admin permissions for the operation. This issue could allow an authenticated user to access information outside of their intended permissions.


The redirect_uri validation logic allows for bypassing explicitly allowed hosts that would otherwise be restricted

[Severity: HIGH]

An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts.

The problem arises in the verifyRedirectUri method, which attempts to enforce rules on user-controllable input, but essentially causes a desynchronization in how Keycloak and browsers interpret URLs. Keycloak, for example, receives "[www%2ekeycloak%2eorg%2fapp%2f:y@example.com](https://www%2ekeycloak%2eorg%2fapp%2f:y@example.com/)" and thinks the authority to be keycloak.org when it is actually example.com. This happens because the validation logic is performed on a URL decoded version, which no longer represents the original input.

### Acknowledgements
Karel Knibbe


yii2-authclient vulnerable to possible timing attack on string comparison in OAuth1, OAuth2 and OpenID Connect implementation

[Severity: LOW]

### Impact
_What kind of vulnerability is it? Who is impacted?_

Original Report:

> The Oauth1/2 "state" and OpenID Connect "nonce" is vulnerable for a "timing attack" since it's compared via regular string
> comparison (instead of `Yii::$app->getSecurity()->compareString()`).

Affected Code:

1. OAuth 1 "state"

    https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth1.php#L158

3. OAuth 2 "state"

    https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth2.php#L121

4. OpenID Connect "nonce"

    https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OpenIdConnect.php#L420

### Patches
_Has the problem been patched? What versions should users upgrade to?_

TBD: Replace strcmp with  `Yii::$app->getSecurity()->compareString()`).

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

not as far as I see.

### References
_Are there any links users can visit to find out more?_


Using the directory back payload (“/../”) in a package name allows placement of package in other folders.

[Severity: LOW]

#### Impact
Backoffice users with permissions to create packages can use path traversal and thereby write outside of the expected location.

#### Explanation of the vulnerability
The “Package” section in Umbraco Backoffice allows a logged in user to write folders outside of the default package directory.


Microcks contains a Server-Side Request Forgery (SSRF) via the component /jobs and /artifact/download

[Severity: CRITICAL]

Microcks up to version 1.17.1 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /jobs and /artifact/download. This vulnerability allows attackers to access network resources and sensitive information via a crafted GET request.


Apache Storm Local Information Disclosure Vulnerability in Storm-core on Unix-Like systems due temporary files

[Severity: MEDIUM]

On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems.

The method File.createTempFile on unix-like systems creates a file with predefined name (so easily identifiable) and by default will create this file with the permissions -rw-r--r--. Thus, if sensitive information is written to this file, other local users can read this information.

File.createTempFile(String, String) will create a temporary file in the system temporary directory if the 'java.io.tmpdir' system property is not explicitly set.

This affects the class  https://github.com/apache/storm/blob/master/storm-core/src/jvm/org/apache/storm/utils/TopologySpoutLag.java#L99  and was introduced by  https://issues.apache.org/jira/browse/STORM-3123

In practice, this has a very limited impact as this class is used only if ui.disable.spout.lag.monitoring

 is set to false, but its value is true by default.
Moreover, the temporary file gets deleted soon after its creation.

The solution is to use  Files.createTempFile https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/file/Files.html#createTempFile(java.lang.String,java.lang.String,java.nio.file.attribute.FileAttribute...)  instead.

We recommend that all users upgrade to the latest version of Apache Storm.


Whole content of all documents of all wikis exposed to anybody with view right on Solr suggest service

[Severity: HIGH]

### Impact
The Solr-based search suggestion provider that also duplicates as generic JavaScript API for search results in XWiki exposes the content of all documents of all wikis to anybody who has access to it, by default it is public. This exposes all information stored in the wiki (but not some protected information like password hashes). While there is a right check normally, the right check can be circumvented by explicitly requesting fields from Solr that don't include the data for the right check. This can be reproduced by opening `<xwiki-server>/xwiki/bin/get/XWiki/SuggestSolrService?outputSyntax=plain&media=json&nb=1000&query=q%3D*%3A*%0Aq.op%3DAND%0Afq%3Dtype%3ADOCUMENT%0Afl%3Dtitle_%2C+reference%2C+links%2C+doccontentraw_%2C+objcontent__&input=+` where `<xwiki-server>` is the URL of the XWiki installation. If this displays any results, the wiki is vulnerable.

### Patches
This has been fixed in XWiki 15.6RC1, 15.5.1 and 14.10.15 by not listing documents whose rights cannot be checked.

### Workarounds
We're not aware of a workaround apart from upgrading to a fixed version.

### References
* https://jira.xwiki.org/browse/XWIKI-21138
* https://github.com/xwiki/xwiki-platform/commit/93b8ec702d7075f0f5794bb05dfb651382596764


Concrete CMS allows unauthorized access because directories can be created with insecure permissions

[Severity: MEDIUM]

Concrete CMS before 8.5.13 and 9.x before 9.2.2 allows unauthorized access because directories can be created with insecure permissions. File creation functions (such as the Mkdir() function) gives universal access (0777) to created folders by default. Excessive permissions can be granted when creating a directory with permissions greater than 0755 or when the permissions argument is not specified.


HTTPie allows attackers to eavesdrop on communications between the host and server via a man-in-the-middle attack

[Severity: HIGH]

Missing SSL certificate validation in HTTPie v3.2.2 allows attackers to eavesdrop on communications between the host and server via a man-in-the-middle attack.


TinyMCE vulnerable to mutation Cross-site Scripting via special characters in unescaped text nodes

[Severity: MEDIUM]

### Impact
A [mutation cross-site scripting](https://researchgate.net/publication/266654651_mXSS_attacks_Attacking_well-secured_web-applications_by_using_innerHTML_mutations) (mXSS) vulnerability was discovered in TinyMCE’s core undo/redo functionality and other APIs and plugins. Text nodes within specific parents are not escaped upon serialization according to the [HTML standard](https://html.spec.whatwg.org/multipage/parsing.html#serialising-html-fragments). If such text nodes contain a special character reserved as an internal marker, they can be combined with other HTML patterns to form malicious snippets. These snippets pass the initial sanitisation layer when the content is parsed into the editor body, but can trigger XSS when the special internal marker is removed from the content and re-parsed. Such mutations occur when serialised HTML content is processed before being stored in the undo stack, or when the following APIs and plugins are used:
* [`tinymce.Editor.getContent({ format: 'raw' })`](https://tiny.cloud/docs/tinymce/6/apis/tinymce.editor/#getContent)
* [`tinymce.Editor.resetContent()`](https://tiny.cloud/docs/tinymce/6/apis/tinymce.editor/#resetContent)
* [Autosave Plugin](https://tiny.cloud/docs/tinymce/6/autosave/)

### Patches
This vulnerability has been patched in TinyMCE 6.7.3 by:
* ensuring that any unescaped text nodes which contain the special internal marker are emptied before removing the marker from the rest of the HTML, and
* removing the special internal marker from content strings passed to `Editor.setContent`, `Editor.insertContent`, and `Editor.resetContent` APIs to prevent them from being loaded into the editor as user-provided content.

### Fix
To avoid this vulnerability:
- Upgrade to TinyMCE 6.7.3 or higher for TinyMCE 6.x.
- Upgrade to TinyMCE 5.10.9 or higher for TinyMCE 5.x.

### Acknowledgements
Tiny Technologies would like to thank Masato Kinugawa of [Cure53](https://cure53.de/) for discovering this vulnerability.

### References
- [TinyMCE 5.10.9 Release Notes](https://tiny.cloud/docs/release-notes/release-notes5109/)
- [TinyMCE 6.7.3 Release Notes](https://tiny.cloud/docs/tinymce/6/6.7.3-release-notes/)

### For more information

Email us at [infosec@tiny.cloud](mailto:infosec@tiny.cloud)
Open an issue in the [TinyMCE repo](https://github.com/tinymce/tinymce/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc)


Quarkus does not properly sanitize artifacts created from its use of the Gradle plugin, allowing certain build system information to remain

[Severity: HIGH]

A flaw was found in Quarkus, where it does not properly sanitize artifacts created using the Gradle plugin, allowing certain build system information to remain. This flaw allows an attacker to access potentially sensitive information from the build system within the application.


In Reactor Netty HTTP Server a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack

[Severity: HIGH]

In Reactor Netty HTTP Server, versions 1.1.x prior to 1.1.13 and versions 1.0.x prior to 1.0.39, a malicious user can send a request using a specially crafted URL that can lead to a directory traversal attack.

Specifically, an application is vulnerable if Reactor Netty HTTP Server is configured to serve static resources.


Aiohttp has inconsistent interpretation of `Content-Length` vs. `Transfer-Encoding` differing in C and Python fallbacks

[Severity: LOW]

### Impact

Aiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation.

A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want.

The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and log the request.

### References

- https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371


Remarshal expands YAML alias nodes unlimitedly, hence Remarshal is vulnerable to Billion Laughs Attack

[Severity: HIGH]

Remarshal prior to v0.17.1 expands YAML alias nodes unlimitedly, hence Remarshal is vulnerable to Billion Laughs Attack. Processing untrusted YAML files may cause a denial-of-service (DoS) condition.


Apache Airflow allows authenticated and DAG-view authorized users to modify some DAG run detail values when submitting notes

[Severity: MEDIUM]

Apache Airflow, versions before 2.7.3, is affected by a vulnerability that allows authenticated and DAG-view authorized Users to modify some DAG run detail values when submitting notes. This could have them alter details such as configuration parameters, start date, etc.  Users should upgrade to version 2.7.3 or later which has removed the vulnerability.


Any value can be changed in the configuration table by an employee having access to block reassurance module

[Severity: MEDIUM]

### Impact
An ajax function in module blockreassurance allows modifying any value in the configuration table

### Patches
v5.1.4

### Workarounds
no workaround available

### References


PrestaShop blockreassurance BO User can remove any file from server when adding a and deleting a block

[Severity: MEDIUM]

### Impact
When adding a block in blockreassurance module, a BO user can modify the http request and give the path of any file in the project instead of an image. When deleting the block from the BO, the file will be deleted.

It is possible to make the website completely unavailable by removing index.php for example.

### Patches
v5.1.4

### Workarounds
No workaround available

### References


XWiki Platform vulnerable to  reflected cross-site scripting through revision parameter in content menu

[Severity: CRITICAL]

### Impact

XWiki is vulnerable to reflected cross-site scripting (RXSS) via the `rev` parameter that is used in the content of the content menu without escaping. If an attacker can convince a user to visit a link with a crafted parameter, this allows the attacker to execute arbitrary actions in the name of the user, including remote code (Groovy) execution in the case of a user with programming right, compromising the confidentiality, integrity and availability of the whole XWiki installation.

The vulnerability can be demonstrated by opening `<xwiki-host>/xwiki/bin/view/Main/?rev=xar%3Aorg.xwiki.platform%3Axwiki-platform-distribution-flavor-common%2F15.5%25%25%22%3e%3cscript%3ealert(1)%3c%2fscript%3e` where `<xwiki-host>` is the URL of your XWiki installation. If an alert is displayed, the installation is vulnerable.

### Patches
This has been patched in XWiki 15.6 RC1, 15.5.1 and 14.10.14.

### Workarounds
The [patch](https://github.com/xwiki/xwiki-platform/commit/04e325d57d4bcb6ab79bddcafbb19032474c2a55) can be manually applied without upgrading (or restarting) the instance.

### References
* https://jira.xwiki.org/browse/XWIKI-21095
* https://github.com/xwiki/xwiki-platform/commit/04e325d57d4bcb6ab79bddcafbb19032474c2a55

### Attribution

We thank Agostino Parentela, Vulnerability Management Engineer of TicketOne S.p.A., [agostino.parentela@ticketone.it](mailto:agostino.parentela@ticketone.it) for reporting this vulnerability.


XWiki Platform vulnerable to remote code execution through the section parameter in Administration as guest

[Severity: CRITICAL]

### Impact
XWiki doesn't properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document `XWiki.AdminSheet` (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance.

By opening the URL `<server>/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet&viewer=content&section=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D&xpage=view` where `<server>` is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message `ERROR attacker                       - Attack succeeded!` to appear in XWiki's log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated with `<server>/xwiki/bin/get/XWiki/XWikiPreferences?section=%3C%25println(%22Hello%20from%20Groovy%22)%25%3E&xpage=view` which displays `admin.hello from groovy` as title when the attack succeeds (tested on XWiki 1.7).

### Patches
This vulnerability has been patched in XWiki 14.10.14, 15.6 RC1 and 15.5.1.

### Workarounds
The [fix](https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a#diff-6271f9be501f30b2ba55459eb451aee3413d34171ba8198a77c865306d174e23), which consists of replacing `= $services.localization.render("administration.sectionTitle$level", [$sectionName]) =` by `= $services.localization.render("administration.sectionTitle$level", 'xwiki/2.1', [$sectionName]) =`, can be applied manually to the document `XWiki.AdminSheet`.

### References
* https://jira.xwiki.org/browse/XWIKI-21110
* https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a


XWiki Platform privilege escalation from script right to programming right through title displayer

[Severity: CRITICAL]

### Impact

In XWiki Platform, it's possible for a user to write a script in which any velocity content is executed with the right of any other document content author.

To reproduce:

As a user with script but not programming right, create a document with the following content:

```
{{velocity}}
#set($main = $xwiki.getDocument('AppWithinMinutes.DynamicMessageTool'))
$main.setTitle('$doc.getDocument().getContentAuthor()')
$main.getPlainTitle()
{{/velocity}}
```

Since this API require programming right and the user does not have it, the expected result is `$doc.document.authors.contentAuthor` (not executed script), unfortunately with the security vulnerability we get `XWiki.superadmin` which shows that the title was executed with the right of the unmodified document.

### Patches

This has been patched in XWiki 14.10.7 and 15.2-RC-1.

### Workarounds

There are no known workarounds for it.

### References

* https://jira.xwiki.org/browse/XWIKI-20624
* https://github.com/xwiki/xwiki-platform/commit/11a9170dfe63e59f4066db67f84dbfce4ed619c6
* https://jira.xwiki.org/browse/XWIKI-20625
* https://github.com/xwiki/xwiki-platform/commit/41d7dca2d30084966ca6a7ee537f39ee8354a7e3

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


XWiki Platform vulnerable to remote code execution via the edit action because it lacks CSRF token

[Severity: CRITICAL]

### Impact

In XWiki Platform, it's possible to execute content with the right of any user if you can make this user follow a crafted URL. This is possible because edit action sets and thereby executes the page content without checking for a cross-site request forgert (CSRF) token.

To reproduce:
Get a user with programming rights to visit the URL `<xwiki-host>/xwiki/bin/edit/Main/?content=%7B%7Bgroovy%7D%7Dprintln%28%22Hello+from+Groovy%21%22%29%7B%7B%2Fgroovy%7D%7D&xpage=view`, where `<xwiki-host>` is the URL of your XWiki installation. This can be done by embedding an image with this URL.

The text "Hello from Groovy!" is displayed in the page content, showing that the Groovy macro has been executed.

### Patches

This has been patched in XWiki 14.10.7 and 15.2-RC-1.

### Workarounds
There are no known workarounds for it.

### References

* https://jira.xwiki.org/browse/XWIKI-20386
* https://github.com/xwiki/xwiki-platform/commit/cf8eb861998ea423c3645d2e5e974420b0e882be

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


capsule-proxy service discloses Namespaces of colliding tenants to owners of different tenants with the same ServiceAccount name

[Severity: MEDIUM]

### Summary

A bug in the RoleBinding reflector used by `capsule-proxy` gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name.

### Details

- Tenant `solar`, owned by a ServiceAccount named `tenant-owner` in the Namespace `solar`
- Tenant `wind`, owned by a ServiceAccount named `tenant-owner` in the Namespace `wind`

> Please, notice the same ServiceAccount name, although in different namespaces.

The Tenant owner `solar` would be able to list the namespaces of the Tenant `wind` and vice-versa, although this is not correct.

The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions:

1. `capsule-proxy` runs with the `--disable-caching=false` (default value: `false`)
2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces.

The CVE doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this.


CodeIgniter4 vulnerable to information disclosure when detailed error report is displayed in production environment

[Severity: HIGH]

### Impact
If an error or exception occurs in CodeIgniter4 v4.4.2 and earlier, a detailed error report is displayed even if in the production environment. As a result, confidential information may be leaked.

### Patches
Upgrade to v4.4.3 or later. See [upgrading guide](https://codeigniter4.github.io/userguide/installation/upgrade_443.html).

### Workarounds
Replace `ini_set('display_errors', '0')` with `ini_set('display_errors', 'Off')` in `app/Config/Boot/production.php`.

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [codeigniter4/CodeIgniter4](https://github.com/codeigniter4/CodeIgniter4/issues)
* Email us at [SECURITY.md](https://github.com/codeigniter4/CodeIgniter4/blob/develop/SECURITY.md)


crypto-js PBKDF2 1,000 times weaker than specified in 1993 and 1.3M times weaker than current standard

[Severity: CRITICAL]

### Impact
#### Summary
Crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and [at least 1,300,000 times weaker than current industry standard][OWASP PBKDF2 Cheatsheet]. This is because it both (1) defaults to [SHA1][SHA1 wiki], a cryptographic hash algorithm considered insecure [since at least 2005][Cryptanalysis of SHA-1] and (2) defaults to [one single iteration][one iteration src], a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to [preimage][preimage attack] and [collision][collision attack] attacks.

Potential Impact:

1. If used to protect passwords, the impact is high.
2. If used to generate signatures, the impact is high.

Probability / risk analysis / attack enumeration:

1. [For at most $45,000][SHA1 is a Shambles], an attacker, given control of only the beginning of a crypto-js PBKDF2 input, can create a value which has _identical cryptographic signature_ to any chosen known value.
4. Due to the [length extension attack] on SHA1, we can create a value that has identical signature to any _unknown_ value, provided it is prefixed by a known value. It does not matter if PBKDF2 applies '[salt][cryptographic salt]' or '[pepper][cryptographic pepper]' or any other secret unknown to the attacker. It will still create an identical signature.

Update: PBKDF2 requires a pseudo-random function that takes two inputs, so HMAC-SHA1 is used rather than plain SHA1. HMAC is not affected by [length extension attacks][Length Extension attack]. However, by defaulting to a single PBKDF2 iteration, the hashes do not benefit from the extra computational complexity that PBKDF2 is supposed to provide. The resulting hashes therefore have little protection against an offline brute-force attack.

[cryptographic salt]: https://en.wikipedia.org/wiki/Salt_(cryptography) "Salt (cryptography), Wikipedia"
[cryptographic pepper]: https://en.wikipedia.org/wiki/Pepper_(cryptography) "Pepper (cryptography), Wikipedia"
[SHA1 wiki]: https://en.wikipedia.org/wiki/SHA-1 "SHA-1, Wikipedia"
[Cryptanalysis of SHA-1]: https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html "Cryptanalysis of SHA-1"
[one iteration src]: https://github.com/brix/crypto-js/blob/1da3dabf93f0a0435c47627d6f171ad25f452012/src/pbkdf2.js#L22-L26 "crypto-js/src/pbkdf2.js lines 22-26"
[collision attack]: https://en.wikipedia.org/wiki/Hash_collision "Collision Attack, Wikipedia"
[preimage attack]: https://en.wikipedia.org/wiki/Preimage_attack "Preimage Attack, Wikipedia"
[SHA1 is a Shambles]: https://eprint.iacr.org/2020/014.pdf "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
and Application to the PGP Web of Trust, Gaëtan Leurent and Thomas Peyrin"
[Length Extension attack]: https://en.wikipedia.org/wiki/Length_extension_attack "Length extension attack, Wikipedia"

crypto-js has 10,642 public users [as displayed on NPM][crypto-js, NPM], today October 11th 2023. The number of transient dependents is likely several orders of magnitude higher.

A very rough GitHub search[ shows 432 files][GitHub search: affected files] cross GitHub using PBKDF2 in crypto-js in Typescript or JavaScript, but not specifying any number of iterations.

[OWASP PBKDF2 Cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2 "OWASP PBKDF2 Cheatsheet"
[crypto-js, NPM]: https://www.npmjs.com/package/crypto-js "crypto-js on NPM"
[GitHub search: affected files]: https://github.com/search?q=%22crypto-js%22+AND+pbkdf2+AND+%28lang%3AJavaScript+OR+lang%3ATypeScript%29++NOT+%22iterations%22&type=code&p=2 "GitHub search: crypto-js AND pbkdf2 AND (lang:JavaScript OR lang:TypeScript)  NOT iterations"

#### Affected versions
All versions are impacted. This code has been the same since crypto-js was first created.

#### Further Cryptanalysis

The issue here is especially egregious because the length extension attack makes useless any secret that might be appended to the plaintext before calculating its signature.

Consider a scheme in which a secret is created for a user's username, and that secret is used to protect e.g. their passwords. Let's say that password is 'fake-password', and their username is 'example-username'.

To encrypt the user password via symmetric encryption we might do `encrypt(plaintext: 'fake-password', encryption_key: cryptojs.pbkdf2(value: 'example username' + salt_or_pepper))`. By this means, we would, in theory, create an `encryption_key` that can be determined from the public username, but which requires the secret `salt_or_pepper` to generate. This is a common scheme for protecting passwords, as exemplified in bcrypt & scrypt. Because the encryption key is symmetric, we can use this derived key to also decrypt the ciphertext.

Because of the length extension issue, if the attacker obtains (via attack 1), a collision with 'example username', the attacker _does not need to know_ `salt_or_pepper` to decrypt their account data, only their public username.

### Description

PBKDF2 is a key-derivation is a key-derivation function that is used for two main purposes: (1) to stretch or squash a variable length password's entropy into a fixed size for consumption by another cryptographic operation and (2) to reduce the chance of downstream operations recovering the password input (for example, for password storage).

Unlike the modern [webcrypto](https://w3c.github.io/webcrypto/#pbkdf2-operations) standard, crypto-js does not throw an error when a number of iterations is not specified, and defaults to one single iteration. In the year 2000, when PBKDF2 was originally specified, the minimum number of iterations suggested was set at 1,000. Today, [OWASP recommends 1,300,000][OWASP PBKDF2 Cheatsheet]:

https://github.com/brix/crypto-js/blob/4dcaa7afd08f48cd285463b8f9499cdb242605fa/


crypto-es PBKDF2 1,000 times weaker than specified in 1993 and 1.3M times weaker than current standard

[Severity: CRITICAL]

### Impact
#### Summary
Crypto-js PBKDF2 is 1,000 times weaker than originally specified in 1993, and [at least 1,300,000 times weaker than current industry standard][OWASP PBKDF2 Cheatsheet]. This is because it both (1) defaults to [SHA1][SHA1 wiki], a cryptographic hash algorithm considered insecure [since at least 2005][Cryptanalysis of SHA-1] and (2) defaults to [one single iteration][one iteration src], a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to [preimage][preimage attack] and [collision][collision attack] attacks. Remediation of this issue might be very difficult, as the changes required to fix this issue would change the output of this method and thus break most, if not all, current uses of this method as configured by default.

Potential Impact:

1. If used to protect passwords, the impact is high.
2. If used to generate signatures, the impact is high.

Probability / risk analysis / attack enumeration:

1. [For at most $45,000][SHA1 is a Shambles], an attacker, given control of only the beginning of a crypto-js PBKDF2 input, can create a value which has _identical cryptographic signature_ to any chosen known value.
4. Due to the [length extension attack] on SHA1, we can create a value that has identical signature to any _unknown_ value, provided it is prefixed by a known value. It does not matter if PBKDF2 applies '[salt][cryptographic salt]' or '[pepper][cryptographic pepper]' or any other secret unknown to the attacker. It will still create an identical signature.

[cryptographic salt]: https://en.wikipedia.org/wiki/Salt_(cryptography) "Salt (cryptography), Wikipedia"
[cryptographic pepper]: https://en.wikipedia.org/wiki/Pepper_(cryptography) "Pepper (cryptography), Wikipedia"
[SHA1 wiki]: https://en.wikipedia.org/wiki/SHA-1 "SHA-1, Wikipedia"
[Cryptanalysis of SHA-1]: https://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html "Cryptanalysis of SHA-1"
[one iteration src]: https://github.com/brix/crypto-js/blob/1da3dabf93f0a0435c47627d6f171ad25f452012/src/pbkdf2.js#L22-L26 "crypto-js/src/pbkdf2.js lines 22-26"
[collision attack]: https://en.wikipedia.org/wiki/Hash_collision "Collision Attack, Wikipedia"
[preimage attack]: https://en.wikipedia.org/wiki/Preimage_attack "Preimage Attack, Wikipedia"
[SHA1 is a Shambles]: https://eprint.iacr.org/2020/014.pdf "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1
and Application to the PGP Web of Trust, Gaëtan Leurent and Thomas Peyrin"
[Length Extension attack]: https://en.wikipedia.org/wiki/Length_extension_attack "Length extension attack, Wikipedia"

crypto-js has 10,642 public users [as displayed on NPM][crypto-js, NPM], today October 11th 2023. The number of transient dependents is likely several orders of magnitude higher.

A very rough GitHub search[ shows 432 files][GitHub search: affected files] cross GitHub using PBKDF2 in crypto-js in Typescript or JavaScript, but not specifying any number of iterations.

[OWASP PBKDF2 Cheatsheet]: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2 "OWASP PBKDF2 Cheatsheet"
[crypto-js, NPM]: https://www.npmjs.com/package/crypto-js "crypto-js on NPM"
[GitHub search: affected files]: https://github.com/search?q=%22crypto-js%22+AND+pbkdf2+AND+%28lang%3AJavaScript+OR+lang%3ATypeScript%29++NOT+%22iterations%22&type=code&p=2 "GitHub search: crypto-js AND pbkdf2 AND (lang:JavaScript OR lang:TypeScript)  NOT iterations"

#### Affected versions
All versions are impacted. This code has been the same since crypto-js was first created.

#### Further Cryptanalysis

The issue here is especially egregious because the length extension attack makes useless any secret that might be appended to the plaintext before calculating its signature.

Consider a scheme in which a secret is created for a user's username, and that secret is used to protect e.g. their passwords. Let's say that password is 'fake-password', and their username is 'example-username'.

To encrypt the user password via symmetric encryption we might do `encrypt(plaintext: 'fake-password', encryption_key: cryptojs.pbkdf2(value: 'example username' + salt_or_pepper))`. By this means, we would, in theory, create an `encryption_key` that can be determined from the public username, but which requires the secret `salt_or_pepper` to generate. This is a common scheme for protecting passwords, as exemplified in bcrypt & scrypt. Because the encryption key is symmetric, we can use this derived key to also decrypt the ciphertext.

Because of the length extension issue, if the attacker obtains (via attack 1), a collision with 'example username', the attacker _does not need to know_ `salt_or_pepper` to decrypt their account data, only their public username.

### Description

PBKDF2 is a key-derivation function that is used for two main purposes: (1) to stretch or squash a variable length password's entropy into a fixed size for consumption by another cryptographic operation and (2) to reduce the chance of downstream operations recovering the password input (for example, for password storage).

Unlike the modern [webcrypto](https://w3c.github.io/webcrypto/#pbkdf2-operations) standard, crypto-js does not throw an error when a number of iterations is not specified, and defaults to one single iteration. In the year 1993, when PBKDF2 was originally specified, the minimum number of iterations suggested was set at 1,000. Today, [OWASP recommends 1,300,000][OWASP PBKDF2 Cheatsheet]:

https://github.com/entronad/crypto-es/blob/aa48d48413549addc06cd737a272466d5fc1b5e6/lib/pbkdf2.js#L35-L39

### Workarounds
Consult the [OWASP PBKDF2 Cheatsheet]. Configure to use SHA256 with at least 250,000 iterations.

### Coordinated disclosure
This issue was simultaneously submitted to [crypto-js](https://github.com/bri


XWiki Platform web templates vulnerable to reflected XSS in the create document form if name validation is enabled

[Severity: CRITICAL]

### Impact
When document names are validated according to a name strategy (disabled by default), XWiki is vulnerable to a reflected XSS attack in the page creation form. To reproduce, make sure that "Validate names before saving" is enabled in the administration under "Editing" -> "Name strategies" and then open `<xwiki-host>/xwiki/bin/create/Main/%3Cscript%3Ealert%28%27Test%20Test%20Test%20Test%20Test%27%29%3C%2Fscript%3E` where `<xwiki-host>` is the URL of your XWiki installation. This displays an alert if the installation is vulnerable. This allows an attacker to execute arbitrary actions with the rights of the user opening the malicious link. Depending on the rights of the user, this may allow remote code execution and full read and write access to the whole XWiki installation.

### Patches
This has been patched in XWiki 14.10.12 and 15.5-RC-1 by adding appropriate escaping.

### Workarounds
The vulnerable template file `createinline.vm` is part of XWiki's WAR and can be patched by manually applying the [changes from the fix](https://github.com/xwiki/xwiki-platform/commit/ba56fda175156dd35035f2b8c86cbd8ef1f90c2e#diff-c222148bddebe4ff7629350f4053b618504a4ab172e697938c8fddf7c1fc6bc8).


XWiki users can be tricked to execute scripts as the create page action doesn't display the page's title

[Severity: CRITICAL]

### Impact
In XWiki, it is possible to pass a title to the page creation action that isn't displayed at first but then executed in the second step. This can be used by an attacker to trick a victim to execute code, allowing script execution if the victim has script right or remote code execution including full access to the XWiki instance if the victim has programming right.

For the attack to work, the attacker needs to convince the victim to visit a link like `<xwiki-host>/xwiki/bin/create/NonExistingSpace/WebHome?title=$services.logging.getLogger(%22foo%22).error(%22Script%20executed!%22)` where `<xwiki-host>`  is the URL of the Wiki installation and to then click on the "Create" button on that page. The page looks like a regular XWiki page that the victim would also see when clicking the button to create a page that doesn't exist yet, the malicious code is not displayed anywhere on that page. After clicking the "Create" button, the malicious title would be displayed but at this point, the code has already been executed and the attacker could use this code also to hide the attack, e.g., by redirecting the victim again to the same page with an innocent title. It thus seems plausible that this attack could work if the attacker can place a fake "create page" button on a page which is possible with edit right.

### Patches
This has been patched in XWiki 14.10.2 and 15.5RC1 by displaying the title already in the first step such that the victim can notice the attack before continuing.

### Workarounds
It is possible to manually patch the modified files from the [patch](https://github.com/xwiki/xwiki-platform/commit/199e27ce7016757e66fa7cea99e718044a1b639b) in an existing installation. For the JavaScript change, the minified JavaScript file would need to be obtained from a build of XWiki and replaced accordingly.


org.xwiki.platform:xwiki-platform-office-importer vulnerable to arbitrary server side file writing from account through office converter

[Severity: CRITICAL]

### Impact

Triggering the office converter with a specially crafted file name allows writing the attachment's content to an attacker-controlled location on the server as long as the Java process has write access to that location. In particular in the combination with attachment moving, a feature introduced in XWiki 14.0, this is easy to reproduce but it also possible to reproduce in versions as old as XWiki 3.5 by uploading the attachment through the REST API which doesn't remove `/` or `\` from the filename. As the mime type of the attachment doesn't matter for the exploitation, this could e.g., be used to replace the `jar`-file of an extension which would allow executing arbitrary Java code and thus impact the confidentiality, integrity and availability of the XWiki installation. To reproduce the issue on versions since XWiki 14.0, execute the following steps:

1.  Activate the office server
2.  Upload an arbitrary file with the extension .doc, e.g., to your user profile (you can use a regular plain text file, only the extension matters).
3.  Use the attachment move feature to rename the file to ../../../../../tmp/Hello from XWiki.txt where the latter part is the location of a file you want to write on the server. The number of ../ depends on the directory depth, the provided example should work on Linux with the demo distribution.
4.  Click the "preview" link to trigger the office converter

For information how to reproduce on older versions, see the [Jira issue](https://jira.xwiki.org/browse/XWIKI-20715).

To the best of our knowledge, this attack is not possible when the office conversion process doesn't run as the code fails before the file is written.

### Patches

This vulnerability has been patched in XWiki 14.10.8 and 15.3RC1.

### Workarounds

There are no known workarounds apart from disabling the office converter.

### References

* https://jira.xwiki.org/browse/XWIKI-20715
* https://github.com/xwiki/xwiki-platform/commit/45d182a4141ff22f3ff289cf71e4669bdc714544


org.xwiki.platform:xwiki-platform-attachment-api vulnerable to Missing Authorization on Attachment Move

[Severity: HIGH]

### Impact

An attacker with edit access on any document (can be the user profile which is editable by default) can move any attachment of any other document to this attacker-controlled document. This allows the attacker to access and possibly publish any attachment of which the name is known, regardless if the attacker has view or edit rights on the source document of this attachment. Further, the attachment is deleted from the source document. This vulnerability exists since the introduction of attachment move support in XWiki 14.0 RC1.

### Patches

This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1.

### Workarounds

There is no workaround apart from upgrading to a fixed version.

### References

* https://jira.xwiki.org/browse/XWIKI-20334
* https://github.com/xwiki/xwiki-platform/commit/d7720219d60d7201c696c3196c9d4a86d0881325

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

### Attribution

This vulnerability has been reported on Intigriti by [Mete](https://www.linkedin.com/in/metehan-kalkan-5a3201199).


org.xwiki.rendering:xwiki-rendering-xml Improper Neutralization of Invalid Characters in Identifiers in Web Pages vulnerability

[Severity: CRITICAL]

### Impact
The cleaning of attributes during XHTML rendering, introduced in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid attribute names. 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||/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.

While this attribute was correctly recognized as not allowed, the attribute was still printed with a prefix `data-xwiki-translated-attribute-` without further cleaning or validation.

Note that while versions below 14.6 are not vulnerable to this particular vulnerability, they are still vulnerable to XSS through attributes in XWiki syntax, see [the corresponding advisory](https://github.com/xwiki/xwiki-rendering/security/advisories/GHSA-6gf5-c898-7rxp).

### Patches
This problem has been patched in XWiki 14.10.4 and 15.0 RC1 by removing characters not allowed in data attributes and then validating the cleaned attribute again.

### Workarounds
There are no known workarounds apart from upgrading to a version including the fix.

### References
* https://jira.xwiki.org/browse/XRENDERING-697
* https://github.com/xwiki/xwiki-rendering/commit/f4d5acac451dccaf276e69f0b49b72221eef5d2f

### 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 [XWiki Security mailing-list](mailto:security@xwiki.org)


Werkzeug DoS: High resource usage when parsing multipart/form-data containing a large part with CR/LF character at the beginning

[Severity: MEDIUM]

Werkzeug multipart data parser needs to find a boundary that may be between consecutive chunks. That's why parsing is based on looking for newline characters. Unfortunately, code looking for partial boundary in the buffer is written inefficiently, so if we upload a file that starts with CR or LF and then is followed by megabytes of data without these characters: all of these bytes are appended chunk by chunk into internal bytearray and lookup for boundary is performed on growing buffer.

This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. If many concurrent requests are sent continuously, this can exhaust or kill all available workers.


Viewing wget extractor output while logged in as an admin allows archived JS to execute in the admins context

[Severity: HIGH]

### Impact

Any users who are using the `wget` or `dom` extractors and view the content they output.

The impact is potentially severe if you are logged in to the ArchiveBox admin site in the same browser session and view an archived malicious page designed to target your ArchiveBox instance. Malicious JS could potentially act using your logged-in admin credentials and add/remove/modify snapshots, add/remove/modify ArchiveBox users, and generally do anything an admin user could do.

The impact is less severe for non-logged-in users, as malicious JS cannot *modify* any archives, but it can still *read* all the other archived content by fetching the snapshot index and iterating through it.

Because all of ArchiveBox's archived content is served from the same host and port as the admin panel, when archived pages are viewed the JS executes in the same context as all the other archived pages (and the admin panel), defeating most of the browser's usual CORS/CSRF security protections and leading to this issue.

### Patches

Follow here for progress on mitigating this issue: https://github.com/ArchiveBox/ArchiveBox/issues/239

### Workarounds

Disable the risky extractors by setting [`archivebox config --set SAVE_WGET=False SAVE_DOM=False`](https://github.com/ArchiveBox/ArchiveBox/wiki/Configuration#save_wget), ensure you are always logged out, or serve only a [static HTML version](https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive#2-export-and-host-it-as-static-html) of your archive.

### References

- https://en.wikipedia.org/wiki/Cross-site_request_forgery
- https://github.com/ArchiveBox/ArchiveBox#caveats
- https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview
- https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive#security-concerns


XWiki Identity Oauth Privilege escalation (PR)/remote code execution from login screen through unescaped URL parameter

[Severity: CRITICAL]

### Impact

When login via the OAuth method, the identityOAuth parameters, sent in a GET request is vulnerable to XSS and XWiki syntax injection. This allows remote code execution via the groovy macro and thus affects the confidentiality, integrity and availability of the whole XWiki installation.

The vulnerability is in [this part](https://github.com/xwikisas/identity-oauth/blob/master/ui/src/main/resources/IdentityOAuth/LoginUIExtension.vm#L58) of the code.

### Patches
The issue has been fixed in Identity OAuth version 1.6 by https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6 . The fix is in the content of the [IdentityOAuth/LoginUIExtension](https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6#diff-2ab2e0716443d790d7d798320e4a45151661f4eca5440331f4a227b29c87c188) file

### Workarounds
There are no known workarounds besides upgrading.

### References
_Are there any links users can visit to find out more?_

* Original report: https://jira.xwiki.org/browse/XWIKI-20719


OpenTelemetry-Go Contrib vulnerable to denial of service in otelhttp due to unbound cardinality metrics

[Severity: HIGH]

### Summary

This handler wrapper https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65
out of the box adds labels

- `http.user_agent`
- `http.method`

that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it.

### Details

HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses [httpconv.ServerRequest](https://github.com/open-telemetry/opentelemetry-go/blob/v1.12.0/semconv/internal/v2/http.go#L159) that records every value for HTTP [method](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b896/semconv/internal/v2/http.go#L204) and [User-Agent](https://github.com/open-telemetry/opentelemetry-go/blob/38e1b499c3da3107694ad2660b3888eee9c8b896/semconv/internal/v2/http.go#L223).

### PoC

Send many requests with long randomly generated HTTP methods or/and User agents (e.g. a million) and observe how memory consumption increases during it.

### Impact

In order to be affected, the program has to configure a metrics pipeline, use [otelhttp.NewHandler](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/5f7e6ad5a49b45df45f61a1deb29d7f1158032df/instrumentation/net/http/otelhttp/handler.go#L63-L65) wrapper, and does not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc.

### Others

It is similar to already reported vulnerabilities
- https://github.com/open-telemetry/opentelemetry-go-contrib/security/advisories/GHSA-5r5m-65gx-7vrh ([open-telemetry/opentelemetry-go-contrib](https://github.com/open-telemetry/opentelemetry-go-contrib))
- https://github.com/advisories/GHSA-cg3q-j54f-5p7p ([prometheus/client_golang](https://github.com/prometheus/client_golang))

### Workaround for affected versions

As a workaround to stop being affected [otelhttp.WithFilter()](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp/filters) can be used, but it requires manual careful configuration to not log certain requests entirely.

For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.

The other possibility is to disable HTTP metrics instrumentation by passing [`otelhttp.WithMeterProvider`](https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp#WithMeterProvider) option with [`noop.NewMeterProvider`](https://pkg.go.dev/go.opentelemetry.io/otel/metric/noop#NewMeterProvider).

### Solution provided by upgrading

In PR https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277, released with package version 0.44.0, the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed.

### References

- https://github.com/open-telemetry/opentelemetry-go-contrib/pull/4277
- https://github.com/open-telemetry/opentelemetry-go-contrib/releases/tag/v1.19.0


Apache Airflow vulnerable to sensitive information exposure when expose-config is set to non-sensitive-only

[Severity: MEDIUM]

Apache Airflow, versions 2.7.0 and 2.7.1, is affected by a vulnerability that allows an authenticated user to retrieve sensitive configuration information when the `expose_config` option is set to `non-sensitive-only`. The `expose_config` option is `False` by default. It is recommended to upgrade to a version that is not affected.


pyminizip affected by zlib's integer overflow/heap based buffer overflow vulnerability due to vulnerable dependency

[Severity: CRITICAL]

MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product.

pyminizip uses version 1.2.11 of zlib's code.


Denial of service vulnerability on creating a Launch with too many recursively nested elements in reportportal

[Severity: MEDIUM]

### Impact
ReportPortal database becomes unstable and reporting almost fully stops except for small launches with approximately 1 test inside when the test_item.path field is exceeded the allowable "ltree" field type indexing limit (path length>=120 approximately, recursive nesting of the nested steps).

REINDEX INDEX path_gist_idx and path_idx aren't helped.

### Patches
The problem was fixed in `service-api` module of version `5.10.0` (product release [23.2](https://reportportal.io/docs/releases/Version23.2/)), where the maximum number of nested elements were programmatically limited.

### Workarounds
After deletion of the data with long paths, and reindexing both indexes (path_gist_idx and path_idx), the database becomes stable and ReportPortal is working properly.


langchain_experimental vulnerable to arbitrary code execution via PALChain in the python exec method

[Severity: CRITICAL]

langchain_experimental (aka LangChain Experimental) in LangChain before 0.0.306 allows an attacker to bypass the CVE-2023-36258 fix and execute arbitrary code via __import__ in Python code, which is not prohibited by pal_chain/base.py.


Soft Serve Public Key Authentication Bypass Vulnerability when Keyboard-Interactive SSH Authentication is Enabled

[Severity: HIGH]

### Impact

A security vulnerability in Soft Serve could allow an unauthenticated, remote attacker to bypass public key authentication when keyboard-interactive SSH authentication is active, through the `allow-keyless` setting, and the public key requires additional client-side verification for example using FIDO2 or GPG. This is due to insufficient validation procedures of the public key step during SSH request handshake, granting unauthorized access if the keyboard-interaction mode is utilized. An attacker could exploit this vulnerability by presenting manipulated SSH requests using keyboard-interactive authentication mode. This could potentially result in unauthorized access to the Soft Serve.

### Patches

Users should upgrade to the latest Soft Serve version `v0.6.2` to receive the patch for this issue.

### Workarounds

To workaround this vulnerability without upgrading, users can _temporarily_ disable Keyboard-Interactive SSH Authentication using the `allow-keyless` setting.

### References

https://github.com/charmbracelet/soft-serve/issues/389


snappy-java's missing upper bound check on chunk length can lead to Denial of Service (DoS) impact

[Severity: HIGH]

### Summary

snappy-java is a data compression library in Java. Its SnappyInputStream was found to be vulnerable to Denial of Service (DoS) attacks when decompressing data with a too-large chunk size. Due to missing upper bound check on chunk length, an unrecoverable fatal error can occur.

### Scope

All versions of snappy-java including the latest released version 1.1.10.3.  A fix is applied in 1.1.10.4

### Details
While performing mitigation efforts related to [CVE-2023-34455](https://nvd.nist.gov/vuln/detail/CVE-2023-34455) in Confluent products, our Application Security team closely analyzed the fix that was accepted and merged into snappy-java version 1.1.10.1 in [this](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea) commit. The check on [line 421](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR421) only attempts to check if chunkSize is not a negative value. We believe that this is an inadequate fix as it misses an upper-bounds check for overly positive values such as 0x7FFFFFFF (or (2,147,483,647 in decimal) before actually [attempting to allocate](https://github.com/xerial/snappy-java/commit/3bf67857fcf70d9eea56eed4af7c925671e8eaea#diff-c3e53610267092989965e8c7dd2d4417d355ff7f560f9e8075b365f32569079fR429) the provided unverified number of bytes via the “chunkSize” variable. This missing upper-bounds check can lead to the applications depending upon snappy-java to allocate an inappropriate number of bytes on the heap which can then cause an  java.lang.OutOfMemoryError exception. Under some specific conditions and contexts, this can lead to a Denial-of-Service (DoS) attack with a direct impact on the availability of the dependent implementations based on the usage of the snappy-java library for compression/decompression needs.

### PoC
Compile and run the following code:
```
package org.example;
import org.xerial.snappy.SnappyInputStream;

import java.io.*;

public class Main {

    public static void main(String[] args) throws IOException {
        byte[] data = {-126, 'S', 'N', 'A', 'P', 'P', 'Y', 0, 0, 0, 0, 0, 0, 0, 0, 0,(byte) 0x7f, (byte) 0xff, (byte) 0xff, (byte) 0xff};
        SnappyInputStream in = new SnappyInputStream(new ByteArrayInputStream(data));
        byte[] out = new byte[50];
        try {
            in.read(out);
        }
        catch (Exception ignored) {
        }
    }
}
```

### Impact
Denial of Service of applications dependent on snappy-java especially if `ExitOnOutOfMemoryError` or `CrashOnOutOfMemoryError` is configured on the JVM.

### Credits
Jan Werner, Mukul Khullar and Bharadwaj Machiraju from Confluent's Application Security team.

We kindly request for a new CVE ID to be assigned once you acknowledge this vulnerability.


Croc sender may place ANSI or CSI escape sequences in filename to attach receiver's terminal device

[Severity: HIGH]

An issue was discovered in Croc before 9.6.16. A sender may place ANSI or CSI escape sequences in a filename to attack the terminal device of a receiver.


Dolibarr allows a remote privileged attacker to execute arbitrary code via a crafted command/script

[Severity: HIGH]

An issue in Dolibarr ERP CRM v.17.0.1 and before allows a remote privileged attacker to execute arbitrary code via a crafted command/script.


RKE2 supervisor port is vulnerable to unauthenticated remote denial-of-service (DoS) attack via TLS SAN stuffing attack

[Severity: HIGH]

### Impact

An issue was found in RKE2 where an attacker with network access to RKE2 servers' supervisor port (TCP 9345) can force the TLS server to add entries to the certificate's Subject Alternative Name (SAN) list, through a stuffing attack, until the certificate grows so large that it exceeds the maximum size allowed by TLS client implementations. OpenSSL for example will raise an `excessive message size` error when this occurs. No authentication is necessary to perform this attack, only the ability to perform a TLS handshake against the supervisor port (TCP 9345).

Affected servers will continue to operate, but clients (server or agent nodes) will fail to establish new connections when joining or rejoining the cluster, thus leading to a denial of service (DoS) attack.

### Remediation

Upgrade to a fixed release:
- v1.28.1+rke2r1
- v1.27.5+rke2r1
- v1.26.8+rke2r1
- v1.25.13+rke2r1
- 1.24.17+rke2r1

If you are using RKE2 1.27 or earlier, you must also add the parameter `tls-san-security: true` to the RKE2 configuration to enable enhanced security for the supervisor's TLS SAN list. This option defaults to `true` starting with RKE2 1.28.

Note that this flag changes the behavior of RKE2's supervisor listener. You should ensure that you configure `node-external-ip` on servers that will be connected to via an external IP, and add `tls-san` entries for any load-balancers or VIP addresses that will be associated with the supervisor port. External IPs and load-balancer/VIP addresses will no longer be added to the supervisor certificate's SAN list unless explicitly configured.

### Mitigation

If you cannot upgrade to a fixed release, the certificate can be "frozen" by running the following command against the cluster:

```shell
kubectl annotate secret -n kube-system rke2-serving listener.cattle.io/static=true
```

**⚠ IMPORTANT CAUTION:** Note that this mitigation will prevent the certificate from adding new SAN entries when servers join the cluster, and automatically renewing itself when it is about to expire. If you do this, you should delete the annotation when adding new servers to the cluster, or when the certificate is within 90 days of expiring, so that it can be updated. Once that is done, you can freeze it again.

Affected certificates can be reset by performing the following steps:
* Run `kubectl delete secret -n kube-system rke2-serving`
* Delete `/var/lib/rancher/rke2/server/tls/dynamic-cert.json` from all servers, and restart the `rke2-server` service.

### Background

The RKE2 supervisor listens on port TCP 9345 and uses the `rancher/dynamiclistener` library to dynamically generate TLS certificates that contain TLS Subject Alternative Names (SAN) for any host name or IP address requested by a client. This is done to allow servers and external load-balancers to be added to the cluster without the administrator having to explicitly know and configure in advance a fixed list of endpoints that the supervisor may be hosted at.

The library allows the embedding application to configure a callback that is used to filter addresses requested by clients; but this was not previously implemented in RKE2.

### For more information

If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rke2/security/policy) for security related inquiries.
- Open an issue in the [RKE2](https://github.com/rancher/rke2/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).


K3s apiserver port is vulnerable to unauthenticated remote denial-of-service (DoS) attack via TLS SAN stuffing attack

[Severity: HIGH]

### Impact

An issue was found in K3s where an attacker with network access to K3s servers' apiserver/supervisor port (TCP 6443) can force the TLS server to add entries to the certificate's Subject Alternative Name (SAN) list, through a stuffing attack, until the certificate grows so large that it exceeds the maximum size allowed by TLS client implementations. OpenSSL for example will raise an `excessive message size` error when this occurs. No authentication is necessary to perform this attack, only the ability to perform a TLS handshake against the apiserver/supervisor port (TCP 6443).

Affected servers will continue to operate, but clients (including both external administrative access with `kubectl` and server or agent nodes) will fail to establish new connections, thus leading to a denial of service (DoS) attack.

### Remediation

Upgrade to a fixed release:

- v1.28.1+k3s1
- v1.27.5+k3s1
- v1.26.8+k3s1
- v1.25.13+k3s1
- v1.24.17+k3s1

If you are using K3s 1.27 or earlier, you must also add  the parameter `tls-san-security: true` to the K3s configuration to enable enhanced security for the supervisor's TLS SAN list. This option defaults to `true` starting with K3s 1.28.

Note that this flag changes the behavior of K3s servers. You should ensure that you configure `node-external-ip` on servers that will be connected to via an external IP, and add `tls-san` entries for any load-balancers or VIP addresses that will be associated with the supervisor port. External IPs and load-balancer/VIP addresses will no longer be added to the supervisor certificate's SAN list unless explicitly configured.

### Mitigation

If you cannot upgrade to a fixed release, the certificate can be "frozen" by running the following command against the cluster:

```shell
kubectl annotate secret -n kube-system k3s-serving listener.cattle.io/static=true
```

**⚠ IMPORTANT CAUTION:** Note that this mitigation will prevent the certificate from adding new SAN entries when servers join the cluster, and automatically renewing itself when it is about to expire. If you do this, you should delete the annotation when adding new servers to the cluster, or when the certificate is within 90 days of expiring, so that it can be updated. Once that is done, you can freeze it again.

Affected certificates can be reset by performing the following steps:
1. Run `kubectl --server https://localhost:6444 delete secret -n kube-system k3s-serving`
2. Delete `/var/lib/rancher/k3s/server/tls/dynamic-cert.json` from all servers, and restart the `k3s` service.

### Background

The K3s apiserver/supervisor listener on port TCP 6443 and uses the `rancher/dynamiclistener` library to dynamically generate TLS certificates that contain TLS Subject Alternative Names (SAN) for any host name or IP address requested by a client. This is done to allow servers and external load-balancers to be added to the cluster without the administrator having to explicitly know and configure in advance a fixed list of endpoints that the supervisor may be hosted at.

The library allows the embedding application to configure a callback that is used to filter addresses requested by clients; but this was not previously implemented in K3s.

### For more information

If you have any questions or comments about this advisory:

- Reach out to the [K3s Security team](https://github.com/k3s-io/k3s/security/policy) for security related inquiries.
- Open an issue in the [K3s](https://github.com/k3s-io/k3s/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-k3s/support-matrix/all-supported-versions) and [product support lifecycle](https://www.suse.com/lifecycle/#k3s).


Domain restrictions bypass via DNS Rebinding in WireMock and WireMock Studio webhooks, proxy and recorder modes

[Severity: LOW]

### Impact

The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in [Preventing proxying to and recording from specific target addresses](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions.

The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact.

### Affected versions

- WireMock 3,x until 3.0.3 (security patch), on default settings in environments with access to the network
- WireMock 2.x until 2.35.1 (security patch), on default settings in environments with access to the network
- Python WireMock until 2.6.1
- WireMock Studio - all versions, this proprietary product was discontinued in 2022

### Patches

- WireMock 3.0.3 + the 3.0.3-1 Docker image
- WireMock 2.35.1 + the 2.35.1-1 Docker image - backport to WireMock 2.x
- Python WireMock 2.6.1

### Workarounds

For WireMock:

- Option 1: Configure WireMock to use IP addresses instead of the domain names in the outbound URLs subject to DNS rebinding
- Option 2: Use external firewall rules to define the list of permitted destinations

For WireMock Studio: N/A. Switch to another distribution, there will be no fix provided. The vendor of former WireMock Studio recommends migration to [WireMock Cloud](https://www.wiremock.io/product)

### References

- CVE-2023-41327 - Related issue in the WireMock Webhooks Extension


Electron's Content-Secrity-Policy disabling eval not applied consistently in renderers with sandbox disabled

[Severity: HIGH]

### Impact
A Content-Security-Policy that disables eval, specifically setting a `script-src` directive and _not_ providing `unsafe-eval` in that directive, is not respected in renderers that have sandbox and contextIsolation disabled.  i.e. `sandbox: false` and `contextIsolation: false` in the `webPreferences` object.

This resulted in incorrectly allowing usage of methods like `eval()` and `new Function`, which can result in an expanded attack surface.

### Patches
This issue only ever affected the 22 and 23 major versions of Electron and has been fixed in the latest versions of those release lines. Specifically, these versions contain the fixes:

- 22.0.1
- 23.0.0-alpha.2

We recommend all apps upgrade to the latest stable version of Electron, especially if they use `sandbox: false` or `contextIsolation: false`.

### Workarounds
If upgrading isn't possible, this issue can be addressed without upgrading by enabling at least one of `sandbox: true` or `contextIsolation: true` on all renderers.

```js
const mainWindow = new BrowserWindow({
  webPreferences: {
    sandbox: true,
  }
});
```

### For more information
If you have any questions or comments about this advisory, email us at [security@electronjs.org](mailto:security@electronjs.org).

### Credit
Thanks to user @andreasdj for reporting this issue.


Missing permission check in Jenkins AWS CodeCommit Trigger Plugin allows enumerating credentials IDs

[Severity: MEDIUM]

A missing permission check in Jenkins AWS CodeCommit Trigger Plugin 3.0.12 and earlier allows attackers with Overall/Read permission to enumerate credentials IDs of AWS credentials stored in Jenkins.


Default functions in VolatileMemory trait lack bounds checks, potentially leading to out-of-bounds memory accesses

[Severity: LOW]

### Impact
An issue was discovered in the default implementations of the `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref}` trait functions, which allows out-of-bounds memory access if the `VolatileMemory::get_slice` function returns a `VolatileSlice` whose length is less than the function’s `count` argument. No implementations of `get_slice` provided in `vm_memory` are affected. Users of custom `VolatileMemory` implementations may be impacted if the custom implementation does not adhere to `get_slice`'s documentation.

### Patches
The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the `VolatileSlice` returned by `get_slice` is of the correct length.

### Workarounds
Not Required

### References
https://github.com/rust-vmm/vm-memory/commit/aff1dd4a5259f7deba56692840f7a2d9ca34c9c8
https://crates.io/crates/vm-memory/0.12.2


Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin vulnerable to exposure of system-scoped credentials

[Severity: MEDIUM]

Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin 1.14 and earlier does not set the appropriate context for credentials lookup, allowing the use of System-scoped credentials otherwise reserved for the global configuration.

This allows attackers with Item/Configure permission to access and capture credentials they are not entitled to.

As of publication of this advisory, there is no fix.


SES's dynamic import and spread operator provides possible path to arbitrary exfiltration and execution

[Severity: CRITICAL]

### Impact

This is a hole in the confinement of guest applications under SES that may manifest as either the ability to exfiltrate information or execute arbitrary code depending on the configuration and implementation of the surrounding host.

Guest program running inside a Compartment with as few as no endowments can gain access to the surrounding host’s dynamic import by using dynamic import after the spread operator, like `{...import(arbitraryModuleSpecifier)}`.

On the web or in web extensions, a Content-Security-Policy following ordinary best practices likely mitigates both the risk of exfiltration and execution of arbitrary code, at least limiting the modules that the attacker can import to those that are already part of the application. However, without a Content-Security-Policy, dynamic import can be used to issue HTTP requests for either communication through the URL or for the execution of code reachable from that origin.

Within an XS worker, an attacker can use the host’s module system to the extent that the host has been configured. This typically only allows access to module code on the host’s file system and is of limited use to an attacker.

Within Node.js, the attacker gains access to Node.js’s module system. Importing the powerful builtins is not useful except insofar as there are side-effects and tempered because dynamic import returns a promise. Spreading a promise into an object renders the promises useless. However, Node.js allows importing data URLs, so this is a clear path to arbitrary execution.

### Patches

All affected `0.*` version trains have the following patch. Running `npm update` will obtain the patch on all affected projects using `^0.*` style dependency constraints in their `package.json`.

```diff
From 33469e88bfb2bf34a161c265f10f808ce354a700 Mon Sep 17 00:00:00 2001
From: Kris Kowal <kris@agoric.com>
Date: Thu, 27 Jul 2023 13:25:13 -0700
Subject: [PATCH] fix(fix): Censor spread import

---
 packages/ses/src/transforms.js       |  2 +-
 packages/ses/test/test-transforms.js | 22 +++++++++++++++++++++-
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/packages/ses/src/transforms.js b/packages/ses/src/transforms.js
index a0fc8d0ef..64a46cb53 100644
--- a/packages/ses/src/transforms.js
+++ b/packages/ses/src/transforms.js
@@ -106,7 +106,7 @@ export const evadeHtmlCommentTest = src => {
 // /////////////////////////////////////////////////////////////////////////////

 const importPattern = new FERAL_REG_EXP(
-  '(^|[^.])\\bimport(\\s*(?:\\(|/[/*]))',
+  '(^|[^.]|\\.\\.\\.)\\bimport(\\s*(?:\\(|/[/*]))',
   'g',
 );

diff --git a/packages/ses/test/test-transforms.js b/packages/ses/test/test-transforms.js
index cef0c02c1..8f6818b83 100644
--- a/packages/ses/test/test-transforms.js
+++ b/packages/ses/test/test-transforms.js
@@ -6,7 +6,7 @@ import {
 } from '../src/transforms.js';

 test('no-import-expression regexp', t => {
-  t.plan(9);
+  t.plan(13);

   // Note: we cannot define these as regular functions (and then stringify)
   // because the 'esm' module loader that we use for running the tests (i.e.
@@ -20,6 +20,7 @@ test('no-import-expression regexp', t => {
   const safe = 'const a = 1';
   const safe2 = "const a = notimport('evil')";
   const safe3 = "const a = importnot('evil')";
+  const safe4 = "const a = compartment.import('name')";

   const obvious = "const a = import('evil')";
   const whitespace = "const a = import ('evil')";
@@ -27,10 +28,14 @@ test('no-import-expression regexp', t => {
   const doubleSlashComment = "const a = import // hah\n('evil')";
   const newline = "const a = import\n('evil')";
   const multiline = "\nimport('a')\nimport('b')";
+  const spread = "{...import('exfil')}";
+  const spread2 = "{\n...\nimport\n('exfil')}";
+  const spread3 = "{\n...\nimport/**/\n('exfil')}";

   t.is(rejectImportExpressions(safe), safe, 'safe');
   t.is(rejectImportExpressions(safe2), safe2, 'safe2');
   t.is(rejectImportExpressions(safe3), safe3, 'safe3');
+  t.is(rejectImportExpressions(safe4), safe4, 'safe4');
   t.throws(
     () => rejectImportExpressions(obvious),
     { instanceOf: SyntaxError },
@@ -62,6 +67,21 @@ test('no-import-expression regexp', t => {
     'possible import expression rejected around line 2',
     'multiline',
   );
+  t.throws(
+    () => rejectImportExpressions(spread),
+    { instanceOf: SyntaxError },
+    'spread',
+  );
+  t.throws(
+    () => rejectImportExpressions(spread2),
+    { instanceOf: SyntaxError },
+    'spread2',
+  );
+  t.throws(
+    () => rejectImportExpressions(spread3),
+    { instanceOf: SyntaxError },
+    'spread3',
+  );
 });

 test('no-html-comment-expression regexp', t => {
--
2.40.1
```

### Workarounds

On the web, providing a suitably constrained Content-Security-Policy mitigates most of the threat.

With XS, building a binary that lacks the ability to load modules at runtime mitigates the entirety of the threat. That will look like an implementation of `fxFindModule` in a file like `xsPlatform.c` that calls `fxRejectModuleFile`.

We highly advise applying the above patch for Node.js as there is no known work-around and Node.js’s module specifiers are exceedingly powerful, including support for `data:text/javascript,` style module specifier URLs.

### References

No references at this time.


matrix-appservice-bridge doesn't verify the sub parameter of an openId token exhange, allowing unauthorized access to provisioning APIs

[Severity: MEDIUM]

### Impact

A malicious Matrix server can use a foreign user's MXID in an OpenID exchange, allowing a bad actor to impersonate users when using the provisioning API.

### Details

The library does not check that the servername part of the `sub` parameter (containing the user's *claimed* MXID) is the same as the servername we are talking to. A malicious actor could spin up a server on any given domain, respond with a `sub` parameter according to the user they want to act as and use the resulting token to perform provisioning requests.

### Workarounds

Disable the provisioning API. If the bridge does not use the provisioning API, you are not vulnerable.


matrix-appservice-irc events can be crafted to leak parts of targeted messages from other bridged rooms

[Severity: LOW]

### Impact

It was possible to craft an event such that it would leak part of a targeted message event from another bridged room. This required knowing an event ID to target.

### Patches

Please upgrade to 1.0.1.

### Workarounds

You can set the `matrixHandler.eventCacheSize` config value to `0` to workaround this bug. However, this may impact performance.

### Credits

Discovered and reported by [Val Lorentz](https://valentin-lorentz.fr/).

### For more information

If you have any questions or comments about this advisory email us at [security@matrix.org](mailto:security@matrix.org).


FFmpeg discovered to contain a code injection vulnerability in the component net.bramp.ffmpeg.FFmpeg.<constructor>

[Severity: CRITICAL]

## Withdrawn

This advisory has been withdrawn because it has been found to be disputed. Please see the issue [here](https://github.com/bramp/ffmpeg-cli-wrapper/issues/291) for more information.

## Original Despcription

FFmpeg 0.7.0 and below was discovered to contain a code injection vulnerability in the component net.bramp.ffmpeg.FFmpeg.<constructor>. This vulnerability is exploited via passing an unchecked argument.


Incorrect permission checks in Qualys Web App Scanning Connector Plugin allow capturing credentials

[Severity: MEDIUM]

Qualys Web App Scanning Connector Plugin 2.0.10 and earlier does not correctly perform permission checks in several HTTP endpoints.

This allows attackers with global Item/Configure permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Qualys Web App Scanning Connector Plugin 2.0.11 requires the appropriate permissions for the affected HTTP endpoints.


rabbitmq-connector plugin module in Apache EventMesh platforms allows attackers to send controlled message

[Severity: CRITICAL]

CWE-502 Deserialization of Untrusted Data at the rabbitmq-connector plugin module in Apache EventMesh (incubating) V1.7.0\V1.8.0 on windows\linux\mac os e.g. platforms allows attackers to send controlled message and

remote code execute via rabbitmq messages. Users can use the code under the master branch in project repo to fix this issue,  the new version is set to be released as soon as possible.


Apache RocketMQ may have remote code execution vulnerability when using update configuration function

[Severity: CRITICAL]

For RocketMQ versions 5.1.0 and below, under certain conditions, there is a risk of remote command execution.

Several components of RocketMQ, including NameServer, Broker, and Controller, are leaked on the extranet and lack permission verification, an attacker can exploit this vulnerability by using the update configuration function to execute commands as the system users that RocketMQ is running as. Additionally, an attacker can achieve the same effect by forging the RocketMQ protocol content.

To prevent these attacks, users are recommended to upgrade to version 5.1.1 or above for using RocketMQ 5.x or 4.9.6 or above for using RocketMQ 4.x .


league/oauth2-server key exposed in exception message when passing as a string and providing an invalid pass phrase

[Severity: HIGH]

### Impact
Servers that passed their keys to the CryptKey constructor as as string instead of a file path will have had that key included in a LogicException message if they did not provide a valid pass phrase for the key where required.

### Patches
This issue has been patched so that the provided key is no longer exposed in the exception message in the scenario outlined above. Users should upgrade to version 8.5.3 or 8.4.2 to receive the patch.

### Workarounds
We recommend upgrading the oauth2-server to one of the patched releases (8.5.3 or 8.4.2). If you are unable to upgrade you can avoid this security issue by passing your key as a file instead of a string.

### References
* [Fix for 8.4.x](https://github.com/thephpleague/oauth2-server/pull/1359)
* [Fix for 8.5.x](https://github.com/thephpleague/oauth2-server/pull/1353)


Sanitize vulnerable to Cross-site Scripting via insufficient neutralization of `style` element content

[Severity: HIGH]

### Impact

Using carefully crafted input, an attacker may be able to sneak arbitrary HTML and CSS through Sanitize `>= 3.0.0, < 6.0.2` when Sanitize is configured to use the built-in "relaxed" config or when using a custom config that allows `style` elements and one or more CSS at-rules. This could result in XSS (cross-site scripting) or other undesired behavior when the malicious HTML and CSS are rendered in a browser.

### Patches

Sanitize `>= 6.0.2` performs additional escaping of CSS in `style` element content, which fixes this issue.

### Workarounds

Users who are unable to upgrade can prevent this issue by using a Sanitize config that doesn't allow `style` elements, using a Sanitize config that doesn't allow CSS at-rules, or by manually escaping the character sequence `</` as `<\/` in `style` element content.

### Credit

This issue was found by @cure53 during an audit of a project that uses Sanitize and was reported by one of that project's maintainers. Thank you!


HashiCorp Boundary Workers Store Rotated Credentials in Plaintext Even When Key Management Service Configured

[Severity: HIGH]

HashiCorp Boundary from 0.10.0 through 0.11.2 contain an issue where when using a PKI-based worker with a Key Management Service (KMS) defined in the configuration file, new credentials created after an automatic rotation may not have been encrypted via the intended KMS. This would result in the credentials being stored in plaintext on the Boundary PKI worker’s disk. This issue is fixed in version 0.12.0.