ghsa

### Impact _What kind of vulnerability is it? Who is impacted?_ Using the vesting module, a malicious attacker can create a new vesting account at a given address, before a contract is created on that address. Addresses of smart contracts deployed to the EVM are deterministic. Therefore, it would be possible for an attacker to front-run a contract creation and create a vesting account at that address. When an address has been initialized without any contract code deployed to it, it will not be possible to upload any afterwards. In the described attack, this would mean that a malicious actor could prevent smart contracts from being deployed correctly. In order to remediate this, an alternative user flow is being implemented for the vesting module: - only the account receiving the vesting funds will be able to create such an account by calling the `CreateClawbackVestingAccount` method and defining a funder address - vesting and lockup periods can then be created by that funder addres...

## Impact _What kind of vulnerability is it? Who is impacted?_ An attacker can use this bug to bypass the block gas limit and gas payment completely to perform a full Denial-of-Service against the chain. ## Disclosure Evmos versions below `v11.0.1` do not check for `MsgEthereumTx` messages that are nested under other messages. This allows a malicious actor to perform EVM transactions that do not meet the checks performed under `newEthAnteHandler`. This opens the possibility for the DOS of validators and consequently halt the chain through an infinite EVM execution. ### Additional details The attack scenario is as follows: 1. The attacker deploys a simple smart contract with an infinite loop to the chain. 2. The attacker calls the smart contract using an embedded transaction with an extremely high gas value (`uint64` max or similar). 3. Once the transaction is included in a block, nodes will try to execute the EVM transaction with almost infinite gas and get stuck. **This stops...

Due to a permissive regular expression hardcoded for filtering allowed hosts to register a dynamic client, a malicious user with enough information about the environment could benefit and jeopardize an environment with this specific Dynamic Client Registration with TrustedDomain configuration previously unauthorized. #### Acknowledgements: Special thanks to Bastian Kanbach for reporting this issue and helping us improve our security.

Keycloak allows arbitrary URLs as SAML Assertion Consumer Service POST Binding URL (ACS), including JavaScript URIs (javascript:). Allowing JavaScript URIs in combination with HTML forms leads to JavaScript evaluation in the context of the embedding origin on form submission. #### Acknowledgements: Special thanks to Lauritz Holtmann for reporting this issue and helping us improve our project.

Keycloak does not correctly validate its client step-up authentication. A password-authed attacker could use this flaw to register a false second auth factor, alongside the existing one, to a targeted account. The second factor then permits step-up authentication.

An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts.

Versions of the BlazeMeter Jenkins plugin prior to 4.22 contain a flaw which results in credential enumeration.

Incorrect access control in Dolibarr ERP CRM versions 19.0.0 and before, allows authenticated attackers to steal victim users' session cookies and CSRF protection tokens via user interaction with a crafted web page, leading to account takeover.

### Summary There is a potential cross-site scripting (XSS) vulnerability that can be exploited via maliciously crafted user data. Our filter to detect and prevent the use of the `javascript:` URL scheme in the `href` attribute of an `<a>` tag could be bypassed with tab `\t` or newline `\n` characters between the characters of the protocol, e.g. `java\tscript:`. ### Impact If you render an `<a>` tag with an `href` attribute set to a user-provided link, that link could potentially execute JavaScript when clicked by another user. ```ruby a(href: user_profile) { "Profile" } ``` ### Mitigation The best way to mitigate this vulnerability is to update to one of the following versions: - [1.10.1](https://rubygems.org/gems/phlex/versions/1.10.1) - [1.9.2](https://rubygems.org/gems/phlex/versions/1.9.2) - [1.8.3](https://rubygems.org/gems/phlex/versions/1.8.3) - [1.7.2](https://rubygems.org/gems/phlex/versions/1.7.2) - [1.6.3](https://rubygems.org/gems/phlex/versions/1.6.3) - [1.5.3](htt...

# Overview Some end users of OpenFGA v1.5.0 or later are vulnerable to authorization bypass when calling Check or ListObjects APIs. # Am I Affected? You are very likely affected if your model involves exclusion (e.g. `a but not b`) or intersection (e.g. `a and b`) and you have any cyclical relationships. If you are using these, please update as soon as possible. # Fix Update to v1.5.3 # Backward Compatibility This update is backward compatible.