#perl

### Summary `concat` built-in can write over the bounds of the memory buffer that was allocated for it and thus overwrite existing valid data. The root cause is that the `build_IR` for `concat` doesn't properly adhere to the API of copy functions (for `>=0.3.2` the `copy_bytes` function). A contract search was performed and no vulnerable contracts were found in production. Tracked in issue https://github.com/vyperlang/vyper/issues/3737 ### Details The `build_IR` allocates a new internal variable for the concatenation: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L534-L550 Notice that the buffer is allocated for the `maxlen` + 1 word to actually hold the length of the array. Later the `copy_bytes` function is used to copy the actual source arguments to the destination: https://github.com/vyperlang/vyper/blob/3b310d5292c4d1448e673d7b3adb223f9353260e/vyper/builtins/functions.py#L569-L572 The `dst_data` is defined via: ...

Ubuntu Security Notice 6590-1 - It was discovered that Xerces-C++ was not properly handling memory management operations when parsing XML data containing external DTDs, which could trigger a use-after-free error. If a user or automated system were tricked into processing a specially crafted XML document, an attacker could possibly use this issue to cause a denial of service or execute arbitrary code. This issue only affected Ubuntu 22.04 LTS. It was discovered that Xerces-C++ was not properly performing bounds checks when processing XML Schema Definition files, which could lead to an out-of-bounds access via an HTTP request. If a user or automated system were tricked into processing a specially crafted XSD file, a remote attacker could possibly use this issue to cause a denial of service.

MiniWeb HTTP Server version 0.8.1 remote denial of service exploit.

SpyCamLizard version 1.230 remote denial of service exploit.

The implementation of the [`Instrumented::into_inner`] method in affected versions of this crate contains undefined behavior due to incorrect use of [`std::mem::forget`] The function creates `*const` pointers to `self`, calls [`mem::forget(self)`][`std::mem::forget`], and then moves values out of those pointers using [`std::ptr::read`]. ```rust // To manually destructure `Instrumented` without `Drop`, we // move it into a ManuallyDrop and use pointers to its fields let span: *const Span = &this.span; let inner: *const ManuallyDrop<T> = &this.inner; mem::forget(self); // SAFETY: Those pointers are valid for reads, because `Drop` didn't // run, and properly aligned, because `Instrumented` isn't // `#[repr(packed)]`. let _span = unsafe { span.read() }; let inner = unsafe { inner.read() }; ``` However, the [`mem::forget` documentation][`std::mem::forget`] states: > Any resources the value manages, such as heap memory or a file handle, will > linger forever in an unreacha...

Easy File Sharing FTP version 3.6 remote denial of service exploit.

### Summary The revocation schema that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. ### Details The revocation schema that is part of the Ursa CL-Signatures implementation has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, allowing a malicious holder of a revoked credential to generate a valid Non-Revocation Proof for that credential as part of an AnonCreds presentation. The flaw exists in all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and are fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate]. To exploit the flaw, a holder must update...

### Summary The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model. Notably, a malicious verifier may be able to generate a unique identifier for a holder providing a verifiable presentation that includes a Non-Revocation proof. ### Details The revocation scheme that is part of the Ursa CL-Signatures implementations has a flaw that could impact the privacy guarantees defined by the AnonCreds verifiable credential model, potentially allowing a malicious verifier to generate a unique identifier for a holder that provides a verifiable presentation that includes a Non-Revocation proof. The flaws affects all CL-Signature versions published from the [Hyperledger Ursa] repository to the [Ursa Rust Crate], and is fixed in all versions published from the [Hyperledger AnonCreds CL-Signatures] repository to the [AnonCreds CL-Signatures Rust Crate]. The addressing the...

# CL Signatures Issuer Key Correctness Proof lacks of prime strength checking A weakness in the Hyperledger AnonCreds specification that is not mitigated in the Ursa and AnonCreds implementations is that the Issuer does not publish a key correctness proof demonstrating that a generated private key is sufficient to meet the unlinkability guarantees of AnonCreds. A sufficient private key is one in which it's components `p` and `q` are safe primes, such that: - `p` and `q` are both prime numbers - `p` and `q` are not equal - `p` and `q` have the same, sufficiently large, size - For example, using two values both 1024 bits long is sufficient, whereas using one value 2040 bits long and the other 8 bits long is not. The Ursa and AnonCreds CL-Signatures implementations always generate a sufficient private key. A malicious issuer could in theory create a custom CL Signature implementation (derived from the Ursa or AnonCreds CL-Signatures implementations) that uses weakened private keys su...

### Summary A **stored cross-site scripting (XSS)** vulnerability was found in the **key_value** field of Avo v3.2.3. This vulnerability could allow an attacker to execute arbitrary JavaScript code in the victim's browser. ### Details The value of the key_value is inserted directly into the HTML code. In the current version of Avo (possibly also older versions), the value is not properly sanitized before it is inserted into the HTML code. This vulnerability can be exploited by an attacker to inject malicious JavaScript code into the key_value field. When a victim views the page containing the malicious code, the code will be executed in their browser. In [avo/fields/common/key_value_component.html.erb]( https://github.com/avo-hq/avo/blob/main/app/components/avo/fields/common/key_value_component.html.erb#L38C21-L38C33) the value is taken in lines **38** and **49** and seems to be interpreted directly as html in lines **44** and **55**. ### PoC ![POC](https://user-images.githubuserc...