Por: Neal Jayu [], Daira-Emma Hopwood [], Kris Nuttycombe [*], Zooko Wilcox [†]
[*] Zcash Open Development Lab, [†] Shielded Labs
Puntos Clave
- Se descubrieron y parchearon varias vulnerabilidades en zcashd y Zebra, incluyendo un error que podía bloquear nodos al manejar ciertas transacciones Orchard, una brecha en la aplicación del consenso entre las dos implementaciones que podría haber desencadenado una bifurcación de cadena, un error que podía deshabilitar la aplicación del conteo del torniquete de zcashd, y comportamiento indefinido debido a aritmética de enteros sin verificar en cálculos de saldos de pools.
- Las vulnerabilidades no fueron explotadas para afectar la cadena de consenso. Todos los fondos de usuarios están seguros, y la privacidad de los usuarios no estuvo en riesgo.
- Ninguna de estas vulnerabilidades podría haber sido usada por sí sola para inflar el suministro de ZEC. La vulnerabilidad que podría haber sido usada para deshabilitar el mecanismo del torniquete no es explotable de forma independiente sin una vulnerabilidad de falsificación adicional y separada. En ese caso, cualquier violación del torniquete en la cadena habría sido públicamente detectable.
- Las vulnerabilidades fueron divulgadas a través de nuestro proceso de divulgación coordinada por el investigador de seguridad Alex "Scalar" Sol – el mismo investigador que reportó la vulnerabilidad de verificación Sprout de marzo de 2026 – el 4 de abril de 2026. Los parches para zcashd, que también abordan posibles vectores de explotación adicionales, fueron desarrollados por ingenieros de Zcash Open Development Lab (ZODL). Un parche para Zebra fue desarrollado por ingenieros de la Zcash Foundation.
- Tanto zcashd como Zebra requirieron parches y fueron actualizados de forma coordinada antes de la divulgación pública.
- Los pools de minería que representan una supermayoría del poder de hash de la red, y el operador principal ejecutando Zebra en producción de minería, desplegaron los parches antes de esta divulgación.
| Versiones Afectadas | Versión Corregida |
|---|---|
| zcashd | |
| v5.0.0 hasta v6.12.0 | v6.12.1 |
| Zebra | |
| v1.0.0 hasta v4.3.0 | v4.3.1 |
Resumen
El investigador de seguridad Alex "Scalar" Sol identificó un conjunto de vulnerabilidades tanto en zcashd como en Zebra, las dos implementaciones de nodo completo del protocolo Zcash. Ingenieros de Zcash Open Development Lab (ZODL) y la Zcash Foundation desarrollaron y revisaron correcciones para ambas implementaciones, y coordinaron su despliegue con pools de minería y operadores de nodos antes de esta divulgación pública.
Las vulnerabilidades no fueron explotadas para afectar la cadena de consenso. Todos los fondos de usuarios están seguros, y la privacidad de los usuarios no estuvo en riesgo. Puedes verificar esto ejecutando Zebra v4.3.1 o zcashd v6.12.1: ambas implementaciones actualizadas validan independientemente la blockchain de Zcash y confirman que solo transacciones válidas han sido añadidas a la cadena.
La más directamente explotable de las fallas, presente desde zcashd v5.0.0, era un bloqueo: una transacción Orchard elaborada podía hacer que cualquier nodo zcashd o Zebra accesible entrara en pánico y terminara. Confirmamos que no existen transacciones que desencadenen esta condición en la mainnet, y no se reportaron bloqueos de nodos inexplicables antes de la corrección. Un error relacionado – una discrepancia entre la aplicación de zcashd y Zebra de un requisito del protocolo Orchard – podría haber sido usado para publicar una transacción que zcashd aceptaría y Zebra rechazaría, forzando una bifurcación de cadena.
Un error separado en zcashd, introducido en v5.10.0, podía deshabilitar el conteo del torniquete de Zcash – el mecanismo que rastrea y aplica los saldos de ZEC entre pools de valor. Esto podía ocurrir bajo ciertas condiciones de red que podrían surgir de la operación P2P ordinaria, o podría ser desencadenado deliberadamente por un par malicioso. Este error no es explotable de forma independiente para crear transacciones Zcash inválidas; explotarlo para robar fondos requeriría una vulnerabilidad de saldo separada e independiente además de este. Además, cualquier violación del torniquete sería observable públicamente como una anomalía, con un rollback disponible como remedio. No ocurrió tal evento.
Un problema potencial en zcashd, relacionado con el anterior, que podría haber causado que valores de conteo de cadena en disco fueran corrompidos por un par malicioso también ha sido remediado.
En el curso de abordar estas vulnerabilidades, los ingenieros de ZODL también añadieron endurecimiento a la aritmética de saldos de pools para prevenir comportamiento indefinido en casos extremos donde un bloque elaborado maliciosamente podría desencadenar desbordamiento de enteros con signo en C++, y mejoraron la seguridad de excepciones en caso de detección de desbordamiento.
Este es el segundo conjunto de vulnerabilidades de Zcash divulgadas dentro de un mes. Creemos que el patrón aquí es uno bueno: un investigador que regresa con más hallazgos, reportando nuevamente a través de nuestros canales de divulgación coordinada. La amplitud y minuciosidad de esta investigación –abarcando dos implementaciones y revelando cuatro problemas distintos en el lapso de una semana– refleja el tipo de escrutinio de seguridad serio que un protocolo financiero debería recibir y que el ecosistema Zcash es cada vez más capaz de manejar. Las organizaciones involucradas trabajan en coordinación cercana, y la respuesta aquí lo demuestra.
Antecedentes
Zcash mantiene varios pools de valor blindados: Sprout (en desuso), Sapling y Orchard. Cada uno está protegido por pruebas de conocimiento cero que aseguran que solo transacciones válidas puedan mover ZEC y que nuevos ZEC solo sean creados por emisión de recompensas de bloque. Los fondos transparentes y la caja fuerte (lockbox) también se consideran pools de valor.
Orchard es el pool blindado actual de Zcash, introducido con la actualización de red NU5 en mayo de 2022. Dos de las vulnerabilidades en este reporte involucran cómo campos específicos de transacciones dentro de acciones Orchard son validados por las reglas de consenso.
Un mecanismo de seguridad fundamental en el protocolo Zcash es el torniquete: una restricción de contabilidad que rastrea el saldo total de ZEC en cada pool de valor (Sprout, Sapling, Orchard, transparente y caja fuerte) y limita cuánto valor puede fluir entre pools. Los torniquetes están especificados en ZIP 209 y la sección 4.17 de la especificación del protocolo Zcash. Funcionan como puertas blindadas: incluso si una vulnerabilidad fuera usada para falsificar valor dentro de un pool, cualquier intento de mover valor total excesivo a otro pool sería prevenido. Es decir, actúan como una segunda línea de defensa para propiedades de saldo que el protocolo está destinado a aplicar. Esto es esencial para entender la vulnerabilidad relacionada con el torniquete en este reporte – y por qué no representa una amenaza independiente para los fondos de usuarios.
Divulgación por Terceros
Alex "Scalar" Sol reportó las vulnerabilidades a Shielded Labs el 4 de abril de 2026.
Tras recibir el reporte, Shielded Labs coordinó con ingenieros principales de ZODL para validar los problemas y desarrollar parches. Daira-Emma Hopwood y Kris Nuttycombe analizaron y validaron las vulnerabilidades. Kris Nuttycombe escribió los parches que abordan el bloqueo de Orchard, la brecha en la aplicación del consenso y el error de contabilidad del torniquete; Daira-Emma Hopwood escribió dos parches de endurecimiento que abordan el desbordamiento de enteros y la seguridad de excepciones, y cambios adicionales para introducir un punto de control de suministro de cadena y recalcular los deltas de valor de cadena. Daira-Emma Hopwood y Kris Nuttycombe revisaron el trabajo del otro, y Zooko Wilcox revisó y comentó extensamente sobre el conjunto de parches que se proporcionaron a los socios. Hemos comenzado a usar IA en mayor medida en nuestro trabajo; partes del análisis de vulnerabilidades y remediación fueron asistidas por Claude Opus 4.6, con revisión humana exhaustiva.
Shielded Labs divulgó los problemas a la Zcash Foundation el 6 de abril de 2026. Conrado Gouvêa de la Zcash Foundation escribió el parche de Zebra que aborda la vulnerabilidad de bloqueo de Orchard y la discrepancia relacionada en la aplicación.
Shielded Labs lideró el contacto con pools de minería y proveedores de infraestructura para coordinar el despliegue de parches. Los pools de minería incluyendo ViaBTC, Luxor, F2Pool y AntPool – que ejecutan zcashd – fueron contactados directamente para coordinar actualizaciones. Foundry, que ejecuta Zebra en producción de minería, también fue contactado y recibió el parche de Zebra antes del lanzamiento público.
El conjunto de parches de zcashd enviado a los pools de minería fue intencionalmente mantenido simple para minimizar el riesgo de regresiones. Los cambios en zcashd en v6.12.1 tienen estos parches y también un conjunto más extenso de cambios de endurecimiento y pruebas, incluyendo la adición de un punto de control de valor de suministro de cadena en la activación de NU6.1, y recálculo de los deltas después de ese punto para permitir que cualquier corrupción de los valores persistidos sea detectada.
Cronología
- 21 de mayo de 2019: La aplicación del torniquete a nivel de consenso de ZIP 209 fue desplegada con el lanzamiento de zcashd v2.0.5.
- 14 de junio de 2023: Lanzamiento de Zebra v1.0.
- 27 de agosto de 2024: La vulnerabilidad que podía deshabilitar la aplicación del torniquete y permitir desbordamiento de enteros (Comportamiento Indefinido) fue introducida con el lanzamiento de zcashd v5.10.0.
- 4 de abril de 2026: Alex "Scalar" Sol reportó las vulnerabilidades a Shielded Labs.
- 5 de abril de 2026: Shielded Labs se reunió con los ingenieros de ZODL Daira-Emma Hopwood y Kris Nuttycombe para revisar y validar las vulnerabilidades.
- 6 de abril de 2026: Shielded Labs divulgó los problemas a la Zcash Foundation. Comenzó el desarrollo de parches. Kris Nuttycombe escribió los parches iniciales que abordan la vulnerabilidad de bloqueo de Orchard y el error de contabilidad del torniquete.
- 10 de abril de 2026: Daira-Emma Hopwood completó dos parches de endurecimiento que abordan el comportamiento indefinido de desbordamiento de enteros y seguridad de excepciones. Conrado Gouvêa (Zcash Foundation) completó el parche de Zebra. Los parches fueron proporcionados a socios del ecosistema.
- 11 de abril de 2026: El pool de minería F2Pool desplegó el parche de zcashd.
- 16 de abril de 2026: Los pools de minería Luxor y Foundry confirmaron el despliegue de los parches de zcashd y Zebra, respectivamente.
- 17 de abril de 2026: El pool de minería ViaBTC confirmó el despliegue del parche de zcashd. zcashd v6.12.1 y Zebra v4.3.1 fueron lanzados públicamente.
Detalles de las Vulnerabilidades
Bloqueo de Nodos Orchard mediante Clave Aleatorizada de Identidad
El protocolo blindado Orchard incluye una clave de firma re-aleatorizable, rk, en cada acción de transacción. La especificación del protocolo Zcash permite que rk tome cualquier valor en el grupo Pallas, incluyendo el punto de identidad. Sin embargo, la implementación de la verificación de pruebas Orchard tanto en zcashd como en Zebra entraría en pánico al encontrar la identidad rk durante la construcción de la instancia de prueba – causando que ambos nodos se bloqueen.
Un atacante podría explotar esto transmitiendo una transacción elaborada con una acción Orchard teniendo una codificación rk de todos ceros (la única codificación del punto de identidad de Pallas). Cualquier nodo zcashd o Zebra que recibiera y procesara tal transacción se bloquearía inmediatamente. Un ataque sostenido repitiendo esta transacción podría prevenir que los nodos participaran en la red.
Ambas implementaciones fueron parcheadas independientemente:
- zcashd: Kris Nuttycombe añadió una verificación
validate_action_encodings()enCheckTransactionWithoutProofVerification, que se ejecuta antes de la verificación de pruebas tanto en las rutas de validación de mempool como de bloques. La verificación compara rk contra su codificación canónica de todos ceros y rechaza cualquier transacción que contenga tal valor con una penalizaciónDoS(100, REJECT_INVALID). - Zebra: Conrado Gouvêa (Zcash Foundation) añadió un rechazo en tiempo de deserialización, retornando un error de serialización si rk codifica el punto de identidad.
La especificación del protocolo será actualizada para alinearla con las implementaciones. (Usualmente es más seguro en casos de divergencia entre implementaciones y la especificación alinear la más permisiva con la más estricta, de modo que el efecto en el consenso sea a lo sumo un soft fork.)
No se encontraron transacciones conteniendo valores rk de identidad en la mainnet de Zcash, confirmando que esta vulnerabilidad no fue explotada en la cadena de consenso antes de la corrección.
Brecha en la Aplicación del Consenso: Clave Efímera de Identidad
La especificación del protocolo Zcash (§5.4.9.4) requiere que la clave pública efímera epk en cada acción Orchard codifique un punto no-identidad en la curva Pallas. Zebra aplica este requisito en tiempo de deserialización. zcashd no lo aplicaba en absoluto.
Esta discrepancia creaba una potencial división de consenso: una transacción elaborada conteniendo un epk de identidad sería aceptada por zcashd pero rechazada por Zebra. Un atacante publicando tal transacción podría hacer que nodos zcashd y Zebra discreparan sobre la validez de un bloque, bifurcando la red.
El parche que aborda la vulnerabilidad de bloqueo de rk cierra simultáneamente esta brecha: la función validate_action_encodings() ahora verifica tanto rk como epk, alineando a zcashd completamente con la implementación de Zebra y la especificación del protocolo. No se encontraron valores epk de identidad en la mainnet.
Elusión de la Contabilidad del Torniquete mediante Encabezado de Bloque Duplicado
El mecanismo de torniquete de Zcash rastrea el saldo total de ZEC en cada pool de valor (Sprout, Sapling, Orchard, transparente y caja fuerte), y aplica invariantes sobre cuánto valor puede fluir entre pools. Estas verificaciones se ejecutan durante la conexión de bloques y requieren que se conozca el saldo de cadena por pool. Cuando el saldo de cadena de un pool es nullopt – significando que su valor no está siendo rastreado – la verificación correspondiente del torniquete se omite.
Un error en cómo zcashd inicializa los saldos de pools durante el procesamiento de bloques significaba que recibir un bloque cuyo encabezado coincidiera con un bloque visto previamente sobrescribiría silenciosamente los campos de saldo de pool para esa entrada de índice de bloque con nullopt. Esto deshabilitaría la aplicación del torniquete para todos los bloques subsiguientes. Críticamente, recibir anuncios de bloques duplicados de múltiples pares es comportamiento rutinario de red P2P, lo cual implica que esta condición podría surgir en operación ordinaria, no solo bajo ataque deliberado. Bajo ataque deliberado, un par malicioso podría retransmitir cualquier encabezado de bloque ya aceptado para reiniciar la contabilidad de pools, sin necesidad de ser un minero ni tener acceso especial.
La causa raíz fue una llamada de función mal colocada. SetChainPoolValues –que inicializa campos delta por pool y reinicia campos de saldo de cadena a nullopt en preparación para acumulación posterior– fue llamada en AcceptBlock antes de la verificación de si el encabezado de bloque ya había sido visto. La corrección mueve esta llamada a ReceivedBlockTransactions, al cual solo se llega para bloques genuinamente nuevos y solo después de la validación de la raíz de Merkle, asegurando que la contabilidad de pools nunca sea reiniciada por encabezados retransmitidos o duplicados.[1]
Este error no es explotable de forma independiente para crear o robar ZEC. Eludir la verificación del torniquete no permite por sí mismo violaciones de saldo – solo significa que una vulnerabilidad de saldo separada e independiente podría potencialmente causar daño a través de múltiples pools en lugar de estar contenida a uno. Además, de haberse explotado tal combinación, cualquier bloque violando el torniquete habría sido rechazado por nodos Zebra –así como por nodos zcashd recién sincronizados o reindexados– resultando en una bifurcación de cadena públicamente visible. No ocurrió tal evento.
zcashd también tenía un problema relacionado que podría haber permitido que un par malicioso corrompiera los valores de contabilidad de cadena en disco – específicamente, los deltas entre saldos de cadena "antes" y "después" en un bloque dado. El impacto sería que después de un reinicio, el torniquete podría activarse al nivel incorrecto relativo a los límites correctos.
Si el ataque descrito anteriormente fuera usado para corromper valores delta en memoria en el índice de bloques, el valor de cadena acumulado normalmente se establecería en nullopt, significando que los valores corruptos no podrían ser observados directamente (excepto vía RPC getblock en bloques específicos) y no persistirían cuando el nodo se reinicia. Sin embargo, bajo algunas circunstancias los deltas incorrectos podrían persistirse a disco. La corrección añade un punto de control para estos valores en la activación de NU6.1, y recalcula los deltas después de ese punto desde datos de bloque. Si los valores persistidos son inconsistentes con los recalculados más allá del punto de control, zcashd v6.12.1 en adelante abortará al iniciar y requerirá una reindexación, lo cual corrige los valores en disco. (Es suficiente para la aplicación del torniquete que sean correctos en la cadena principal más allá de NU6.1; deltas anteriores solo pueden observarse vía RPC getblock y no se usan de otra forma.) Nótese que esta defensa contra corrupción pasada no puede aplicarse a nodos que habilitaron el pruning (que no es el default ni una configuración común en el ecosistema Zcash). Los usuarios de nodos con pruning deberían verificar en cambio que los valores de pool de cadena retornados por el RPC getblockchaininfo coincidan con los de un nodo sin pruning en el mismo bloque.
Los torniquetes son una capa importante de defensa, y su operación correcta es central para las garantías de seguridad del protocolo. Tratamos cualquier condición que los deshabilite – incluso una que no sea explotable independientemente – como una corrección de alta prioridad.
Endurecimiento contra Desbordamiento de Enteros en Contabilidad de Saldos de Pools
En C++, el desbordamiento de enteros con signo es comportamiento indefinido: el compilador puede asumir que no puede ocurrir y puede optimizar el código circundante bajo esa suposición. En las rutinas de acumulación de saldos de pools de zcashd, era posible construir un bloque elaborado maliciosamente que desencadenara desbordamiento de enteros con signo durante el cálculo de deltas de valor por pool. Dependiendo del compilador y sus configuraciones de optimización, este comportamiento indefinido podría potencialmente haber causado que verificaciones del torniquete fueran omitidas, que la validación de consenso retornara temprano, o que valores de saldo de pool fueran calculados incorrectamente.
Daira-Emma Hopwood abordó esto con dos parches. El primero añade verificaciones explícitas de rango usando un nuevo helper MoneyDeltaRange – verificando que las sumas corrientes de deltas por pool permanezcan dentro de [-MAX_MONEY, MAX_MONEY] en cada punto de acumulación en SetChainPoolValues, ReceivedBlockTransactions, ConnectBlock y LoadBlockIndexDB. Estas verificaciones también protegen contra datos de saldo en disco corruptos que puedan haber sido escritos por una versión vulnerable previa. El segundo parche envuelve todas las llamadas de consenso relevantes a funciones de cálculo de valor en manejadores explícitos de excepciones, asegurando que cualquier valor fuera de rango produzca un rechazo de consenso DoS(100, REJECT_INVALID) apropiado en lugar de una excepción no manejada.
Agradecimientos
Gracias a Alex "Scalar" Sol por descubrir estas vulnerabilidades y divulgarlas de manera responsable para proteger a los usuarios de Zcash – su segunda divulgación de este tipo al ecosistema Zcash.
Agradecimientos especiales a Kris Nuttycombe y Daira-Emma Hopwood de ZODL por su análisis exhaustivo, desarrollo rápido de parches y revisión cuidadosa del trabajo del otro.
Gracias a Conrado Gouvêa de la Zcash Foundation por el parche de Zebra y por la coordinación de la Fundación a lo largo del proceso.
Gracias también a Judah Caruso de Shielded Labs, quien trabajó estrechamente con pools de minería, CEXs y otros proveedores de infraestructura para asegurar que ellos y Zcash estuvieran protegidos.
Extendemos nuestro agradecimiento a ViaBTC, Luxor, F2Pool y Foundry por su despliegue de parches antes de la divulgación pública.
Traducción del original en inglés de ZODL
Si quieres aprender más sobre privacidad en la economía digital descentralizada, te puedes unir a la comunidad de Zcash en Español en Telegram. Para conectar con el ecosistema digital de Zcash Español, visita nuestro Privacidad.me.
