CVE-2026-62162
HighCVSS 8.2Exploitation Probability (EPSS)
Low risk31th percentile - higher than 31% of all known CVEs
Summary
In Hydra (a layer-two scalability solution for Cardano) before 2.1.0, the Claim branch in the deposit validator only checks that datum.head_id matches the attacker-controlled redeemer.currencySymbol and that the transaction is valid before the deposit deadline. It neither requires spending the Head state-token UTxO in the same transaction nor constrains outputs, so after a deposit via POST /commit is confirmed, any third party can consume the pending deposit UTxO and redirect the assets to an arbitrary address.
Risk Assessment
An attacker can intercept pending deposits and redirect assets to an address they control, causing direct loss of user funds. The issue affects pending deposits before the deadline (default three times depositPeriod).
Recommendation
Upgrade Hydra to version 2.1.0 or later. Until patched, avoid accepting deposits or limit their amounts and monitor pending UTxOs.
Other vulnerabilities in Hydra
See all- CVE-2026-106442High
Hydra from 1.3.4 until 1.3.6 and 1.4.0.dev9 has an incomplete target blacklist for instantiate() that does not fully check the effective callable selected by the target field. Execution wrappers such as timeit.timeit, pickle.loads, aliases, callable-returning helpers, generic dispatch, and deferred calls can obscure or defer the effective target and bypass name-based authorization.
- CVE-2026-106441High
Hydra prior to 1.3.6 and 1.4.0.dev9 passes Python logging configuration to logging.config.dictConfig() without applying Hydra's target policy to handler class values or formatter, filter, handler, queue, and listener factories. An attacker who controls Hydra logging configuration can select an importable class or factory and cause it to be invoked with the application's privileges.
- CVE-2026-106440High
Hydra from 1.2.0 until 1.3.0 and 1.4.0.dev10 in the hydra-optuna-sweeper package accepts a configuration-controlled dotted path in hydra.sweeper.custom_search_space, resolves it with hydra.utils.get_method(), and later invokes the returned callable in the Hydra controller process. Because get_method() does not apply the execution policy used by instantiate(), an attacker who controls Optuna sweep configuration or command-line overrides can select importable Python code for execution with the application's privileges.
- CVE-2026-106439High
Hydra from 1.3.4 until 1.3.7 and 1.4.0.dev10 stores legacy instantiate target blocklists and related execution-policy collections in mutable module-level state. An attacker who controls multiple sibling target entries can resolve hydra._internal.target_policy.UNCONTROLLED_EXECUTION_TARGETS.discard through instantiate(), remove a denied target, and then invoke that target because sibling nodes are processed in insertion order against the same modified policy.
- CVE-2026-68508High
Hydra before version 1.3.4 has an arbitrary code execution vulnerability. The hydra.utils.instantiate() function resolves and calls Python objects selected by configuration, allowing an attacker to invoke dangerous callables.
- CVE-2026-56766High
A stack buffer overflow vulnerability in Hydra through version 9.7 (fixed in commit 9cc84c2) affects NTLM authentication in SMTP, POP3, IMAP, NNTP, HTTP, HTTP-Proxy, and HTTP-Proxy-Urlenum modules when processing malicious NTLM Type-2 challenges. A remote server can send a crafted challenge with an excessively long domain string, causing base64-encoded response data to overflow a 500-byte stack buffer by 18 to 330 bytes, enabling remote code execution on systems without stack protection.
Original NVD description (English source)
Hydra is a layer-two scalability solution for Cardano. Prior to 2.1.0, the `Claim` branch in `hydra-plutus/validators/deposit.ak` checks only that `datum.head_id` matches the attacker-controlled `redeemer.currencySymbol` and that the transaction is valid before the deposit deadline. It neither requires spending the Head state-token UTxO in the same transaction nor constrains outputs. After a deposit made through `POST /commit` is confirmed, any third party able to build a Cardano transaction can observe and consume the pending deposit UTxO before its deadline and redirect the assets to an arbitrary address. A standalone deposit spend invokes no Head validator, bypassing its safety checks; historical head-ID binding and the Aiken rewrite retained this missing invariant. The default deadline is three times depositPeriod, so the described attack applies to pending deposits before that deadline. This issue is fixed in version 2.1.0.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

