Los hacks de 2026 ya no atacan el contrato, sino el perímetro

En los cuatro mayores robos de DeFi de 2026, el contrato inteligente auditado no falló ni una sola vez. Cayeron la configuración de un puente, los nodos que alimentaban a un verificador, los agentes de IA con permisos de transferencia y la cadena de herramientas del desarrollador. El código que custodia el dinero —ese que se audita, se publica y se peina línea a línea— resistió; lo que cedió fue el perímetro que lo rodea: la infraestructura. Abril de 2026 fue el peor mes de la historia de DeFi con 606 millones de dólares robados, y casi todo ese dinero salió por la puerta de servicio, no por la cerradura blindada de la entrada. Este artículo defiende una tesis: en 2026 el locus del ataque se ha desplazado fuera del contrato. Lo argumentamos con los incidentes públicos del año, explicamos por qué el perímetro es estructuralmente más blando que el código auditado, y cerramos con qué cambia eso para protocolos y para usuarios. No es un manual de cómo atacar nada — es la lectura del patrón y de la defensa.

¿Por qué el contrato inteligente dejó de ser el objetivo?

Durante años, la imagen mental del hack de DeFi fue la del exploit de contrato: un fallo de reentrancy, una manipulación de oráculo, una función de retirada mal protegida. El atacante leía el código público, encontraba el agujero matemático y vaciaba el pool en un bloque. La industria respondió con la maquinaria que hoy define a un protocolo serio: auditorías múltiples, verificación formal, bug bounties de siete cifras (Aave paga hasta 1 millón de dólares en Immunefi por un fallo crítico) y librerías estándar revisadas por miles de ojos. El contrato se convirtió en la parte más cara de atacar de todo el sistema.

Y precisamente por eso dejó de ser el objetivo rentable. La lógica es la de cualquier atacante racional: no se entra por la puerta blindada cuando la ventana del baño está abierta. Un contrato auditado es código casi inmutable, público, escrutado por defensores que llevan años cerrando esa clase concreta de fallos. El perímetro que lo rodea —el editor del desarrollador, el pipeline que despliega, los nodos RPC (los servidores que sirven el estado de la cadena a las aplicaciones) que alimentan a un puente, los agentes de IA con permisos para mover fondos— no tiene ni una décima parte de ese escrutinio. Cambia a diario, lo mantienen personas con prisa y casi nadie lo audita con el rigor que se aplica a una función de Solidity.

El dato lo confirma. Según TRM Labs, el 76 % de todo el valor robado en cripto en 2026 lo concentró el Grupo Lazarus de Corea del Norte en solo dos operaciones. Ninguna de las dos fue un exploit de lógica de contrato: una atacó la configuración de un puente, la otra fue meses de ingeniería social contra operadores humanos. El dinero grande de 2026 no entró por el código. Entró por todo lo demás.

¿Cuáles son los cuatro vectores de perímetro de 2026?

La tesis no se sostiene con un caso aislado, sino con el patrón. Cuatro incidentes públicos de 2026, cada uno atacando una capa distinta del perímetro, dibujan el mismo desplazamiento. En ninguno falló la lógica del contrato; en los cuatro falló la infraestructura que lo envuelve.

Conviene leer la tabla como un mapa, no como una lista de sucesos. Cada fila es una capa de la pila que un protocolo necesita para funcionar pero que no aparece en su informe de auditoría. El contrato es la única pieza que esos informes cubren — y es la única que aguantó en los cuatro casos.

¿Cómo cayó Kelp DAO sin tocar un contrato?

El 18 de abril de 2026, Kelp DAO perdió 292 millones de dólares a través de su puente sobre LayerZero. No hubo bug en Solidity. El puente operaba con una configuración DVN (la red de verificadores que aprueba los mensajes entre cadenas) en modo «1 de 1»: un único verificador validaba los mensajes cross-chain, sin redundancia. El atacante envenenó los nodos RPC que ese verificador consultaba para leer el estado de la cadena de origen y, en paralelo, lanzó un DDoS (saturación de tráfico) contra esa infraestructura. Con el verificador leyendo un estado manipulado, fabricó un mensaje falso que ordenó al puente liberar 116.500 rsETH en Ethereum sin que existiera el burn correspondiente en origen.

