Hydra is a Continuous Integration service for Nix based projects. It is possible to trigger evaluations in Hydra without any authentication. Depending on the size of evaluations, this can impact the availability of systems. The problem can be fixed by applying https://github.com/NixOS/hydra/commit/f73043378907c2c7e44f633ad764c8bdd1c947d5 to any Hydra package. Users are advised to upgrade. Users unable to upgrade should deny the `/api/push` route in a reverse proxy. This also breaks the "Evaluate jobset" button in the frontend.

Hydra is a Continuous Integration service for Nix based projects. Attackers can execute arbitrary code in the browser context of Hydra and execute authenticated HTTP requests. The abused feature allows Nix builds to specify files that Hydra serves to clients. One use of this functionality is serving NixOS `.iso` files. The issue is only with html files served by Hydra. The issue has been patched on https://hydra.nixos.org around 2024-04-21 14:30 UTC. The nixpkgs package were fixed in unstable and 23.11. Users with custom Hydra packages can apply the fix commit to their local installations. The vulnerability is only triggered when opening HTML build artifacts, so not opening them until the vulnerability is fixed works around the issue.

Hydra is the two-layer scalability solution for Cardano. Prior to version 0.13.0, it is possible for a malicious head initializer to extract one or more PTs for the head they are initializing due to incorrect data validation logic in the head token minting policy which then results in an 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`. During the `Initial` state of the protocol, if the malicious initializer removes a PT from the Hydra scripts it becomes impossible for any other participant to reclaim any funds they have attempted to commit into the head, as to do so the Abort transaction must burn all the PTs for the head, but they cannot burn the PT which the attacker controls and so cannot satisfy this requirement. That means the initializer can lock the other partic…

Hydra is the layer-two scalability solution for Cardano. Prior to version 0.13.0, the specification states that the contestation period in the datum of the UTxO at the head validator must stay unchanged as the state progresses from Open to Closed (Close transaction), 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. Version 0.13.0 contains a patch for this issue.

Hydra is the layer-two scalability solution for Cardano. Users of the Hydra head protocol send the UTxOs they wish to commit into the Hydra head first to the `commit` validator, where they remain until they are either collected into the `head` validator or the protocol initialisation is aborted and the value in the committed UTxOs is returned to the users who committed them. Prior to version 0.12.0, the `commit` validator contains a flawed check when the `ViaAbort` redeemer is used, which allows any user to spend any UTxO which is at the validator arbitrarily, meaning an attacker can steal the funds that users are trying to commit into the head validator. The intended behavior is that the funds must be returned to the user which committed the funds and can only be performed by a participant of the head. The `initial` validator also is similarly affected as the same flawed check is performed for the `ViaAbort` redeemer. Due to this issue, an attacker can steal any funds that user's try…

Hydra is the layer-two scalability solution for Cardano. Prior to version 0.13.0, not signing and verifying `$\mathsf{cid}$` allows an attacker (which 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 (= value extraction attack; hard, but possible) or prevent the head to finalize because the value available is not consistent with the closed utxo state (= denial of service; easy). A patch is planned for version 0.13.0. As a workaround, rotate keys between heads so not to re-use keys and not result in the same multi-signature participants.

In Hydra (an OAuth2 Server and OpenID Certified™ OpenID Connect Provider written in Go), before version 1.4.0+oryOS.17, when using client authentication method 'private_key_jwt' [1], OpenId specification says the following about assertion `jti`: "A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties". Hydra does not check the uniqueness of this `jti` value. Exploiting this vulnerability is somewhat difficult because: - TLS protects against MITM which makes it difficult to intercept valid tokens for replay attacks - The expiry time of the JWT gives only a short window of opportunity where it could be replayed This has been patched in version v1.4.0+oryOS.17

Hydra through 0.1.8 has a NULL pointer dereference and daemon crash when processing POST requests that lack a Content-Length header. read.c, request.c, and util.c contribute to this. The process_header_end() function calls boa_atoi(), which ultimately calls atoi() on a NULL pointer.

ORY Hydra before v1.0.0-rc.3+oryOS.9 has Reflected XSS via the oauth2/fallbacks/error error_hint parameter.

The 17046 Ethernet card before 94450214LFMT100SEM-L.R3-CL for the GE Digital Energy Hydran M2 does not properly generate random values for TCP Initial Sequence Numbers (ISNs), which makes it easier for remote attackers to spoof packets by predicting these values.