ghsa

Excessive directory permissions in MLflow leads to local privilege escalation when using spark_udf. This behavior can be exploited by a local attacker to gain elevated permissions by using a ToCToU attack. The issue is only relevant when the spark_udf() MLflow API is called.

An issue in the upload_documents method of libre-chat v0.0.6 allows attackers to execute a path traversal via supplying a crafted filename in an uploaded file.

A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.

A bug introduced in rustls 0.23.13 leads to a panic if the received TLS ClientHello is fragmented. Only servers that use `rustls::server::Acceptor::accept()` are affected. Servers that use `tokio-rustls`'s `LazyConfigAcceptor` API are affected. Servers that use `tokio-rustls`'s `TlsAcceptor` API are not affected. Servers that use `rustls-ffi`'s `rustls_acceptor_accept` API are affected.

### Summary "Unsanitized input from *the request URL* flows into `end`, where it is used to render an HTML page returned to the user. This may result in a Cross-Site Scripting attack (XSS)." ### Details Source of potentially tainted data is in `packages/kit/src/exports/vite/dev/index.js`, line 437. This potentially tainted data is passed through a number of steps (which I could detail if you'd like) all the way down to line 91 in `packages/kit/src/exports/vite/utils.js`, which performs an operation that Snyk believes an attacker shouldn't be allowed to manipulate. Another source of potentially tainted data (according to Snyk) comes from `‎packages/kit/src/exports/vite/utils.js`, line 30, col 30 (i.e., the `url` property of `req`). This potentially tainted data is passed through a number of steps (which I could detail if you'd like) all the way down line 91 in `packages/kit/src/exports/vite/utils.js`, which performs an operation that Snyk believes an attacker shouldn't be allowed to...

### Summary The static error.html template for errors contains placeholders that are replaced without escaping the content first. ### Details From https://kit.svelte.dev/docs/errors: > error.html is the page that is rendered when everything else fails. It can contain the following placeholders: %sveltekit.status% — the HTTP status %sveltekit.error.message% — the error message This leads to possible injection if an app explicitly creates an error with a message that contains user controlled content that ends up being something like this inside a server handle function: ```js error(500, '<script>alert("boom")</script>'); ``` Uncaught errors cannot be exploited like this, as they always render the message "Internal error". Escaping the message string in the function that creates the html output can be done to improve safety for applications that are using custom errors on the server. ### PoC None provided ### Impact Only applications where user provided input is used in the `Er...

### Summary In versions of `dawidd6/action-download-artifact` before v6, a repository's forks were also searched by default when attempting to find matching artifacts. This could be exploited by an unprivileged attacker to introduce compromised artifacts (such as malicious executables) into a privileged workflow context, as creating a fork requires no privileges. Users should immediately upgrade to v6 or newer, which changes the default behavior to avoid searching forks for matching artifacts. Users who cannot upgrade should explicitly set `allow_forks: false` to disable searching forks for artifacts. ### Details GitHub's artifact storage for workflows does not natively distinguish between artifacts created by a repository and artifacts created by forks of that repository. As a result, attempting to retrieve the "latest" artifact for a workflow run can return artifacts produced by a fork, rather than its upstream. Because any GitHub user can create a fork of a public repository, ...

Coinbase researchers reported 2 security issues in our implementation of the oblivious transfer (OT) based protocol [DKLS](https://eprint.iacr.org/2018/499.pdf): ### 1. Secret share recovery attack If the base OT setup of the protocol is reused for another execution of the OT extension, then a malicious participant can extract a bit of the secret of another participant. By repeating the execution they can eventually recover the whole secret. Therefore, unlike our comments suggested, you **must not reuse an OT setup** for multiple protocol executions. We're adding a warning in the code: https://github.com/taurushq-io/multi-party-sig/blob/9e4400fccee89be6195d0a12dd0ed052288d5040/internal/ot/extended.go#L114 ### 2. Invalid security proof due to incorrect operator The original 2018 version of the DKLS had a typo in the OT extension protocol when computing the check value in the OT extension: the paper noted a XOR whereas it should be a field multiplication. This erroneous behavior ...

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-jgwc-jh89-rpgq. This link is maintained to preserve external references. ## Original Description A vulnerability was found in the Keycloak Server. The Keycloak Server is vulnerable to a denial of service (DoS) attack due to improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This issue can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers.

A flaw was found in OpenShift Console. A Server Side Request Forgery (SSRF) attack can happen if an attacker supplies all or part of a URL to the server to query. The server is considered to be in a privileged network position and can often reach exposed services that aren't readily available to clients due to network filtering. Leveraging such an attack vector, the attacker can have an impact on other services and potentially disclose information or have other nefarious effects on the system. The /api/dev-console/proxy/internet endpoint on the OpenShit Console allows authenticated users to have the console's pod perform arbitrary and fully controlled HTTP(s) requests. The full response to these requests is returned by the endpoint. While the name of this endpoint suggests the requests are only bound to the internet, no such checks are in place. An authenticated user can therefore ask the console to perform arbitrary HTTP requests from outside the cluster to a service inside the cluste...