Lo demoledor del caso es que la advertencia existía. LayerZero había señalado el riesgo de la configuración 1-de-1 antes del hack; cerca del 47 % de las aplicaciones sobre LayerZero usaban ese mismo default. Kelp custodiaba miles de millones y nunca endureció más allá de la configuración por defecto. El contrato del puente hacía exactamente lo que estaba programado para hacer — el problema era la infraestructura que decidía qué mensajes eran legítimos. La onda expansiva alcanzó a más de veinte protocolos conectados y disparó más de 10.000 millones de dólares en salidas de Aave, aunque los contratos de Aave tampoco fueron explotados: simplemente quedaron con colateral en disputa. Lo analizamos en detalle en cómo robaron 292 millones de Kelp DAO sin tocar un contrato.

¿Por qué un agente de IA con permisos es una bomba?

Step Finance, un gestor de portfolios de DeFi sobre Solana, fue drenado en enero de 2026 y acabó cerrando el 24 de febrero. La cifra ronda los 27 millones de dólares (261.854 SOL en una sola transacción; algunos reportes la elevan hacia los 40 millones contando el colapso del 97 % de su token). El vector inicial fue humano y clásico: comprometer los dispositivos de los ejecutivos del proyecto para hacerse con sus claves. Pero el amplificador fue nuevo.

Step Finance había integrado agentes de IA con permiso para ejecutar transferencias grandes de SOL sin aprobación humana. Una vez dentro, los atacantes no tuvieron que mover el dinero a mano: usaron los propios agentes del protocolo —con sus permisos excesivos y sin aislamiento— como palanca para sacar los fondos. El fallo no fue el contrato ni el modelo de IA en sí, sino la automatización con permisos: una identidad de máquina capaz de mover valor sin un humano en el bucle convierte un compromiso de credenciales en un drenaje instantáneo. Es el mismo principio que en seguridad tradicional hace peligroso un servicio con privilegios de administrador que nadie revisa.

El caso vecino es Resolv USR (25 millones de dólares): una inyección de prompts en un agente de IA con acceso a la nube, atacando la capa de herramientas —MCP, Supabase, claves gestionadas en AWS KMS— en lugar del contrato. Dos incidentes, dos puntos distintos de la misma capa nueva: la infraestructura de IA que los protocolos están conectando a sus operaciones más rápido de lo que la aseguran. El detalle de la inyección de prompts está en 25 millones robados mediante inyección de prompts en MCP.

¿Cómo entra el atacante por la cadena de herramientas del dev?

El cuarto vector es el más insidioso porque actúa antes de que el contrato exista siquiera. El 18 de mayo de 2026, el grupo TeamPCP (rastreado como UNC6780) publicó una versión envenenada de Nx Console, la extensión oficial de VS Code para el monorepo Nx, con 2,2 millones de instalaciones. Estuvo disponible en el Marketplace oficial menos de 20 minutos — suficiente para que la actualización automática la empujara a un número desconocido de máquinas. El payload, bautizado Mini Shai-Hulud, robaba tokens de CI/CD, se autopropagaba como gusano de npm y barría rutas de wallets en disco. GitHub confirmó la exfiltración de unos 3.800 de sus repositorios internos.

La innovación que asusta no fue romper una defensa, sino cooptarla: el gusano generaba atestaciones de procedencia SLSA Build Level 3 auténticas para los paquetes maliciosos. Es decir, la firma criptográfica que la industria construyó tras SolarWinds para certificar que un paquete venía de un pipeline confiable estaba correcta — solo que el pipeline ya estaba secuestrado. Para un desarrollador Web3 esto es crítico: en su máquina conviven la clave que firma un despliegue de contrato y la seed de una wallet de tesorería. No hay departamento de fraude que revierta la transacción: si la extensión filtra esa clave y el atacante firma, los fondos se han ido. Lo revelador del incidente es lo que sí contuvo el daño — según GitHub, los repositorios de clientes no se vieron afectados porque el acceso comprometido estaba segregado. La disciplina de permisos, no el contrato, fue la última línea de defensa.

