ghsa

### Impact The route used for file downloads allows specifying the name of the downloaded file. This is an unintended side effect of the implementation, and means one could construct download URLs with filenames that have no relation to the actual file, which could lead to misunderstandings and confusion, and possibly other harm. As such it is a low severity vulnerability. It affects all supported versions of Ibexa DXP and eZ Platform, in installations where downloadable files exist. ### Patches The issue is fixed in all supported versions of ezsystems/ezpublish-kernel, see "Patched versions". An advisory is also published for ezsystems/ezplatform-kernel and ibexa/core, please see those repositories. Commit: https://github.com/ezsystems/ezpublish-kernel/commit/142152f9bae4c4835713df0bdfe22bc98d03f9a1 ### Workarounds None, other than blocking all downloads. ### References https://developers.ibexa.co/security-advisories/ibexa-sa-2023-005-vulnerabilities-in-solr-search-and-file-downloa...

Kubernetes is vulnerable to privilege escalation when a user that can create pods on Windows nodes running kubernetes-csi-proxy may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes running kubernetes-csi-proxy.

Subrion 4.2.1 has a remote command execution vulnerability in the backend.

In Eclipse Parsson before versions 1.1.4 and 1.0.5, Parsing JSON from untrusted sources can lead malicious actors to exploit the fact that the built-in support for parsing numbers with large scale in Java has a number of edge cases where the input text of a number can lead to much larger processing time than one would expect. To mitigate the risk, parsson put in place a size limit for the numbers as well as their scale.

In Eclipse Glassfish 5 or 6, running with old versions of JDK (lower than 6u211, or < 7u201, or < 8u191), allows remote attackers to load malicious code on the server via access to insecure ORB listeners.

In Django 3.2 before 3.2.22, 4.1 before 4.1.12, and 4.2 before 4.2.6, the django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

An issue was discovered in Pillow before 10.0.0. It is a Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.

In Django 3.2 before 3.2.21, 4.1 before 4.1.11, and 4.2 before 4.2.5, django.utils.encoding.uri_to_iri() is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.

Dromara Lamp-Cloud before v3.8.1 was discovered to use a hardcoded cryptographic key when creating and verifying a Json Web Token. This vulnerability allows attackers to authenticate to the application via a crafted JWT token.

There is a potential SSRF vulnerability in foodcoopshop. Since there is no security policy on your Github, I tried to use the emails to contact you. The potential issue is in the Network module, where a manufacturer account can use the /api/updateProducts.json endpoint to make the server send a request to arbitrary host. For example, use ``` data[data][0][remoteProductId]=352&data[data][0][image]=http://localhost:8888/ ``` will make the server send a request to localhost:8888. This means that it can be used as a proxy into the internal network where the server is. To make matters worse, the checks on valid image is not enough. There is time of check time of use issue there. For example, by using a custom server that returns 200 on HEAD requests, then return a valid image on first GET request and then a 302 redirect to final target on second GET request, the server will copy whatever file at the redirect destination, making this a full SSRF. (An example python server that can do this ...