Aztec Connect: 2,19 M$ robados de un contrato muerto

Un contrato que llevaba más de dos años imparcheable por decisión de su propio equipo perdió unos 2,19 millones de dólares en una sola transacción. El 14 de junio de 2026, un atacante vació el contrato RollupProcessor de Aztec Connect —un puente de privacidad sobre Ethereum que Aztec Labs había deprecado (retirado del servicio)—. Aztec Connect anunció su cierre en marzo de 2023 (depósitos cortados el 31 de marzo) y renunció a las admin keys (las llaves de administración que permiten modificar o pausar un smart contract) un año después, en marzo de 2024, al apagar el secuenciador. Desde esa renuncia de llaves —el momento en que el contrato quedó realmente imparcheable— hasta el exploit pasaron unos dos años y tres meses. El equipo hizo lo que la comunidad considera «lo correcto»: dejar que nadie, ni siquiera ellos, pudiera tocarlo. El problema es que el dinero seguía dentro. Este artículo analiza por qué deprecar un protocolo y dejarlo inmutable con fondos vivos no es seguridad máxima, sino un bug latente convertido en bomba sin desactivador, y qué debería incluir un cierre responsable.

¿Qué pasó exactamente en Aztec Connect el 14 de junio?

El 14 de junio de 2026, un atacante interactuó con el contrato RollupProcessor de Aztec Connect en Ethereum y extrajo, en una única transacción atómica (todo o nada, sin pasos intermedios reversibles), una cesta de activos valorada en torno a 2,19 millones de dólares. Según el desglose publicado por SlowMist (firma de ciberseguridad blockchain con sede en China, conocida por sus análisis forenses de hacks DeFi), el botín incluía ETH, DAI, wstETH, LUSD y varios vaults de Yearn (yvDAI, yvWETH, yvLUSD). Los fondos pasaron del contrato a un contrato-puente intermedio y de ahí a una wallet externa controlada por el atacante.

Un dato que conviene subrayar: al cierre de los análisis técnicos, y según SlowMist, el 100 % de los fondos seguía intacto en la dirección del atacante, sin que hubiera empezado el proceso de blanqueo. Eso es relevante porque significa que no fue un robo desesperado para mover deprisa, sino la explotación tranquila de un objetivo que llevaba años sin que nadie lo vigilara.

Aztec Labs y la Aztec Foundation confirmaron que el contrato explotado no tiene ninguna relación con el token AZTEC ni con los smart contracts de la red Aztec actual. El daño quedó confinado al producto legacy. Pero el episodio no terminó ahí: tres días después llegó un segundo golpe.

¿Hubo un segundo exploit y por qué importa la cronología?

El 17 de junio de 2026, un segundo incidente afectó a otro contrato legacy del ecosistema Aztec —descrito por varias fuentes como un mecanismo de retirada de emergencia (escapeHatch) de un puente de rollup privado también deprecado—. Los montos reportados varían entre 2,15 y 2,21 millones de dólares según la fuente (Coinpedia lo cifró en torno a 2,16 M$; CryptoTimes, en unos 2,21 M$), es decir, ~2,16 M$ de media entre fuentes. Sumados a los 2,19 millones del primer golpe, medios como CoinJournal y NullTX cifraron las pérdidas en más de 4 millones de dólares en tres días a través de dos sistemas legacy distintos.

BlockSec (firma de análisis on-chain y auditoría de smart contracts) describió ambos incidentes como ligados a «problemas de vinculación de public inputs» (cómo el contrato ata los datos de entrada de una prueba criptográfica a lo que realmente se liquida), aunque aclaró que los métodos de ataque no eran idénticos. La cronología importa porque dibuja un patrón: un mismo equipo, varios contratos apagados años atrás, todos imparcheables, todos con saldo, cayendo uno tras otro en cuestión de días. No es mala suerte; es el resultado predecible de una decisión de diseño.

Nota de cautela: las cifras exactas del segundo incidente y el total agregado todavía no estaban consolidadas entre todas las fuentes al cierre de este artículo. Las tratamos como reportes atribuidos, no como cifra definitiva.

¿Por qué un contrato deprecado en 2023 seguía teniendo millones dentro?

Aquí está la paradoja que da sentido a todo el caso. Aztec Connect era un puente que permitía a los usuarios mover activos hacia un entorno privado sobre Ethereum y operar con ellos. Cuando Aztec Labs decidió pivotar hacia una red nueva, anunció el cierre del producto en marzo de 2023, cortó los depósitos el 31 de marzo y abrió una ventana para que los usuarios retiraran sus fondos. Solo un año después, en marzo de 2024 —tras cerrarse esa ventana—, apagó el secuenciador y renunció a las admin keys, congelando el contrato de forma definitiva.

Pero «abrir una ventana de retirada» no es lo mismo que «vaciar el contrato». Siempre hay usuarios que no se enteran, que perdieron las claves, que dieron el dinero por perdido o que simplemente no actuaron. Dos años después de soldar la puerta, ese remanente —el dinero de la gente que nunca volvió— seguía depositado en un contrato que nadie operaba. En la jerga, esto es TVL (total value locked, valor total bloqueado) huérfano: capital vivo dentro de código muerto.