¿Por qué el perímetro es más blando que el contrato?

La pregunta clave no es por qué los atacantes se han movido al perímetro, sino por qué el perímetro lo permite. La respuesta está en una asimetría estructural entre dos clases de superficie.

El contrato inteligente tiene cuatro propiedades que lo endurecen: es público (cualquiera puede auditarlo), es casi inmutable (no cambia tras desplegarse), tiene un perímetro acotado (el conjunto de funciones es finito y conocido) y concentra toda la atención defensiva del sector. La infraestructura que lo rodea es exactamente lo contrario en las cuatro:

• Cambia a diario. Un contrato se audita una vez y queda fijo. La toolchain del desarrollador, los nodos RPC, las dependencias de npm y la configuración de los agentes mutan constantemente. Cada actualización es una ventana nueva, y nadie reaudita el sistema entero en cada cambio.
• Es opaca y dispersa. El código del contrato está en un explorador de bloques para que lo vea el mundo. La configuración del DVN de un puente, los permisos de un agente de IA o los tokens que viven en un pipeline de CI/CD no se publican ni se escrutan. El default vulnerable de Kelp llevaba meses ahí, advertido, sin que nadie lo cambiara.
• Hereda confianza de terceros. El protocolo no controla el VS Code Marketplace, ni el registro de npm, ni los nodos RPC de un proveedor, ni el pipeline de la nube. Confía en ellos. TeamPCP no atacó el contrato: atacó el eslabón de confianza —una extensión firmada— que el desarrollador da por bueno.
• Casi nadie la audita con el mismo rigor. Hay bug bounties de un millón de dólares por un fallo de contrato y verificación formal de cada función. No existe el equivalente para «¿está bien configurado tu puente?» o «¿qué puede mover tu agente de IA sin un humano delante?». El presupuesto de seguridad se gastó en la parte que ya estaba dura.

La consecuencia es directa: el coste marginal de encontrar un fallo en el perímetro es mucho menor que el de romper un contrato auditado, y el premio es idéntico —los mismos fondos—. Un atacante racional, y Lazarus lo es, va donde la relación esfuerzo-recompensa es mejor. En 2026, eso es la infraestructura.

¿Significa esto que los exploits de contrato desaparecieron?

No, y el matiz importa para no caer en el titular fácil. Los fallos de lógica de contrato —reentrancy, manipulación de oráculos, errores de redondeo— siguen ocurriendo y seguirán ocurriendo, sobre todo en protocolos jóvenes, sin auditar o con código copiado a medias. La anatomía de esos fallos no ha cambiado y conviene conocerla; la repasamos en la anatomía de una vulnerabilidad cripto.

Lo que afirma la tesis es algo más preciso: el dinero grande de 2026 se ha desplazado al perímetro. De los 606 millones robados en abril —3,7 veces el total del primer trimestre completo—, dos ataques de Lazarus concentraron cerca del 95 %, y ninguno fue un exploit de contrato. Cuando el código se ha endurecido tanto que vaciar un protocolo serio por la vía matemática es carísimo, los grandes operadores migran a la vía barata. Los exploits de contrato no han muerto; han quedado relegados a las presas fáciles, mientras las presas gordas caen por el perímetro. Es una redistribución del riesgo, no una sustitución.

¿Qué cambia para los protocolos?

Si el ataque ya no entra por el contrato, auditar solo el contrato es defender una puerta blindada con la ventana abierta. La defensa se desplaza con el ataque. Para un protocolo, eso implica tratar el perímetro con el mismo rigor que el código:

