ghsa

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!

Due to a missing signature (HMAC) for a request argument, an attacker could unserialize arbitrary objects within FLOW3. To our knowledge it is neither possible to inject code through this vulnerability, nor are there exploitable objects within the FLOW3 Base Distribution. However, there might be exploitable objects within user applications.

Due to reports it has been validated that internal workspaces in Neos are accessible without authentication. Some users assumed this is a planned feature but it is not. A workspace preview should be an additional feature with respective security measures in place. Note that this only allows reading of internal workspaces not writing. And for clarification, an internal workspace is a workspace that is non public and doesn't have an owner. Given that an internal workspace exists in your installation, it is possible to view a page in context of that workspace by opening a link in this format: https://domain/path/to/page.html@workspace-name The issue is quite problematic when exploited but at the same time slightly less impactful than it sounds. First of all there is no default internal workspace, so the issue affects only workspaces created by users. That also means the workspace-name, which will also always include a hash is individual to a project and an exploiter must get hold of t...

It has been discovered that Flow 3.0.0 allows arbitrary file uploads, inlcuding server-side scripts, posing the risk of attacks. If those scripts are executed by the server when accessed through their public URL, anything not blocked through other means is possible (information disclosure, placement of backdoors, data removal, …). Note: The upload of files is only possible if the application built on Flow provides means to do so, and whether or not the upload of files poses a risk is dependent on the system setup. If uploaded script files are not executed by the server, there is no risk. In versions prior to 3.0.0 the upload of files with the extension php was blocked. In Flow 2.3.0 to 2.3.6 a potential XML External Entity processing vulnerability has been discovered in the MediaTypeConverter.