Los 3 principales incidentes de seguridad en junio
Los tres incidentes más grandes de junio no surgieron de ningún error aislado. Expusieron un fallo compartido. En la superficie, una garantía de seguridad parecía intacta, pero por debajo nunca se aplicó realmente. Un bot MEV confiaba en operaciones que parecían rentables sin confirmar que las aprobaciones fueron verdaderamente consumidas. Dos rollups retirados aceptaron pruebas que eran válidas en forma pero que nunca estuvieron vinculadas al estado de liquidación que afirmaban representar. El código de firma de una billetera descartó silenciosamente el único input secreto del que dependía su seguridad, convirtiendo un valor que debía ser impredecible en algo que cualquiera podía recalcular a partir de datos públicos. Ninguno de estos sistemas fue vulnerado mediante criptoanálisis por fuerza bruta. Fueron vulnerados por una suposición que nadie verificó jamás.
JaredFromSubway: ~$15M
El 20 de junio de 2026, JaredFromSubway, un operador de bot MEV en Ethereum, fue vaciado de aproximadamente $15M en un ataque honeypot.
El atacante construyó un entorno de trading falso con tokens wrapper falsos y pools falsos de estilo Uniswap V2 que emiten eventos Swap / Sync realistas. En un flujo legítimo, la función wrapTo() del contrato wrapper debería llamar internamente a transferFrom() sobre el token real subyacente, consumiendo la aprobación que el bot había otorgado previamente. Sin embargo, el contrato del token wrapper falso omitió este paso por completo mientras seguía devolviendo una pequeña ganancia diseñada por el atacante a través de unwrap(). Debido a que el bot no verificó si las aprobaciones fueron realmente consumidas ni revocó las aprobaciones residuales, las aprobaciones no consumidas se acumularon y fueron posteriormente extraídas a través de withdraw(). Una billetera afectada perdió aproximadamente 1,474.58 WETH, 2,870,573 USDC y 2,035,760 USDT. JaredFromSubway reportó posteriormente una pérdida total de aproximadamente $15M en las billeteras afectadas.
La lección es que los bots MEV deben tratar el código desconocido de tokens y pools como hostil, incluso cuando las simulaciones parecen rentables. Las estrategias automatizadas requieren listas blancas estrictas de gastadores, verificaciones de hash de código, verificación de aprobaciones tras la operación y limpieza de aprobaciones residuales.
Incidentes en los Rollups Legacy de Aztec: ~$4.35M
En junio de 2026, dos despliegues legacy separados de Aztec fueron explotados, resultando juntos en aproximadamente $4.35M en pérdidas. Aunque las causas raíz fueron diferentes, ambos incidentes ocurrieron en el límite entre la validez de la prueba y la semántica de liquidación.
El primer incidente afectó al RollupProcessorV3 de Aztec Connect el 14 de junio de 2026, causando aproximadamente $2.15M en pérdidas. El atacante estableció numTxs en 1 mientras introducía subrepticiamente un depósito real en un slot posterior decodificado, de modo que la ruta de la prueba acreditaba el valor internamente mientras la lógica de liquidación de L1 omitía la invocación correspondiente de decreasePendingDepositBalance(). El atacante luego retiró el saldo resultante sin respaldo a través de los canales normales.
El segundo incidente afectó a un despliegue separado de legacy PrivateRollupBridge / RollupProcessor el 18 de junio de 2026, resultando en aproximadamente $2.2M en pérdidas. Este despliegue aún exponía una ruta escapeHatch(bytes,bytes,bytes), y su circuito nunca restringió la raíz de membresía join-split privada para que coincidiera con el oldDataRoot público consumido por L1. Esto permitió al atacante demostrar la propiedad de notas de alto valor en un árbol privado falso mientras publicaba el dataRoot real de L1 como raíz pública. El verificador aceptó la prueba y el contrato L1 ejecutó el retiro.
En conjunto, estos incidentes demuestran que la verificación de pruebas por sí sola no es suficiente. Cada valor que rige los límites de liquidación debe estar vinculado a los inputs públicos exactos que verifica la prueba, y cada testigo privado debe estar explícitamente restringido para que coincida con el estado público que la liquidación realmente consume.
SecondFi: ~$2.4M
El 23 de junio de 2026, SecondFi (anteriormente Yoroi), una extensión de billetera para navegador desarrollada por EMURGO, reveló un fallo crítico en su implementación de firma Ed25519, que afectó a las versiones v10.0.3 a v10.0.6.
El código vulnerable derivaba el nonce de firma únicamente a partir del mensaje de transacción público, omitiendo un prefijo de nonce secreto requerido. Eso convirtió la ecuación de firma en una única incógnita, permitiendo que cualquiera recuperara la clave privada de una billetera directamente a partir de datos públicos en la cadena. Dos atacantes explotaron el fallo de forma independiente, drenando aproximadamente $2.4M (16M ADA) de 374 billeteras antes de que EMURGO rescatara otros 129M ADA.
La lección es que el código de firma de las billeteras necesita el mismo nivel de escrutinio que la criptografía a nivel de protocolo. Omitir un único input secreto, incluso uno que parezca menor, puede comprometer completamente las claves privadas, por lo que las implementaciones personalizadas de Ed25519 deberían someterse a una auditoría independiente en lugar de tratarse como una biblioteca estándar de confianza.
Mención especial: Bug de solidez de Zcash Orchard
No llegó al Top 3 porque no se ha confirmado ninguna explotación, pero el bug de solidez de Zcash Orchard fue una de las divulgaciones más significativas de junio. Divulgado públicamente el 4 de junio de 2026, el bug era una restricción de igualdad faltante en el circuito del pool blindado Orchard que podría haber permitido que la misma nota blindada produjera diferentes nullifiers y fuera gastada más de una vez. El fallo había existido desde la activación de Orchard en mayo de 2022 y fue parcheado mediante la actualización de emergencia NU6.2.
El incidente reafirma la lección más profunda del caso Aztec. En un sistema ZK, la seguridad depende de lo que el circuito realmente restringe, no de lo que el protocolo circundante asume que restringe.
Leer el análisis del bug de Zcash Orchard
La información anterior está basada en datos a partir de las 00:00 UTC del 1 de julio de 2026.
Esto concluye el informe de incidentes de seguridad de febrero.
Puede obtener más información en nuestra Biblioteca de Incidentes de Seguridad.
¡Manténgase informado y seguro!
