ghsa

An issue was discovered in Mellium mellium.im/sasl before 0.3.1. When performing SCRAM-based SASL authentication, if the remote end advertises support for channel binding, no random nonce is generated (instead, the nonce is empty). This causes authentication to fail in the best case, but (if paired with a remote end that does not validate the length of the nonce) could lead to insufficient randomness being used during authentication.

Argument Injection in GitHub repository froxlor/froxlor prior to 2.0.0-beta1.

### Impact If you are using the **Apiman Vert.x Gateway** prior to Apiman 3.0.0.Final, a connection caching issue in Hazelcast could allow an unauthenticated, remote attacker to access and manipulate data in the cluster with another authenticated connection's identity. Hazelcast is a transitive dependency of the Apiman Vert.x Gateway. The precise risk is difficult to quantify at this juncture as plugins deployed by users may make use of Hazelcast in a different manner to the main Apiman codebase. If any of your custom Apiman plugins specify Hazelcast dependencies, you should also bump these versions. Hint: an easy way to track Apiman dependency versions is to use `apiman-parent`. If you use the Apiman Tomcat or WildFly Gateway this does not affect you. ### Patches Upgrade to **Apiman 3.0.0.Final or later**. If you are using an older version of Apiman and need to remain on that version, contact to your Apiman support provider for advice/long-term support. ### Workarounds Non...

Improper Handling of Insufficient Permissions or Privileges in GitHub repository usememos/memos prior to 0.9.1.

### Summary MeterSphere allow users to upload file, but not check the file name, may lead to upload file to any path if the file name in upload request is falsified. ### Details Metersphere's [`FileUtils.java`](https://github.com/metersphere/metersphere/blob/v2.5.0/framework/sdk-parent/sdk/src/main/java/io/metersphere/commons/utils/FileUtils.java#L57) didn't check the filePath. ```java public static void createFile(String filePath, byte[] fileBytes) { File file = new File(filePath); if (file.exists()) { file.delete(); } try { File dir = file.getParentFile(); if (!dir.exists()) { dir.mkdirs(); } file.createNewFile(); } catch (Exception e) { LogUtil.error(e); } try (InputStream in = new ByteArrayInputStream(fileBytes); OutputStream out = new FileOutputStream(file)) { final int MAX = 4096; byte[] buf = new byte[MAX...

In function `Table::as_ref`, a reference of vector is force cast to slice. There are multiple problems here: 1. To guarantee the size is correct, we have to first do `Vec::shrink_to_fit`. The function requires a mutable reference, so we have to force cast from immutable to mutable, which is undefined behavior (UB). 2. Even if (1) is sound, `&Vec<T>` and `&[T]` still might not have the same layout. Treating them equally may lead to undefinted behavior (UB).

### Impact The vulnerability may allow a remote attacker to terminate the application with a stack overflow error resulting in a denial of service only by manipulating the processed input stream. ### Patches XStream 1.4.20 handles the stack overflow and raises an InputManipulationException instead. ### Workarounds The only solution is to catch the StackOverflowError in the client code calling XStream. ### References See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for [CVE-2022-40151](https://x-stream.github.io/CVE-2022-40151.html). ### Credits The vulnerability was discovered and reported by Henry Lin of the Google OSS-Fuzz team. ### For more information If you have any questions or comments about this advisory: * Open an issue in [XStream](https://github.com/x-stream/xstream/issues) * Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)

### Impact A potential race condition issue exists within the Amazon EFS mount helper in efs-utils versions v1.34.3 and below, and aws-efs-csi-driver versions v1.4.7 and below. When using TLS to mount file systems, the mount helper allocates a local port for stunnel to receive NFS connections prior to applying the TLS tunnel. In affected versions, concurrent mount operations can allocate the same local port, leading to either failed mount operations or an inappropriate mapping from an EFS customer’s local mount points to that customer’s EFS file systems. Affected versions: efs-utils <= v1.34.3, aws-efs-csi-driver <= v1.4.7 ### Patches The patches are included in efs-utils version v1.34.4 and newer, and in aws-efs-csi-driver v1.4.8 and newer. ### Workarounds There is no recommended work around. We recommend affected users update the installed version of efs-utils to v1.34.4+ or aws-efs-csi-driver to v1.4.8+ to address this issue. ### References https://github.com/aws/efs-utils/commi...

When `hyper-staticfile` performs a redirect for a directory request (e.g. a request for `/dir` that redirects to `/dir/`), the `Location` header value was derived from user input (the request path), simply appending a slash. The intent was to perform an origin-relative redirect, but specific inputs allowed performing a scheme-relative redirect instead. An attacker could craft a special URL that would appear to be for the correct domain, but immediately redirects to a malicious domain. Such a URL can benefit phishing attacks, for example an innocent looking link in an email.

### Impact Processing issue, nodes are affected when trying to process a cross-shard relayed transaction with a smart contract deploy transaction data. The problem was a bad correlation between the transaction caches and the processing component. If the above-mentioned transaction was sent with more gas than required, the smart contract result (SCR transaction) that should have returned the leftover gas, would have been wrongly added to a cache that the processing unit did not consider. The node stopped notarizing metachain blocks. The fix was actually to extend the SCR transaction search in all other caches if it wasn't found in the correct (expected) sharded-cache. ### Patches All versions >= v1.3.50 will contain this patch ### Workarounds For the moment there is no workaround ### References N/A ### For more information If you have any questions or comments about this advisory: * Open an issue in [elrond-go main repo](https://github.com/ElrondNetwork/elrond-go)