1. Auditar la configuración, no solo el código. El default de un puente, el modo del DVN, los proveedores de RPC y su redundancia son parte de la superficie de ataque. Kelp tenía el contrato bien y el puente en «1 de 1»: la auditoría que importaba era la de la configuración, y no se hizo.
2. Permisos mínimos en los agentes de IA. Ninguna identidad de máquina debería poder mover valor sin un humano en el bucle o sin límites estrictos. Un agente con permiso de transferencia ilimitada es, en la práctica, una clave privada con voluntad propia. La lección de Step Finance es exactamente esa.
3. Segregar credenciales por radio de explosión. El token que construye no debe ser el que publica; la clave que prueba no debe ser la que despliega en producción. En el caso TeamPCP, los repositorios de clientes de GitHub se salvaron precisamente porque el acceso comprometido no los alcanzaba: la segregación contuvo el daño.
4. Endurecer la toolchain del desarrollador. Actualizaciones manuales y revisadas en máquinas que tocan claves, escepticismo ante la procedencia firmada (ya no basta como garantía), y nunca dejar seeds de producción al alcance de la sesión de un editor.
5. No ignorar las advertencias que ya se tienen. LayerZero avisó a Kelp. El default vulnerable estaba documentado. La defensa del perímetro empieza por actuar sobre el riesgo conocido antes de buscar el desconocido.

La diferencia de fondo con quién ejecuta el ataque la tratamos aparte: si te preguntas si la IA es ya el atacante autónomo que vacía protocolos, la respuesta y los datos están en la alarma de OpenZeppelin sobre la IA «superhumana». Aquel artículo va de quién ataca; este, de qué parte se ataca. Son complementarios: a 1 de junio de 2026, el atacante sigue siendo humano y el blanco se ha movido al perímetro.

¿Qué señales debería mirar un usuario?

El usuario de DeFi no audita puentes ni configura agentes, pero su exposición depende de decisiones de perímetro que sí puede evaluar antes de depositar. Cuatro señales prácticas:

• Riesgo de puente heredado. Cualquier token «wrapped» o bridgeado hereda el riesgo de la infraestructura del puente, no del contrato que lo emite. Si tienes activos cross-chain, conviene saber qué puente los respalda y en qué configuración. Para comparar las arquitecturas de verificación de los grandes puentes antes de mover fondos, el comparador de LayerZero, Wormhole y Axelar ayuda a ver las diferencias de un vistazo.
• Concentración en un solo proveedor. Tener toda la exposición cross-chain bajo un único proveedor de puente es replicar el punto único de fallo que hundió a Kelp. Diversificar reduce el radio de explosión también para el usuario.
• Colateral con respaldo en disputa. Si usas un activo bridgeado como colateral en lending, tu posición depende de que ese respaldo siga siendo válido. Cuando el puente que lo emite sufre un incidente, el Health Factor puede deteriorarse sin que tú hagas nada.
• Madurez del perímetro, no solo de las auditorías. Un sello de auditoría cubre el contrato. Preguntar si el protocolo publica su configuración de puentes, cómo gestiona los permisos de sus automatizaciones y cómo segrega credenciales dice más sobre su riesgo real en 2026 que el número de auditorías del contrato.

La lección transversal es incómoda pero clara: en 2026, leer solo el informe de auditoría del contrato es leer la parte que ya está resuelta. El riesgo vive en el margen no auditado. El contrato se mira una vez y es público; el perímetro cambia cada día y casi nadie lo vigila — y ahí es donde, golpe a golpe, está cayendo el dinero grande. Monitorizar tus posiciones y la salud de tu portfolio sirve precisamente para detectar pronto cuando un incidente de perímetro empieza a contaminar los activos que tocas.

Fuentes y enlaces: TRM Labs (atribución y % robado 2026) · BeInCrypto (606 M$ en abril, 3,7x Q1) · CoinDesk (cierre de Step Finance) · Halborn (análisis Step Finance) · CISA (alerta TeamPCP / Nx Console) · Chainalysis (atribución Lazarus)