Skip to main content

Cardano Hydra CVE-2026-62162

| EUVDEUVD-2026-114282 HIGH
Missing Authorization (CWE-862)
2026-10-30 GitHub_M
8.2
CVSS 4.0 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Observe pending deposit UTxO on-chain
  2. Delivery
    Build standalone Claim tx with matching head_id redeemer
  3. Exploit
    Set tx validity before deposit deadline
  4. Execution
    Submit transaction to Cardano network
  5. Impact
    Redirect deposited assets to attacker address

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Exploitation requires a pending deposit UTxO created through the hydra-node POST /commit endpoint to be confirmed on-chain and not yet past its deadline (the default deadline is three times depositPeriod, typically tens of minutes to hours). The attacker needs only the ability to observe the Cardano chain and build/submit a standard Cardano transaction carrying a Claim redeemer with the head's currencySymbol - no Head involvement, no credentials, and no victim interaction. Limiting factors: the attack window closes at the deposit deadline, a deposit must actually be in-flight to steal, and the issue affects Hydra versions prior to 2.1.0; it works against default configurations, so no special non-default setting is required.

Impact

This is a genuine high-priority, theft-of-funds flaw rather than an inflated high-CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, base 8.2, High) describes an unauthenticated, network-reachable attack whose only real gate is AT:P - a pending deposit UTxO must exist and the attacker must act before its deadline. VI:H with VC:N/VA:N correctly models the impact as unauthorized redirection of assets (integrity) rather than disclosure or service loss. The vuln.today decision label is 'this_week', consistent with a serious but not CISA-KEV-confirmed issue. No EPSS score and no KEV entry were provided in the input, so there is no evidence of active, widespread exploitation; however, the GitHub Security Advisory (GHSA-gfpc-m687-p7h5) includes a complete, step-by-step reproduction recipe, so a public PoC reference exists even though it is not packaged as a verified working exploit binary. Weighing the signals: the flaw is trivially exploitable in principle (the redeemer's currencySymbol is attacker-controlled, so the only head-id check is self-satisfied, and no Head validator runs), the economic motive is direct (draining deposited ADA), but real-world exposure is bounded by the small deployment footprint of Hydra heads and by the requirement that a deposit be in-flight before its deadline. One data conflict must be flagged: the description and release tag state the fix is version 2.1.0, while the embedded source-code evidence line reads 'Package: /hydra-node - vulnerable: <=2.0.0 - fixed in: not yet patched' - verify the actual patched release with the vendor.

Exploit ScenarioDerived

Alice drafts a deposit via POST /commit, locking ADA in the deposit script with an inline datum (head_id H, deadline T). Mallory, watching the chain, submits a standalone transaction that spends Alice's deposit UTxO with a Claim(H) redeemer and outputs the value to her own address, with validity set before deadline T; no Head validator runs, so the transaction validates and Mallory drains the funds. A detailed reproduction/PoC walkthrough is published in the GHSA advisory, though it is not verified as packaged working exploit code.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 30, 2026

Pending deposits in Cardano Hydra heads can be stolen by any third party who can observe the chain and submit a standard Cardano transaction. Versions prior to 2.1.0 ship a deposit validator (hydra-plutus/validators/deposit.ak, deployed via hydra-node <= 2.0.0) whose Claim branch only compares the deposit datum's head_id to the attacker-supplied redeemer currencySymbol and checks the transaction is before the deposit deadline; it never requires the Head state-token UTxO to be spent and never constrains outputs, so a standalone Claim transaction confirming before the deadline redirects the deposited assets to an arbitrary address. The attack is unauthenticated and needs no victim interaction, only a deposit in flight through POST /commit and not yet past its deadline (default three times depositPeriod, typically tens of minutes to hours); the vendor advisory publishes a full exploit walkthrough and devnet reproduction, and the flaw is fixed in 2.1.0. No CISA KEV listing is present in the supplied data.

RemediationAI

Vendor-released patch: 2.1.0 (https://github.com/cardano-scaling/hydra/releases/tag/2.1.0), which changes the deposit validator's Claim branch so a Claim spend must also consume a UTxO carrying exactly one HydraHeadV2 state token of the redeemer's currency symbol, binding Claim to a Head Increment where the Head validator's own checks apply; the source change is the commit https://github.com/cardano-scaling/hydra/commit/ff60e4af4ecf05545a696a6d9bf1afeffe991de0 and the accompanying advisory is https://github.com/cardano-scaling/hydra/security/advisories/GHSA-gfpc-m687-p7h5. Operators must upgrade hydra-node to 2.1.0 and ensure the regenerated hydra-plutus/plutus.json blueprint is the one embedded in the binary (rebuild with aiken build -t compact in hydra-plutus), then run the hydra-tx mutation suite including the new DepositClaimedWithoutHeadSpent mutation, which should fail with the new D07/HeadNotSpent error; the fix commit also adds end-to-end security scenarios in Hydra.Cluster.SecurityScenarios (cannotStealDepositWithoutHeadInput) to verify the regression on a devnet. The advisory identifies no alternative control that fully closes the hole - updating is the complete fix - and until nodes run 2.1.0 any deposit created via POST /commit and confirmed on-chain should be treated as claimable by the first observer, because the attack window remains open until the deposit deadline and requires no credentials or Head participation.

Affected VersionsENISA

hydra < 2.1.0

Affected Packages

euvd hydra fix: 2.1.0

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

Hydra is a layer-two scalability protocol for Cardano built on the extended UTxO (eUTxO) model, where validator scripts run only when the UTxO they guard is spent, so every safety property must be re-established inside each spending path. The affected component is the Plutus/Aiken v_deposit validator (hydra-plutus/validators/deposit.ak), which guards funds locked by a L1 deposit transaction created through hydra-node's POST /commit endpoint. A deposit UTxO carries an inline datum (head_id, deadline, commits), and the Claim redeemer is meant to let the Head's Increment path absorb that deposit. The pre-fix Claim branch enforced only check_head_id (datum.head_id == redeemer.currencySymbol) and before_deadline against self.validity_range. Because the redeemer is attacker-controlled, the head-id comparison is trivially satisfied, and because a standalone spend of the deposit UTxO invokes no Head validator, none of the Head's own invariants (claimedDepositIsSpent, mustIncreaseValue, checkSnapshotSignature) ever run. This is the CWE-862 missing-authorization class: the validator fails to require evidence that an authorized actor - the Head, proven by spending its HydraHeadV2 state token - participated in the transaction. Historical commit c73175bbd introduced the head-id binding while leaving a FIXME noting the spec needed the head currency symbol in the Claim redeemer; the Aiken rewrite (568febff3) preserved the same gap, so the missing 'Head must be spent alongside' invariant survived both implementations. The fix adds head_is_spent(self.inputs, currencySymbol), which walks transaction inputs for a UTxO holding exactly one AssetClass(currencySymbol, "HydraHeadV2") token, and requires regenerating hydra-plutus/plutus.json (aiken build -t compact) because that blueprint is embedded into the Haskell binary via Hydra.Plutus.depositValidatorScript.

Know when Hydra gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 8.2 HIGH
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
vuln.today AI 5.9 MEDIUM

Unauthenticated network spend (PR:N/AV:N); AC:H because a pending deposit must exist and the attacker must act before the deadline; impact is asset redirection (I:H), with no confidentiality or availability loss.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Patch available
Oct 30, 2026 - 20:03 EUVD
CVE Published
Oct 30, 2026 - 18:30 cve.org
HIGH 8.2

DescriptionCVE.org

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.

Technical POC Analysis

Missing authorization / missing invariant binding, CWE-862 (the CVE record assigns it; the GHSA page itself lists "No CWEs").

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

CVE-2026-62162 is a high-severity flaw in Cardano Hydra heads (versions prior to 2.1.0) that allows any third party to steal pending deposits. Organizations using Hydra for layer-2 scaling are at risk of direct financial loss during deposit windows, which can undermine trust and disrupt operations.

Business Impact: High
Compensating Controls

No vendor-released patch identified at time of analysis. Interim mitigations: restrict access to deposit endpoints, monitor deposit transactions for unauthorized claims, and consider temporarily halting deposit operations until upgrade is possible.

Threat Intelligence Overview

EPSS Score
0.4%
Top 69% exploitable
Prevalence
Low
niche Cardano layer-2 scaling tool, limited production deployment
Data Quality
5 sources
Confidence: Medium

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.4%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

41
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +41
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Hydra

View all
CVE-2023-38701 CRITICAL POC
9.1 Oct 04

Hydra is the layer-two scalability solution for Cardano. Rated critical severity (CVSS 9.1), this vulnerability is remot

CVE-2023-42449 HIGH POC
8.1 Oct 04

Hydra is the two-layer scalability solution for Cardano. Rated high severity (CVSS 8.1), this vulnerability is remotely

CVE-2019-17502 HIGH POC
7.5 Oct 12

Hydra through 0.1.8 has a NULL pointer dereference and daemon crash when processing POST requests that lack a Content-Le

CVE-2019-8400 MEDIUM POC
6.1 Feb 17

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

CVE-2026-106439 HIGH
8.5 Oct 06

Code execution with the hosting application's privileges is possible in Hydra 1.3.4 through versions before 1.3.7 (and b

CVE-2023-42448 HIGH
8.1 Oct 04

Hydra is the layer-two scalability solution for Cardano. Rated high severity (CVSS 8.1), this vulnerability is remotely

CVE-2026-106440 HIGH
7.8 Oct 06

Configuration-controlled code execution in the hydra-optuna-sweeper package (Hydra 1.2.0 up to but not including 1.3.0,

CVE-2026-68508 HIGH
7.8 Aug 21

Arbitrary code execution in Facebook Research Hydra prior to version 1.3.4 allows any party who can supply untrusted con

CVE-2024-45049 HIGH
7.5 Aug 27

Hydra is a Continuous Integration service for Nix based projects. Rated high severity (CVSS 7.5), this vulnerability is

CVE-2023-42806 MEDIUM
6.5 Sep 21

Hydra is the layer-two scalability solution for Cardano. Rated medium severity (CVSS 6.5), this vulnerability is remotel

CVE-2024-32657 MEDIUM
5.4 Apr 22

Hydra is a Continuous Integration service for Nix based projects. Rated medium severity (CVSS 5.4), this vulnerability i

CVE-2020-5300 MEDIUM
5.3 Apr 06

In Hydra (an OAuth2 Server and OpenID Certified™ OpenID Connect Provider written in Go), before version 1.4.0+oryOS.17,

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy