ghsa

`lexical` contains multiple soundness issues: 1. [Bytes::read() allows creating instances of types with invalid bit patterns](https://github.com/Alexhuszagh/rust-lexical/issues/102) 1. [BytesIter::read() advances iterators out of bounds](https://github.com/Alexhuszagh/rust-lexical/issues/101) 1. [The `BytesIter` trait has safety invariants but is public and not marked `unsafe`](https://github.com/Alexhuszagh/rust-lexical/issues/104) 1. [`write_float()` calls `MaybeUninit::assume_init()` on uninitialized data, which is is not allowed by the Rust abstract machine](https://github.com/Alexhuszagh/rust-lexical/issues/95) The crate also has some correctness issues and appears to be unmaintained. ## Alternatives For quickly parsing floating-point numbers third-party crates are no longer needed. A fast float parsing algorith by the author of `lexical` has been [merged](https://github.com/rust-lang/rust/pull/86761) into libcore. For quickly parsing integers, consider `atoi` and `btoi` ...

### Impact The order of evaluation of the arguments of the builtin functions `uint256_addmod`, `uint256_mulmod`, `ecadd` and `ecmul` does not follow source order. • For `uint256_addmod(a,b,c)` and `uint256_mulmod(a,b,c)`, the order is `c,a,b`. • For `ecadd(a,b)` and `ecmul(a,b)`, the order is `b,a`. Note that this behaviour is problematic when the evaluation of one of the arguments produces side effects that other arguments depend on. ### Patches https://github.com/vyperlang/vyper/pull/3583 ### Workarounds When using builtins from the list above, make sure that the arguments of the expression do not produce side effects or, if one does, that no other argument is dependent on those side effects. ### References _Are there any links users can visit to find out more?_

### Impact For the following (probably non-exhaustive) list of expressions, the compiler evaluates the arguments from right to left instead of left to right. ``` - unsafe_add - unsafe_sub - unsafe_mul - unsafe_div - pow_mod256 - |, &, ^ (bitwise operators) - bitwise_or (deprecated) - bitwise_and (deprecated) - bitwise_xor (deprecated) - raw_call - <, >, <=, >=, ==, != - in, not in (when lhs and rhs are enums) ``` This behaviour becomes a problem when the evaluation of one of the arguments produces side effects that other arguments depend on. The following expressions can produce side-effect: - state modifying external call - state modifying internal call - `raw_call` - `pop()` when used on a Dynamic Array stored in the storage - `create_minimal_proxy_to` - `create_copy_of` - `create_from_blueprint` For example: ```Vyper f:uint256 @internal def side_effect() -> uint256: self.f = 12 return 1 @external def foo() -> uint256: return unsafe_add(self.f,self.side_effect())...

### Impact It is possible in XWiki to execute Velocity code without having script right by creating an XClass with a property of type "TextArea" and content type "VelocityCode" or "VelocityWiki". For the former, the syntax of the document needs to be set the `xwiki/1.0` (this syntax doesn't need to be installed). In both cases, when adding the property to an object, the Velocity code is executed regardless of the rights of the author of the property (edit right is still required, though). In both cases, the code is executed with the correct context author so no privileged APIs can be accessed. However, Velocity still grants access to otherwise inaccessible data and APIs that could allow further privilege escalation. At least for "VelocityCode", this behavior is most likely very old but only since XWiki 7.2, script right is a separate right, before that version all users were allowed to execute Velocity and thus this was expected and not a security issue. ### Patches This has been pat...

### Impact Improper input validation in the `init` function allows arbitrary javascript to be executed using the `javascript:` prefix ```ts SSO.init('javascript:alert("javascript successfully injected")') ``` ### Patches This vulnerability was patched on version `0.1.0` ### Workarounds This vulnerability can be prevented if user input correctly sanitized or there is no user input pass to the `init` function

### Impact An issue was discovered in the default implementations of the `VolatileMemory::{get_atomic_ref, aligned_as_ref, aligned_as_mut, get_ref, get_array_ref}` trait functions, which allows out-of-bounds memory access if the `VolatileMemory::get_slice` function returns a `VolatileSlice` whose length is less than the function’s `count` argument. No implementations of `get_slice` provided in `vm_memory` are affected. Users of custom `VolatileMemory` implementations may be impacted if the custom implementation does not adhere to `get_slice`'s documentation. ### Patches The issue started in version 0.1.0 but was fixed in version 0.12.2 by inserting a check that verifies that the `VolatileSlice` returned by `get_slice` is of the correct length. ### Workarounds Not Required ### References https://github.com/rust-vmm/vm-memory/commit/aff1dd4a5259f7deba56692840f7a2d9ca34c9c8 https://crates.io/crates/vm-memory/0.12.2

### Impact The specification of the GG18 threshold ECDSA signature protocol contains a vulnerability allowing an attacker to recover the shared secret key. If a participant generates a Paillier modulus `N` containing small factors (less than `2^100`) they can interact with other participants in the signing protocol to steal their secret key shares in as little as sixteen signing attempts. The master key can then be reconstructed from these shares. ### Patches The implementation of GG18 in tss-lib did not prove that `N` is biprime or that it doesn't contain small factors. The fixed implementation adds the following proofs from the CGGMP21 threshold ECDSA protocol to the key generation: - Paillier-Blum Modulus (`N` is the product of two primes) - No Small Factor (both factors of `N` are greater than `2^256`) These proofs apply to both the Paillier encryption modulus `N`, and the modulus `NTilde` used in MTA proofs. To address the issue in the resharing protocol, an additional round...

An issue in LanChain-ai Langchain v.0.0.245 allows a remote attacker to execute arbitrary code via the evaluate function in the numexpr library.

SQL injection vulnerability in DataEase v.1.18.9 allows a remote attacker to obtain sensitive information via a crafted string outside of the blacklist function.

An issue in hjson-java up to v3.0.0 allows attackers to cause a Denial of Service (DoS) via supplying a crafted JSON string to string a `StringIndexOutOfBoundsException`.