• El producto estaba muerto: sin equipo asignado, sin monitorización activa, sin auditorías nuevas.
• El dinero estaba vivo: ETH, stablecoins y activos con rendimiento, perfectamente extraíbles para quien encontrara el fallo.
• El contrato era inmutable: ni el equipo ni nadie podía retirar ese remanente, pausarlo ni parchearlo.

Esa combinación —desatención + saldo + inmutabilidad— es exactamente lo que convierte a un protocolo deprecado en un objetivo que mejora con el tiempo. Cuanto más pasa, menos ojos lo miran y más se olvida que el dinero sigue ahí.

¿Cómo funcionó el exploit del boundary gap?

Imagina un control de seguridad de aeropuerto con 32 puertas en fila, pero un solo guardia que solo está físicamente en la última. La regla del aeropuerto dice que «todos los pasajeros que pasen por estas puertas quedan registrados como verificados». El sistema de registro, efectivamente, anota a los 32 como verificados. Pero el guardia, en la práctica, solo revisa a quien cruza su puerta. Las otras 31 puertas quedan registradas como controladas sin que nadie las controle de verdad.

Eso es, en esencia, lo que ocurrió. En un sistema de ZK-rollup (una tecnología que agrupa muchas transacciones, genera una prueba criptográfica de que todas son válidas y la asienta en Ethereum), hay dos piezas que tienen que cuadrar:

• La prueba criptográfica dice cuántas operaciones se comprometen al nuevo estado. En el contrato, ese número se relaciona con los slots de datos —32 en total en cada lote—.
• El contrato de liquidación en Ethereum (la capa L1, donde el dinero cambia de manos de verdad) recorre esas operaciones para mover los fondos y debería verificar cada una.

El fallo, según SlowMist y BlockSec, fue una discrepancia entre ambos rangos: lo que la prueba comprometía como estado válido (el registro que dice «32 verificados») y lo que el bucle de liquidación de la L1 verificaba de verdad (el guardia que solo mira una puerta). El término técnico es boundary gap: un hueco en la frontera entre la verificación off-chain de la prueba y la verificación on-chain del asentamiento.

En la práctica, el atacante consiguió que 31 de los 32 slots quedaran comprometidos al estado L2 por la prueba sin pasar por ninguna verificación de liquidación en el contrato L1. Metió instrucciones de retirada por esas 31 puertas «registradas pero no controladas» y el contrato soltó los fondos creyendo que todo estaba validado. Y como el contrato era inmutable, no había forma de cerrar la puerta una vez descubierta.

Lo importante de este tipo de fallo es que no es un error grosero de programación, del estilo de un require olvidado o una función pública que debería ser privada. Es un fallo de diseño de la frontera: dos componentes que individualmente funcionan bien —la generación de la prueba y el bucle de liquidación— pero cuyos supuestos sobre «qué cuenta como verificado» no coinciden exactamente. Estos huecos en los límites son notoriamente difíciles de detectar en auditoría porque cada pieza parece correcta por separado; el agujero solo aparece cuando se las mira juntas y bajo una transacción construida a propósito. Por eso SlowMist insiste en auditar la consistencia lógica del borde L1/L2 y la verificación secundaria on-chain de los public inputs como categoría de riesgo propia, no como un detalle más del código.

¿Por qué renunciar a las admin keys puede ser un error?

Esta es la tesis incómoda del artículo. La intuición dominante en cripto es que renunciar a las admin keys equivale a la máxima seguridad: «nadie puede tocar el contrato, ni siquiera el equipo, así que nadie puede robar ni censurar». Para un protocolo de privacidad, además, tiene un atractivo ideológico fuerte: la ausencia de un administrador es la prueba de que no hay puerta trasera.

El problema es que la inmutabilidad es una espada de doble filo. Inmutable también significa imparcheable. Renunciar a las llaves elimina el riesgo de que un administrador malicioso (o comprometido) robe los fondos, pero a cambio elimina también la única herramienta para reaccionar cuando aparece un bug. Y el código sin bugs no existe; existe el código con bugs que aún no se han encontrado.

Mientras un protocolo está vivo, esa apuesta puede tener sentido: hay un equipo vigilando, una comunidad, auditorías, bug bounties. Pero un protocolo deprecado pierde todo eso y conserva lo peor: el saldo y la imposibilidad de actuar. Renunciar a las llaves sin haber vaciado primero los fondos no es entregar las llaves de una caja fuerte vacía; es soldar la puerta de una caja fuerte llena y tirar el soplete. El día que alguien encuentra cómo abrirla por un lado, no hay nadie con autoridad —ni capacidad técnica— para defenderla.

