ghsa

### Impact It’s possible for authenticated users to enumerate clusters by name by inspecting error messages: ``` $ curl -k 'https://localhost:8080/api/v1/clusters/in-cluster?id.type=name' -H "Authorization: Bearer $token" {"error":"permission denied: clusters, get, , sub: alice, iat: 2022-11-04T20:25:44Z","code":7,"message":"permission denied: clusters, get, , sub: alice, iat: 2022-11-04T20:25:44Z"}⏎ $ curl -k 'https://localhost:8080/api/v1/clusters/does-not-exist?id.type=name' -H "Authorizati on: Bearer $token" {"error":"permission denied","code":7,"message":"permission denied"} ``` It’s also possible to enumerate the names of projects with project-scoped clusters if you know the names of the clusters. ``` curl -k 'https://localhost:8080/api/v1/clusters/in-cluster-project?id.type=name' -H "Authorization: Bearer $token" {"error":"permission denied: clusters, get, default/, sub: alice, iat: 2022-11-04T20:25:44Z","co...

### Summary _Short summary of the problem. Make the impact and severity as clear as possible. For example: An unsafe deserialization vulnerability allows any unauthenticated user to execute arbitrary code on the server._ ### Details We discovered a bug walking through how to liquid stake using Safe which itself is a contract. The bug only appears when there is a local state change together with an ICS20 transfer in the same function and uses the contract's balance, that is using the contract address as the `sender` parameter in an ICS20 transfer using the ICS20 precompile ### Proof of Concept ```solidity // This function does not reduce the contract balance correctly but liquid stakes correctly function transfer( string memory sourcePort, string memory sourceChannel, string memory denom, uint256 amount, string memory receiver, string memory evmosReceiver ) external returns (uint64 nextSequence) { counter += 1; # Only happen...

A local file inclusion vulnerability exists in the JSON component of gradio-app/gradio and was discovered in version 4.25. The vulnerability arises from improper input validation in the `postprocess()` function within `gradio/components/json_component.py`, where a user-controlled string is parsed as JSON. If the parsed JSON object contains a `path` key, the specified file is moved to a temporary directory, making it possible to retrieve it later via the `/file=..` endpoint. This issue is due to the `processing_utils.move_files_to_cache()` function traversing any object passed to it, looking for a dictionary with a `path` key, and then copying the specified file to a temporary directory. The vulnerability can be exploited by an attacker to read files on the remote system, posing a significant security risk.

A Server-Side Request Forgery (SSRF) vulnerability exists in the gradio-app/gradio and was discovered in version 4.21.0, specifically within the `/queue/join` endpoint and the `save_url_to_cache` function. The vulnerability arises when the `path` value, obtained from the user and expected to be a URL, is used to make an HTTP request without sufficient validation checks. This flaw allows an attacker to send crafted requests that could lead to unauthorized access to the local network or the AWS metadata endpoint, thereby compromising the security of internal servers.

A remote code execution (RCE) vulnerability exists in the lightning-ai/pytorch-lightning library version 2.2.1 due to improper handling of deserialized user input and mismanagement of dunder attributes by the `deepdiff` library. The library uses `deepdiff.Delta` objects to modify application state based on frontend actions. However, it is possible to bypass the intended restrictions on modifying dunder attributes, allowing an attacker to construct a serialized delta that passes the deserializer whitelist and contains dunder attributes. When processed, this can be exploited to access other modules, classes, and instances, leading to arbitrary attribute write and total RCE on any self-hosted pytorch-lightning application in its default configuration, as the delta endpoint is enabled by default.

## Impact This advisory has been created to address the following vulnerabilities found in the Evmos codebase and affecting vesting accounts. ### Wrong spendable balance computation The spendable balance is not updated properly when delegating vested tokens. The following example help in describing the issue: - Given a clawback vesting account with a starting `15M` vesting schedule. The initial spendable balance is `0`. - Time passes and `5M` are vested. The spendable balance is now `5M`. - The account delegate `5M`. The spendable balance should be `0`, but returns `5M` - The account can send `5M` to another account. The issue allowed a clawback vesting account to anticipate the release of unvested tokens. ### Missing precompile checks Preliminary checks on actions computed by the clawback vesting accounts are performed in the ante handler. Evmos core, implements two different ante handlers: one for Cosmos transactions and one for Ethereum transactions. Checks performed on the tw...

When receiving a message from a client that sent an invalid RSA premaster secret, an issue in s2n-tls results in the server performing additional processing when the premaster secret contains an incorrect client hello version. While no practical attack on s2n-tls has been demonstrated, this causes a small timing difference which could theoretically be used as described in the Marvin Attack [1]. We would like to thank Hubert Kario [2] for reporting this issue. ### Impact The extent of this issue is a timing difference. No practical attack on s2n-tls has been demonstrated. This issue affects server applications that permit RSA key exchange. Applications that use the default, built-in blinding feature or properly implement self-service blinding are not affected. Impacted versions: <= v1.4.15. ### Patches The patch is included in v1.4.16 [3]. ### Workarounds Applications can work around this issue by using an s2n-tls security policy that disallows RSA key exchange. If you have ...

The CraftCMS plugin Two-Factor Authentication in versions 3.3.1, 3.3.2 and 3.3.3 discloses the password hash of the currently authenticated user after submitting a valid TOTP.

The CraftCMS plugin Two-Factor Authentication through 3.3.3 allows reuse of TOTP tokens multiple times within the validity period.

A remote code execution vulnerability has been found in the Swift Mailer library (swiftmailer/swiftmailer) recently. See this advisory for details. If you are not using the default mail() transport, this particular problem does not affect you. Upgrading is of course still recommended!