Source
ghsa
Mattermost versions 8.1.x before 8.1.12, 9.6.x before 9.6.1, 9.5.x before 9.5.3, 9.4.x before 9.4.5 fail to limit the number of active sessions, which allows an authenticated attacker to crash the server via repeated requests to the getSessions API after flooding the sessions table.
Mattermost versions 9.6.0, 9.5.x before 9.5.3, and 8.1.x before 8.1.12 fail to fully validate role changes which allows an attacker authenticated as team admin to demote users to guest via crafted HTTP requests.
A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. This issue has its root in how runc handles Config Annotations lists.
Passbolt API before 4.6.2 allows HTML injection in a URL parameter, resulting in custom content being displayed when a user visits the crafted URL. Although the injected content is not executed as JavaScript due to Content Security Policy (CSP) restrictions, it may still impact the appearance and user interaction of the page.
python-jose through 3.3.0 allows attackers to cause a denial of service (resource consumption) during a decode via a crafted JSON Web Encryption (JWE) token with a high compression ratio, aka a "JWT bomb." This is similar to CVE-2024-21319.
python-jose through 3.3.0 has algorithm confusion with OpenSSH ECDSA keys and other key formats. This is similar to CVE-2022-29217.
### Summary When looping over a `range` of the form `range(start, start + N)`, if `start` is negative, the execution will always revert. ### Details This issue is caused by an incorrect assertion inserted by the code generation of the range (`stmt.parse_For_range()`): https://github.com/vyperlang/vyper/blob/9136169468f317a53b4e7448389aa315f90b95ba/vyper/codegen/stmt.py#L286-L287 This assertion was introduced in https://github.com/vyperlang/vyper/commit/3de1415ee77a9244eb04bdb695e249d3ec9ed868 to fix https://github.com/advisories/GHSA-6r8q-pfpv-7cgj. The issue arises when `start` is signed, instead of using `sle`, `le` is used and `start` is interpreted as an unsigned integer for the comparison. If it is a negative number, its 255th bit is set to `1` and is hence interpreted as a very large unsigned integer making the assertion always fail. ### PoC ```Vyper @external def foo(): x:int256 = min_value(int256) # revert when it should not since we have the following assertion...
### Summary Incorrect values can be logged when `raw_log` builtin is called with memory or storage arguments to be used as topics. A contract search was performed and no vulnerable contracts were found in production. In particular, no uses of `raw_log()` were found at all in production; it is apparently not a well-known function. ### Details The `build_IR` function of the `RawLog` class fails to properly unwrap the variables provided as topics. Consequently, incorrect values are logged as topics. ### PoC ```vyper x: bytes32 @external def f(): self.x = 0x1234567890123456789012345678901234567890123456789012345678901234 raw_log([self.x], b"") # LOG1(offset:0x60, size:0x00, topic1:0x00) y: bytes32 = 0x1234567890123456789012345678901234567890123456789012345678901234 raw_log([y], b"") # LOG1(offset:0x80, size:0x00, topic1:0x40) ``` ### Impact Incorrect values can be logged which may result in unexpected behavior in client-side applications relying on these logs.
### Summary Using the `slice` builtin can result in a double eval vulnerability when the buffer argument is either `msg.data`, `self.code` or `<address>.code` and either the `start` or `length` arguments have side-effects. A contract search was performed and no vulnerable contracts were found in production. Having side-effects in the start and length patterns is also an unusual pattern which is not that likely to show up in user code. It is also much harder (but not impossible!) to trigger the bug since `0.3.4` since the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914). ### Details It can be seen that the `_build_adhoc_slice_node` function of the `slice` builtin doesn't cache the mentioned arguments to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L244 As such, they can be evaluated multiple times (instead of retrieving the value from the stack). ### PoC with Vyper version `0....
### Summary Using the `create_from_blueprint` builtin can result in a double eval vulnerability when `raw_args=True` and the `args` argument has side-effects. A contract search was performed and no vulnerable contracts were found in production. In particular, the `raw_args` variant of `create_from_blueprint` was not found to be used in production. ### Details It can be seen that the `_build_create_IR` function of the `create_from_blueprint` builtin doesn't cache the mentioned `args` argument to the stack: https://github.com/vyperlang/vyper/blob/cedf7087e68e67c7bfbd47ae95dcb16b81ad2e02/vyper/builtins/functions.py#L1847 As such, it can be evaluated multiple times (instead of retrieving the value from the stack). ### PoC The vulnerability is demonstrated in the following `boa` test: ``` vyper src1 = """ c: uint256 """ deployer = """ created_address: public(address) deployed: public(uint256) @external def get() -> Bytes[32]: self.deployed += 1 return b'' @external def create...