El caso espejo lo demuestra desde el otro extremo. A finales de mayo de 2026, los lockers legacy de DxSale (plataforma de lanzamiento de tokens y bloqueo de liquidez en BNB Chain) perdieron unos 7,3 millones de dólares, pero por el motivo opuesto: las admin keys no se habían renunciado, se transfirieron de forma silenciosa meses antes y se abusó de ellas para vaciar más de 1.400 pools. Aztec renunció a las llaves y se las robaron por un bug; DxSale conservó las llaves y se las robaron por las llaves. El factor común no son las llaves: es el dinero que se quedó dentro de un sistema que ya nadie cuidaba. El vector cambia; la causa raíz es la misma.

¿Cómo se compara con otros casos de «código muerto»?

Aztec Connect no es el primer protocolo legacy que sangra años después de morir. La tabla resume tres episodios recientes de 2026 donde el denominador común es capital vivo en infraestructura desatendida, con vectores distintos.

La lectura cruzada es la que da el titular: tanto renunciar a las llaves (Aztec) como conservarlas mal custodiadas (DxSale) terminan en lo mismo cuando hay saldo en un sistema que nadie opera. La gobernanza de las llaves es secundaria; el error primario es no haber retirado los fondos al cerrar. Un contrato deprecado y vacío no aparece en ninguna lista de objetivos.

Hay además un sesgo temporal que agrava el caso de los contratos inmutables frente al de los de administrador comprometido. Un contrato con administrador vivo recibe parches, rotaciones de claves y vigilancia mientras alguien lo opere; su superficie de ataque puede reducirse con el tiempo. Un contrato inmutable y deprecado hace lo contrario: su superficie de ataque solo crece, porque el código se congela el día del cierre mientras las técnicas de análisis y las herramientas de los atacantes siguen mejorando año tras año. El contrato de Aztec Connect era, en 2026, exactamente igual de seguro que cuando se congeló en marzo de 2024 —pero el mundo que lo rodeaba era mucho mejor encontrando fallos—. El tiempo juega en contra del código que no puede cambiar.

¿Cómo debería deprecarse un protocolo de forma responsable?

El sector trata el «deprecar y olvidar» como una operación neutra: se anuncia el cierre, se abre una ventana de retirada y se da por terminado. Pero mientras quede saldo, el protocolo sigue siendo un pasivo de seguridad. Un cierre responsable —un sunset bien hecho— debería tratar el remanente como el problema central, no como un detalle.

• Retirada forzada del remanente: conservar la capacidad técnica de barrer los fondos no reclamados (a un contrato de custodia, a un multisig de la fundación —un contrato que exige varias firmas para mover fondos, sin punto único de fallo— o a un mecanismo de reclamación posterior) antes de soldar la puerta. Un contrato vacío es inmune por definición.
• Renuncia a las llaves después, no antes: la inmutabilidad como último paso, una vez el TVL está en cero o en un mínimo aceptado, no como gesto simbólico el día del anuncio.
• Botón de pausa conservado durante la transición: mantener un botón de pausa (pause button: una función que congela el contrato sin permitir mover fondos) con time-lock (un retardo público antes de que cualquier acción surta efecto) mientras dure la ventana, para poder congelar el contrato si aparece un fallo sin poder mover fondos arbitrariamente.
• Auditoría del estado de cierre: auditar específicamente el camino de retirada de emergencia y los bordes L1/L2, que es justo donde fallaron ambos contratos de Aztec.
• Monitorización post-mortem: si por diseño no se puede actuar, al menos vigilar el contrato muerto y avisar públicamente del saldo residual, para que el riesgo sea explícito y no una mina enterrada.

SlowMist, en su propio análisis, recomienda exactamente esto para contratos deprecados que aún custodian activos: migración ordenada o destrucción de los fondos para eliminar la exposición continua. La lección no es «no renuncies a las llaves»; es «no dejes dinero detrás de una puerta que decides no poder volver a abrir».

¿Qué quedan como lecciones para el lector?

Para quien usa DeFi, el episodio deja una pauta concreta: cuando un protocolo anuncia que cierra, la ventana de retirada es el único momento en que el sistema todavía tiene quien lo cuide, y un saldo olvidado en un contrato deprecado no está «guardado», sino expuesto y sin nadie capaz de defenderlo. La intuición a corregir es equiparar «inmutable» con «seguro»: la inmutabilidad protege contra el administrador malicioso pero te deja indefenso ante el bug sin parche, y en un protocolo muerto —sin vigilancia y con dinero dentro— se da la peor combinación posible. Por eso la recomendación que SlowMist extrae del caso no es «no renuncies a las llaves», sino migrar o destruir los activos de los contratos legacy que aún custodian fondos antes de soldar la puerta: «protocolo muerto, dinero vivo» sigue siendo una de las superficies de ataque peor gestionadas de DeFi precisamente porque se disfraza de buena práctica.

Fuentes y enlaces: SlowMist — análisis técnico del exploit · NewsBTC — riesgo de cola larga de los contratos deprecados · Cryptopolitan · CoinJournal — segundo incidente · Crypto Briefing · Rekt News — DxSale