Exploit del puente Verus Ethereum: el mismo error de $11.58M
El 18 de mayo de 2026, alguien vació el puente Verus-Ethereum por 11,58 millones de dólares. Según el reportaje de CoinDesk, fue el octavo hackeo a un puente del año. El exploit del puente Verus Ethereum no involucró ninguna clase de ataque exótico o novedoso. Fue el mismo fallo que hemos visto acabar con puentes desde 2021: el contrato liberó fondos en una cadena sin verificar correctamente lo que realmente ocurrió en la otra.
La función vulnerable tenía nombre esta vez. checkCCEValues. Esa es la rutina que debía confirmar que los valores de exportación entre cadenas coincidían con la realidad antes de acuñar o liberar en el lado de Ethereum. No cumplió su función, y el atacante se fue con el dinero.
Llevo cuatro años construyendo infraestructura adyacente a puentes en un contexto regulado, y lo deprimente es lo predecible que se ha vuelto esto. Seguimos cambiando el nombre a la misma herida.
El exploit del puente Verus Ethereum fue un fallo de validación de origen
Quitemos el branding y todo puente hace una sola cosa. Observa un evento en la cadena A (un depósito, un bloqueo, una exportación) y produce una acción correspondiente en la cadena B (una acuñación, un desbloqueo, una liberación). Todo el modelo de seguridad se reduce a una sola pregunta: ¿realmente cree la cadena B lo que le dijo la cadena A, y lo verificó?
Cuando la validación que confirma los montos del lado de origen es incorrecta, la respuesta es "no". El atacante falsifica o infla el valor de exportación reclamado, el contrato de destino le da crédito, y se acuñan o liberan tokens que nunca tuvieron respaldo. The Block informó que la pérdida ascendió a aproximadamente 11,58 millones de dólares, drenados exactamente a través de este tipo de brecha contable en la verificación de exportación entre cadenas.
Esto es la validación del monto de origen en un puente, y es la función más crítica de todo el sistema. Fallar en un solo comparador y el puente se convierte en una impresora de dinero gratis.
checkCCEValues es solo el nombre más reciente de una vulnerabilidad antigua
La vulnerabilidad checkCCEValues es estructuralmente idéntica a bugs que ya le han costado a la industria miles de millones. Los nombres rotan. El mecanismo no.
- Wormhole, 2022: una brecha en la verificación de firmas permitió a un atacante acuñar 120.000 ETH envueltos que nunca fueron depositados.
- Nomad, 2022: una inicialización fallida de la raíz de merkle significó que cualquier mensaje se validaba como verdadero, y el puente fue explotado en masa por una multitud que copiaba las transacciones.
- Multichain, 2023: claves y supuestos de confianza que nadie podía verificar desde fuera.
Cada uno de esos fue, en esencia, la cadena de destino liberando valor sin una prueba sólida del evento de origen. checkCCEValues es la ortografía de 2026 de la misma palabra.
Creo que la industria sigue tratando estos como errores de ingeniería individuales cuando son un fallo de categoría. No se arregla una categoría auditando más a fondo una sola función.
Tornado Cash financió al atacante, lo que revela la intención
La billetera del atacante fue financiada a través de Tornado Cash antes del exploit. Ese detalle importa menos por atribución que por lo que dice sobre la preparación. No fue un investigador de seguridad explorando un contrato que se sorprendió con el resultado. El patrón del atacante financiado por Tornado Cash es la firma de alguien que montó una cobertura operativa días antes y esperaba que los fondos necesitaran lavarse a la salida.
Esa es la parte que los defensores subestiman. Para cuando la transacción del exploit aterriza, la vía de escape ya está construida. El rastreo post hoc ayuda a los fiscales, pero no hace casi nada por el protocolo que acaba de perder ocho cifras.
Los fallos de seguridad en puentes son ahora un impuesto mensual
Si ampliamos la vista, el hackeo de Verus es una línea más en el balance, no una anomalía. Según datos de PeckShield citados por Bitcoin.com, los exploits a puentes de criptomonedas sumaron aproximadamente 328 millones de dólares solo en mayo de 2026. Ocho incidentes en puentes en menos de cinco meses del año.
El mercado ha asimilado silenciosamente esto como un costo de hacer negocios entre cadenas. Es la lección equivocada. Una pérdida mensual recurrente de nueve cifras no es volatilidad; es un defecto estructural que el espacio de diseño se niega a confrontar.
Para cualquiera que mueva valor real, la conclusión es incómoda: la mayoría de los puentes son suposiciones de confianza disfrazadas de matemáticas. He argumentado antes, en Cómo fallan realmente los puentes de stablecoins, que el puente más seguro suele ser el que admite cuán poco verifica en realidad.
Cómo debería verse una verificación realmente defendible en un puente
Si estás construyendo o auditando un puente, la validación del monto de origen es donde deberías concentrar una parte desproporcionada de tu paranoia. Algunas cosas que trataría como innegociables:
- El contrato de destino debe verificar una prueba criptográfica del evento de origen, no la palabra de un relayer. Pruebas de cliente ligero o zk por encima de atestaciones multisig siempre que el presupuesto de latencia lo permita.
- Las verificaciones de monto deben ser exhaustivas en cada ruta. La clase de bug
checkCCEValuessuele esconderse en una rama que algunas entradas omiten. Aplica fuzzing a la comparación, no la revises a ojo. - Límites de tasa y cortacircuitos por activo, para que un valor falsificado no pueda vaciar toda la reserva en una sola transacción. Un límite que pause automáticamente al, digamos, 5% del TVL por hora habría atenuado la mayoría de los incidentes de 2026.
- Monitoreo independiente de invariantes que observe el total acuñado frente al total bloqueado en tiempo real y se detenga ante cualquier divergencia.
Nada de eso es novedoso. El conjunto de herramientas de auditoría para detectar estos problemas existe, algo que exploré en el artículo sobre el stack de auditoría. El problema es que los puentes siguen despachando la validación como un añadido en lugar de tratarla como el producto.
El próximo hackeo a un puente en 2026 ya está siendo escrito. Tendrá un nombre de función diferente y la misma causa raíz, y volveremos a fingir sorpresa. No deberíamos.