Threats affecting pkg:github/cardano-scaling/hydra

## Summary Hydra's `instantiate()` API resolves and invokes Python callables named by the `_target_` field in configuration. The target blacklist introduced for CVE-2026-68508 was incomplete. Representative bypasses included execution wrappers such as `timeit.timeit`, executable deserialization through `pickle.loads`, and generic dispatch or wrapper targets that obscured the effective callable. Target aliases, callable-returning helpers, and deferred dispatch could similarly bypass name-based checks. An attacker who can cause an application to instantiate an untrusted Hydra configuration can use these gaps to execute code with the application's privileges. ## Fix Hydra 1.3.6 expands and hardens the blacklist used by the 1.3 compatibility line. It blocks the reported execution and deserialization surfaces, checks canonical callable identities and aliases, mediates callable results, and blocks generic dispatch and wrapper targets that bypass immediate target checks. The Hydra 1.3 blacklist is a best-effort, defense-in-depth measure. It is not a complete security boundary and does not make untrusted configuration safe to instantiate. Hydra 1.4.0.dev9 applies the same hardening and introduces the execution whitelist as the recommended primary security boundary. When a whitelist is supplied, targets are rejected unless trusted Python code authorizes them. If no whitelist is supplied, Hydra preserves legacy behavior with a deprecation warning and the blacklist as a best-effort compatibility fallback. Targets that permit configuration to select or supply executable behavior remain non-whitelistable. ## Remediation Upgrade to Hydra 1.3.6, or to Hydra 1.4.0.dev9 or later when testing the 1.4 prerelease line. On Hydra 1.3, do not instantiate configuration from untrusted sources. On Hydra 1.4 and later, constrain untrusted configuration with a narrow execution whitelist supplied by trusted Python code. For Hydra 1.4 execution-whitelist configuration, see: https://hydra.cc/docs/advanced/execution_whitelist/

Ory Hydra is an OAuth 2.0 Server and OpenID Connect Provider. Prior to version 26.2.0, the listOAuth2Clients, listOAuth2ConsentSessions, and listTrustedOAuth2JwtGrantIssuers Admin APIs in Ory Hydra are vulnerable to SQL injection due to flaws in its pagination implementation. Pagination tokens are encrypted using the secret configured in `secrets.pagination`. If this value is not set, Hydra falls back to using `secrets.system`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection. This issue can be exploited when one or more admin APIs listed above are directly or indirectly accessible to the attacker; the attacker can pass a raw pagination token to the affected API; and the configuration value `secrets.pagination` is set and known to the attacker, or `secrets.pagination` is not set and `secrets.system` is known to the attacker. An attacker can execute arbitrary SQL queries through forged pagination tokens. As a first line of defense, immediately configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret. Next, upgrade Hydra to the fixed version, 26.2.0 as soon as possible.

Hydra is a layer-two scalability solution for Cardano. Prior to version 0.22.0, the process assumes L1 event finality and does not consider failed transactions. Currently, Cardano L1 is monitored for certain events which are necessary for state progression. At the moment, Hydra considers those events as finalized as soon as they are recognized by the node participants making such transactions the target of re-org attacks. The system does not currently consider the fact that failed transactions on the Cardano L1 can indeed appear in blocks because these transactions are so infrequent. This issue has been patched in version 0.22.0.