El puente funcionaba y nadie lo había tocado. A las 18:45 UTC del 10 de noviembre de 2026, quien escribía across.to en el navegador no encontraba la aplicación de Across, sino una web que pedía firmar aprobaciones para seguir operando. Los contratos seguían desplegados y auditados; el dominio que los anunciaba ya pertenecía a otra persona.
Un dominio es el activo menos vistoso del inventario de cualquier protocolo y el más difícil de sustituir sin consecuencias. Across lo tenía registrado en Namecheap, y ese fue el punto que eligieron los atacantes: una operación de ingeniería social contra el registrador bastó para desviar el tráfico. Un recuento del incidente sitúa el botín en unos 350.000 dólares repartidos entre carteras de seis redes, desde Ethereum hasta Plasma.
La diferencia con un exploit de contrato es de naturaleza, no de grado. Aquí no hubo una línea de código que parchear, sino una cuenta, un proceso de soporte y una firma que el usuario creyó legítima porque la página llevaba el logotipo correcto bajo la dirección correcta. Eso explica que el incidente se cerrara en horas y, a la vez, que vaya a repetirse en otro protocolo antes de que termine el año.
El eslabón que no aparece en la auditoría
El registrador es la empresa que vende el nombre y guarda los servidores que indican a internet dónde vive una web. Cuando esa cuenta cae, el atacante no necesita romper nada más: cambia el destino, conserva el certificado y la marca, y coloca su propia página en el mismo sitio donde el usuario esperaba la legítima. Across atribuyó el incidente a una ingeniería social contra Namecheap, el trámite de convencer a una persona de que quien pide el cambio es el dueño del dominio.
Ese es el punto débil de la cadena. El nombre resuelve a donde diga una cuenta de correo y un panel de control, no a donde diga el código, y el incidente no necesitó ninguna vulnerabilidad.
La recuperación llegó el 11 de noviembre, con ayuda del fundador de Namecheap, Richard Kirkendall. Antes, el equipo había pedido a sus usuarios que no entraran en la aplicación ni firmaran aprobaciones, y había confirmado que el dominio llevaba en manos ajenas desde las 18:45 UTC del día anterior. La puerta que se abrió ahí merece atención: el soporte de un registrador puede devolver un nombre a su dueño en minutos o entregárselo a un impostor con una llamada bien construida.
La escala del objetivo ayuda a entender la elección. El puente movió unos 5.900 millones de dólares en 30 días y figuraba tercero por volumen de transferencia en el ranking de DefiLlama, solo por detrás de Circle y LayerZero.
Quince minutos y una firma de más
Across recibió la alerta en unos quince minutos y arrancó el protocolo de emergencia. El grupo SEAL911, la respuesta a incidentes 24 horas de Security Alliance, marcó el dominio como phishing ante los principales proveedores de cartera, y Cloudflare lo clasificó como riesgo y retiró sus registros DNS. Esa combinación es la que cierra el grifo de verdad: sin resolución de nombres, la web falsa desaparece para casi todo el mundo.
El daño se hizo en ese hueco. La página pedía firmar aprobaciones o permisos en lugar de la operación habitual, y con esa firma el atacante podía mover los tokens cuando quisiera. El estándar EIP-2612 que hizo populares los permisos firmados fuera de la cadena explica el motivo: la víctima autoriza con su clave y el atacante ejecuta después, sin gas y sin una segunda confirmación que levante sospechas.
Junto a esto, el ataque se dio por goteo: primero 9.000 dólares en USDC en un caso, 7.053 USDT0 repartidos en siete transacciones sobre Plasma en otro, y una cartera vacía después de usar el puente varias veces.
Cronología del asalto y lo que quedó intacto
| Momento del 10 de noviembre, hora UTC |
Qué ocurrió |
Quién actuó |
| 18:45 |
Toma de control del dominio mediante ingeniería social |
Atacantes, contra la cuenta de Namecheap |
| 19:00 aproximadamente |
Alerta interna y retirada de la web comprometida |
Equipo de Across |
| A continuación |
Dominio marcado como phishing ante los proveedores de cartera |
SEAL911 |
| Sin hora pública |
Dominio clasificado como riesgo y registros DNS eliminados |
Cloudflare |
| 11 de noviembre |
Dominio recuperado y sistemas restaurados |
Across, con ayuda de Namecheap |
La tabla deja un hueco que ningún comunicado ha rellenado: la hora exacta en la que se retiraron los registros DNS. Sin ese dato no se puede saber cuántos minutos estuvo la web falsa resolviendo para el público, y esa cifra es justamente la que necesitarían los afectados para reconstruir si su firma salió de la página legítima o de la copia.
El resto del inventario quedó fuera del alcance. Los contratos del puente no se tocaron, y Across sostuvo que las integraciones de terceros y los usuarios de su API siguieron operando con normalidad, de modo que el ataque vivió entero en el frontend. El token ACX apenas se movió en la sesión del miércoles, con una caída inferior al 1% que sugiere que el mercado leyó el episodio como un susto operativo.
La cifra que Across no firma
Los 350.000 dólares son una estimación de GoPlus, no una cifra del protocolo. Across no ha publicado ni el número de afectados ni el total drenado; su compromiso público es compensar a todos los usuarios perjudicados y publicar un informe completo en los días siguientes. La promesa es razonable y todavía no es verificable.
Ese silencio tiene una lógica y un coste. Callar evita fijar un número que luego crezca y obligue a corregirlo, pero deja al afectado sin referencia para reclamar y al analista sin base para medir el daño. La cuenta de pérdidas de DeFi que el sector manejaba en mayo hablaba de 1.000 millones robados en cinco meses; el recuento de DefiLlama llega ya a 8.780 millones en 341 incidentes de 2026.
Ninguna de esas dos cifras describe bien lo que pasó en Across. El caso se parece más a un robo de identidad corporativa que a una brecha de infraestructura, y ese matiz es el que conviene retener.
Gobernanza de cuentas, la asignatura pendiente
El vector no se tapa con auditorías, y esa es la parte incómoda para un sector que lleva años vendiendo seguridad de contratos. Un dominio se protege con bloqueo de transferencia, con segundo factor físico en la cuenta del registrador y con alertas ante cualquier cambio de servidores de nombres; son controles administrativos que no aparecen en un informe técnico y que rara vez tienen un dueño con nombre y apellidos.
La defensa que los protocolos despliegan contra el hackeo permanente cubre contratos, puentes y claves; el registrador queda fuera del manual porque no es código. Y mientras la UE discute cómo bloquear webs fraudulentas y congelar fondos, el eslabón que decide qué web ve el usuario sigue colgando de una cuenta de correo y de la persona que atiende el teléfono en el soporte del registrador.
Lo que un usuario puede comprobar
Después de este caso, la rutina sensata para cualquiera que use un puente es aburrida y corta. Antes de firmar, conviene comprobar que la dirección de la web es exactamente la que el protocolo publica en su cuenta oficial, no la que llega por un mensaje o por un resultado patrocinado, y desconfiar de cualquier petición de aprobación ilimitada a un contrato que no se reconoce. Guardar la dirección oficial en marcadores evita depender de un buscador que puede colocar un anuncio por delante del resultado real.
En la cartera, las alertas de firma y la lista de permisos activos existen y casi nadie las revisa. Revocar los permisos que ya no se usan reduce el botín de cualquier phishing futuro.
El dominio como parte del código
Across hizo lo que se espera de un equipo golpeado: cortó, avisó, recuperó y prometió compensar. Lo que no puede cambiar es la naturaleza del fallo, porque el puente nunca estuvo comprometido y el usuario tampoco improvisó: entró en la dirección correcta y firmó lo que le pidieron. Mientras el sector mida su seguridad en auditorías de contratos, el próximo incidente se parecerá más a este que a un exploit.
El informe prometido dirá cuánto se perdió y si la compensación llegó a todos. La pregunta que no va a responder es la que importa al resto de los protocolos: quién tiene las llaves del dominio, qué segundo factor las protege y quién recibe la alerta cuando alguien cambia los servidores de nombres un martes por la tarde.
