ghsa

### Summary `tmp@0.2.3` is vulnerable to an Arbitrary temporary file / directory write via symbolic link `dir` parameter. ### Details According to the documentation there are some conditions that must be held: ``` // https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L41-L50 Other breaking changes, i.e. - template must be relative to tmpdir - name must be relative to tmpdir - dir option must be relative to tmpdir //<-- this assumption can be bypassed using symlinks are still in place. In order to override the system's tmpdir, you will have to use the newly introduced tmpdir option. // https://github.com/raszi/node-tmp/blob/v0.2.3/README.md?plain=1#L375 * `dir`: the optional temporary directory that must be relative to the system's default temporary directory. absolute paths are fine as long as they point to a location under the system's default temporary directory. Any directories along the so specified path must exist, otherwise a ENOENT error will be...

A Regular Expression Denial of Service (ReDoS) vulnerability exists in the Hugging Face Transformers library, specifically in the `convert_tf_weight_name_to_pt_weight_name()` function. This function, responsible for converting TensorFlow weight names to PyTorch format, uses a regex pattern `/[^/]*___([^/]*)/` that can be exploited to cause excessive CPU consumption through crafted input strings due to catastrophic backtracking. The vulnerability affects versions up to 4.51.3 and is fixed in version 4.53.0. This issue can lead to service disruption, resource exhaustion, and potential API service vulnerabilities, impacting model conversion processes between TensorFlow and PyTorch formats.

Vault and Vault Enterprise’s (“Vault”) ldap auth method may not have correctly enforced MFA if username_as_alias was set to true and a user had multiple CNs that are equal but with leading or trailing spaces. Fixed in Vault Community Edition 1.20.2 and Vault Enterprise 1.20.2, 1.19.8, 1.18.13, and 1.16.24.

A race condition vulnerability has been identified in Shopware's voucher system of Shopware v6.6.10.4 that allows attackers to bypass intended voucher restrictions and exceed usage limitations.

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-2x5j-vhc8-9cwm. This link is maintained to preserve external references. ## Original Description A flaw was found in CIRCL's implementation of the FourQ elliptic curve. This vulnerability allows an attacker to compromise session security via low-order point injection and incorrect point validation during Diffie-Hellman key exchange.

Concrete CMS 9 to 9.4.2 and versions below 8.5.21 are vulnerable to Reflected Cross-Site Scripting (XSS) in the Conversation Messages Dashboard Page. Unsanitized input could cause theft of session cookies or tokens, defacement of web content, redirection to malicious sites, and (if victim is an admin), the execution of unauthorized actions.

Concrete CMS versions 9 through 9.4.2 are vulnerable to Stored XSS from Home Folder on Members Dashboard page.  Version 8 was not affected. A rogue admin could set up a malicious folder containing XSS to which users could be directed upon login.

Two issues were found: For some inputs to signed integer division, the circuit allowed two outputs, only one of which was valid. Additionally, the result of division by zero was underconstrained. This vulnerability was identified using the Picus tool from Veridise. Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). ## Mitigation We recommend all impacted users upgrade as soon as possible. Rust applications using the `risc0-zkvm` crate at versions < 2.2 should upgrade to version 2.2.0 or later. Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.2 is active on all official routers, and version 2.1 has been disabled. Smart c...

### Impact The XML export of a page in XWiki that can be triggered by any user with view rights on a page by appending `?xpage=xml` to the URL includes password and email properties stored on a document that aren't named `password` or `email`. This allows any user to obtain the salted and hashed user account validation or password reset token. As those tokens are randomly generated strings, the immediate impact of this should be low. The user's password and email itself aren't exposed as those fields are named `password` and `email` and thus aren't affected. However, depending on how the wiki is used, there could be extensions or custom code that store passwords in plain text in such password properties that would be exposed by this vulnerability. ### Patches This vulnerability has been fixed by completely removing the output of password and email fields in this XML export in versions 17.2.0 RC1, 16.10.5 and 16.4.7. ### Workarounds If this XML export isn't needed, the file `templates...

### Impact Any user with edit right on a page of the wiki can create an XClass with a database list property that references a password property, for example the password hash that is stored for users. When adding an object of that XClass, the content of that password property is displayed. In practice, with a standard rights setup, this means that any user with an account on the wiki can access password hashes of all users, and possibly other password properties (with hashed or plain storage) that are on pages that the user can view. ### Patches This vulnerability has been pached in XWiki 16.4.7, 16.10.5, and 17.2.0 by disallowing the use of password properties in database list properties. Additionally, queries for email properties are disallowed, too, when email obfuscation is enabled. ### Workarounds We're not aware of any workarounds.