Jmhrpr

**Name of the Vulnerable Software and Affected Versions** Hydra versions prior to 0.12.0 **Description** Hydra is a layer-two scalability solution for Cardano. The issue arises when the `ViaAbort` redeemer is used in the `commit` validator, allowing any user to spend any UTxO arbitrarily, which means an attacker can steal funds that users are trying to commit into the head validator. The intended behavior is that the funds must be returned to the user who committed the funds and can only be performed by a participant of the head. The `initial` validator is also affected by the same flawed check. Due to this issue, an attacker can steal any funds that users try to commit into a Hydra head and prevent any Hydra head from being successfully opened. However, it does not allow an attacker to take funds that have been successfully collected into and currently reside in the `head` validator. **Recommendations** For versions prior to 0.12.0, update to version 0.12.0 to resolve the issue. As a temporary workaround, consider restricting access to the `commit` and `initial` validators to minimize the risk of exploitation. Avoid using the `ViaAbort` redeemer in the affected validators until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Hydra versions prior to 0.13.0 **Description** Hydra is the layer-two scalability solution for Cardano. The issue arises because the contestation period in the datum of the UTxO at the head validator must stay unchanged as the state progresses from Open to Closed, but no such check appears to be performed in the `checkClose` function of the head validator. This would allow a malicious participant to modify the contestation deadline of the head to either allow them to fanout the head without giving another participant the chance to contest, or prevent any participant from ever redistributing the funds locked in the head via a fan-out. **Recommendations** For versions prior to 0.13.0, update to version 0.13.0 to resolve the issue. As a temporary workaround, consider restricting access to the `checkClose` function of the head validator until the patch is applied. Additionally, avoid modifying the contestation deadline of the head to prevent potential exploitation.

**Name of the Vulnerable Software and Affected Versions** Hydra versions prior to 0.13.0 **Description** The issue arises from incorrect data validation logic in the head token minting policy, which results in a flawed check for burning the head ST in the `initial` validator. This is possible because it is not checked in `HeadTokens.hs` that the datums of the outputs at the `initial` validator are equal to the real head ID, and it is also not checked in the `off-chain code`. A malicious head initializer can extract one or more PTs for the head they are initializing, allowing them to lock other participants' committed funds forever or until they choose to return the PT. The malicious initializer can also use the PT to spoof that they have committed a particular TxO when progressing the head into the `Open` state, forcing other participants to pay the attacker out of their own funds. **Recommendations** For versions prior to 0.13.0, update to version 0.13.0 to fix the issue. As a temporary workaround, consider restricting access to the `initial` validator and the `collectCom` transaction to minimize the risk of exploitation. Avoid using the `Commit` datum in the `collectCom` transaction until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Hydra versions prior to 0.13.0 **Description** Hydra is the layer-two scalability solution for Cardano. Not signing and verifying `cid` allows an attacker, who must be a participant of this head, to use a snapshot from an old head instance with the same participants to close the head or contest the state with it. This can lead to an incorrect distribution of value, resulting in a value extraction attack, or prevent the head from finalizing due to inconsistent value availability, causing a denial of service. **Recommendations** For versions prior to 0.13.0, as a temporary workaround, consider rotating keys between heads to avoid reusing keys and resulting in the same multi-signature participants. A patch is planned for version 0.13.0.