Loading story…
Zcash developers executed an emergency network response after researchers disclosed a critical soundness bug in the Orchard shielded pool that could have allowed unlimited, undetectable counterfeit ZEC to be created inside Orchard. The flaw was reportedly discovered on May 29 by researcher Taylor Hornby during a commissioned audit, and Shielded Labs said a working exploit was reproduced in a local test environment. In response, engineers privately coordinated a soft fork that disabled Orchard transactions, followed by the NU6.2 hard fork that restored Orchard with a corrected circuit.
After the fix, Shielded Labs proposed an additional Zcash upgrade aimed at letting anyone verify that the total ZEC supply was not secretly inflated before remediation. Although the company said there is no cryptographic way to prove the bug was never exploited prior to the patch, the Zcash Foundation stated that turnstile accounting showed the overall supply remained intact and that it had found no evidence of unauthorized value creation. The disclosure also triggered volatility in ZEC and renewed debate over the centralization of Zcash's emergency response process and the auditability limits of privacy-preserving shielded pools.
Track how attackers are adapting to this technology.
5 events from the most recent confirmed update back to the earliest known activity.
The Zcash Foundation said the network’s turnstile accounting showed the total supply remained intact and that there was no evidence of unauthorized value creation. This statement addressed concerns that the Orchard flaw might have been exploited before the fix.
Shielded Labs proposed a further Zcash network upgrade so anyone can verify that the ZEC supply was not secretly inflated before the Orchard bug was fixed. The proposal followed disclosure of the vulnerability and concerns that there is no cryptographic way to prove the flaw was never exploited prior to remediation.
On June 3, Zcash re-enabled Orchard by deploying the NU6.2 hard fork with a corrected circuit. This hard fork served as the remediation step following the earlier emergency soft fork.
On June 2, Zcash engineers privately coordinated an emergency response and disabled Orchard transactions through a soft fork. This step was taken to contain the critical vulnerability before a full fix was deployed.
On May 29, researcher Taylor Hornby discovered a critical soundness vulnerability in Zcash’s Orchard shielded pool during a commissioned audit. Shielded Labs said the flaw could have allowed unlimited, undetectable counterfeit ZEC to be created within Orchard, and Hornby produced a working exploit in a local test environment.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Follow how adversaries are adapting to this technology, and where it touches your stack today.
6 references tracked. Mallory keeps watching after this page renders.
schneier.com
Open sourcescworld.com
Open sourcesecurityaffairs.com
Open sourcetradingview.com
Open sourcethedefiant.io
Open sourcecryptotimes.io
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Several high-severity flaws were disclosed in **Zebra**, the Rust-based Zcash node implementation, including bugs that can split consensus and remotely crash nodes. `CVE-2026-34377` describes a transaction verification cache logic error that could let a malicious miner reuse a valid transaction ID with invalid authorization data, causing vulnerable Zebra nodes to accept an invalid block and diverge from the main Zcash chain. A related advisory said improper sighash hash-type handling could leave isolated Zebra nodes tracking a fraudulent ledger state, creating downstream risk for exchanges, merchants, infrastructure providers, and block explorers that rely on those nodes. Additional Zebra issues can terminate nodes through denial-of-service conditions. `CVE-2026-34202` allows a remote unauthenticated attacker to send a crafted V5 transaction that passes deserialization but panics during transaction ID calculation, while another flaw in Orchard signature verification can trigger a fatal panic when an identity point is used as a randomized validating key. A separate `zebra-rpc` bug can also crash the daemon through interrupted JSON-RPC requests, though exploitation is more limited because authentication is required and the interface binds to localhost by default. The affected issues were patched in **zebrad 4.3.0**, with related fixes in **zebra-consensus 5.0.1** and **zebra-chain 6.0.1**.
Jun 29, 2026
A public disclosure detailed eight **OpenZFS on Linux** vulnerabilities, tracked as `OZ-1` through `OZ-8`, that weaken authorization checks and expose multiple import-time parser bugs. The report says pool-control ioctls improperly trust namespace-local `CAP_SYS_ADMIN` from unprivileged user namespaces and containers when `/dev/zfs` is accessible, allowing host pool operations from confined environments. Reported parser flaws include out-of-bounds reads and writes, a controlled heap overflow, a stack overflow, unbounded traversal, and a cache-destroy hang; `OZ-4` was demonstrated as both a container-to-host-root exploit in a research VM and a reliable host-kernel denial-of-service path via malicious OCI images on **TrueNAS SCALE** and **IncusOS**. Testing cited in the disclosure covered **IncusOS, TrueNAS SCALE, Proxmox VE, and Unraid**, while noting that a tested **RHEL 10.2** configuration with **OpenZFS 2.2.10** plus **SELinux/STIG/FIPS** blocked `OZ-1` and `OZ-2`. The report said all OZ findings remained unfixed in upstream master as of `2026-07-24`, except for `OZ-7`, which had an open contested pull request. Separately, Linux kernel documentation notes that kernel CVE assignment is conservative, generally tied to fixes already merged into supported stable trees, and excludes unsupported versions and distribution-specific issues, leaving downstream vendors and users to determine applicability and prioritize full released updates over cherry-picking individual fixes.
Aug 17, 2026
A critical Cosmos EVM balance-reconciliation flaw, tracked as `GHSA-7g4w-cg88-2cq2`, was exploited to drain assets from six Cosmos-based chains. The bug allows an unchecked underflow in a vesting account’s delegated balance to wrap to roughly `2^256`, corrupting reconciliation between EVM state and the Cosmos SDK `x/bank` module and enabling unauthorized minting or burning. Attackers reportedly sold about **$5.72 million** in affected assets through decentralized and centralized exchanges; KiiChain alone reported the theft of 148 million KII, valued at about $9.7 million at the cited price, while an attacker moved 2.99 billion TAC from a TAC account. Cosmos Labs released fixes in Cosmos EVM `v0.6.2` and `v0.7.2` and urged operators of affected public chains to coordinate upgrades or halt block production, as no configuration-only mitigation exists. MANTRA resumed operations using a patched `v8.4.0` binary, while TAC and KiiChain remained halted; KiiChain alleged that public availability of the state-breaking patch before private operator notification created an exploitable window and said two of three upstream defects were still unpatched. Blocking permissionless creation of vesting accounts removes the exploit precondition, but operators still need to deploy the patched releases.
Aug 30, 2026