Ataque con flash loan

¿Qué es un ataque con flash loan?

Un ataque con flash loan es una explotación de criptomonedas en la que un atacante utiliza un préstamo de gran cuantía sin garantía para manipular o aprovechar vulnerabilidades de uno o varios contratos inteligentes.

El atacante toma prestados los criptoactivos, ejecuta una serie de acciones, extrae valor de un protocolo vulnerable y devuelve el préstamo dentro de una única transacción de blockchain.

La criptomoneda que sobra después de pagar el préstamo, las comisiones, los costes de trading y los costes de transacción se convierte en el beneficio del atacante.

Si el atacante no puede devolver la cantidad exigida antes de que finalice la transacción, esta normalmente revierte.

Esta condición de devolución atómica permite a los atacantes intentar estrategias que requieren mucho capital sin poseer los activos prestados antes de que comience la transacción.

Un ataque con flash loan no es un tipo especial de transacción de blockchain definido exclusivamente para actividades delictivas.

Los flash loans tienen usos legítimos en arbitraje, intercambios de colateral, refinanciación de deuda, liquidaciones y gestión de liquidez.

El ataque se produce cuando se combina capital temporal con una debilidad en los precios, la contabilidad, la gobernanza, el control de acceso u otro componente de un protocolo cripto.

El OWASP Smart Contract Top 10: 2026 clasifica los ataques facilitados por flash loans como un riesgo importante para la seguridad de los contratos inteligentes.

OWASP describe los flash loans como un multiplicador de fuerza capaz de convertir un pequeño error lógico, de precios o aritmético en una pérdida importante.

¿Cómo funciona un ataque con flash loan?

Un ataque con flash loan combina el préstamo, la manipulación, la explotación, la devolución y la extracción de beneficios dentro de una única transacción atómica.

La secuencia exacta varía según el ataque, pero muchos siguen la misma estructura general.

Paso 1: el atacante encuentra una vulnerabilidad

El atacante estudia un protocolo de finanzas descentralizadas y detecta una suposición insegura.

El protocolo puede depender del precio de un único pool con poca liquidez, calcular incorrectamente las participaciones de una bóveda, aceptar saldos temporales de tokens como poder de voto o no validar una llamada de retorno.

La vulnerabilidad puede parecer inofensiva cuando las transacciones implican pequeñas cantidades de criptomonedas.

La liquidez de un flash loan puede hacer que la misma debilidad resulte muy rentable, al permitir al atacante utilizar temporalmente millones de dólares de capital.

Paso 2: el atacante toma prestados criptoactivos

El atacante solicita un flash loan a un contrato inteligente compatible.

El préstamo puede incluir uno o varios activos, según el diseño del prestamista.

El prestamista transfiere la criptomoneda solicitada a un contrato receptor controlado por el atacante.

El contrato receptor obtiene el control temporal de los activos y comienza a ejecutar las instrucciones del ataque.

Paso 3: el atacante manipula el estado del protocolo

El atacante utiliza el capital prestado para modificar un precio, el saldo de liquidez, la ratio de colateral, la oferta de tokens, el valor de las participaciones, el saldo de gobernanza u otro estado que utilice el protocolo objetivo.

Esta manipulación puede implicar varias aplicaciones descentralizadas y numerosas llamadas internas a contratos inteligentes.

El atacante intenta crear un estado en el que el protocolo objetivo calcule un valor incorrecto o permita una acción insegura.

Paso 4: el atacante extrae valor

El atacante interactúa con el protocolo vulnerable mientras el estado está manipulado.

El protocolo puede conceder un préstamo con colateral insuficiente, sobrevalorar un depósito, permitir una retirada injusta, liquidar un colateral solvente, acuñar tokens en exceso o aprobar una acción de gobernanza maliciosa.

El atacante convierte la criptomoneda extraída en activos que pueda utilizar para devolver el flash loan.

Paso 5: el atacante restablece la posición o sale de ella

El atacante puede revertir algunas operaciones anteriores para recuperar el activo necesario para la devolución.

Los precios y las ratios de liquidez pueden volver a niveles próximos a los iniciales una vez finalizada la transacción del ataque.

Aun así, el protocolo objetivo puede quedarse con reservas insuficientes, deuda incobrable, participaciones emitidas incorrectamente o saldos de usuario afectados.

Paso 6: se devuelve el flash loan

El atacante devuelve el principal prestado y la comisión exigida por el flash loan.

Si la devolución se completa, la transacción se acepta y todos los cambios de estado pasan a formar parte del historial de la blockchain.

Si no se completa, la transacción normalmente revierte y el ataque no produce el resultado previsto on-chain.

Por qué los ataques con flash loan pueden utilizar tanto capital

Los atacantes convencionales están limitados por la cantidad de criptomonedas que poseen o pueden pedir prestada mediante préstamos con garantía.

Un flash loan elimina la necesidad de aportar colateral si la deuda se devuelve dentro de la misma transacción.

Por tanto, el atacante puede controlar temporalmente activos cuyo valor supera con creces el saldo de su propia wallet.

El tamaño del préstamo suele estar limitado por la liquidez disponible, las reglas del prestamista, el comportamiento del token y las restricciones de las transacciones de blockchain.

En teoría, una persona con suficientes criptomonedas para pagar el gas puede iniciar una transacción de flash loan mucho mayor mediante un contrato inteligente programado correctamente.

Esta eficiencia de capital hace que los flash loans sean útiles para traders legítimos y peligrosos cuando hay protocolos vulnerables.

Por qué la transacción no revierte después del robo

Una transacción de flash loan solo revierte si no se cumplen las condiciones programadas.

El prestamista normalmente comprueba que recibe el principal y la comisión, no que todos los protocolos implicados hayan recibido un trato justo.

Si el atacante extrae correctamente suficientes activos del protocolo objetivo y devuelve el préstamo, se cumple la condición del flash loan.

Por tanto, la pérdida del protocolo objetivo puede ser permanente aunque el flash loan se haya devuelto correctamente.

La atomicidad protege al prestamista frente al impago habitual del prestatario, pero no protege automáticamente todos los contratos inteligentes a los que se llama durante la transacción.

Los flash loans no suelen ser la vulnerabilidad principal

Un flash loan suele ser una fuente de capital temporal, no el fallo de software subyacente.

La vulnerabilidad real puede ser un oráculo de precios manipulable, un cálculo incorrecto de participaciones, un control de acceso inseguro, una regla de liquidación defectuosa o una suposición económica errónea.

Un atacante que ya poseyera suficientes activos podría explotar la misma vulnerabilidad sin utilizar un flash loan.

El flash loan abarata el ataque, permite escalarlo y reduce su dependencia del capital personal del atacante.

Eliminar los flash loans no corregiría automáticamente el protocolo vulnerable.

Los desarrolladores deben corregir la suposición que permite que el capital temporal o un estado manipulado produzcan un resultado injusto.

Ataque con flash loan frente a flash loan

Un flash loan es una herramienta financiera y técnica que permite tomar prestadas criptomonedas y devolverlas de forma atómica.

Un ataque con flash loan es el uso abusivo de esa herramienta contra la lógica vulnerable de un contrato inteligente.

Los flash loans legítimos pueden ayudar a alinear precios, refinanciar deuda, sustituir colateral, cerrar posiciones o realizar liquidaciones aprobadas por un protocolo.

Un ataque extrae valor mediante un comportamiento no previsto que perjudica a un protocolo o a sus usuarios.

Por tanto, no es correcto llamar ataque a toda transacción de flash loan.

Atomicidad en un ataque con flash loan

La atomicidad significa que todas las operaciones de una transacción de blockchain se ejecutan juntas o fallan juntas.

Un ataque puede incluir préstamos, intercambios de tokens, depósitos de liquidez, cambios de precios, acciones con colateral, retiradas y devoluciones.

Estas operaciones se consideran una sola transacción, aunque se llame a muchos contratos inteligentes.

Si no se cumple la condición final, la blockchain revierte los cambios de estado de la transacción.

Por lo general, el atacante seguirá perdiendo la comisión de red pagada por la ejecución fallida.

La documentación de Ethereum sobre finanzas descentralizadas explica que un flash loan se revierte como si no hubiera ocurrido cuando no se devuelve dentro de la transacción.

ERC-3156 y la seguridad de los flash loans

ERC-3156 es el estándar de interfaz finalizado de Ethereum para flash loans de un solo activo.

El estándar define cómo un prestamista informa de la liquidez disponible, calcula una comisión, transfiere activos, llama a un receptor y obtiene la devolución.

El receptor debe devolver un valor específico que indique que admite la llamada de retorno de flash loan esperada.

El prestamista debe verificar la devolución una vez completadas las operaciones del receptor.

La especificación ERC-3156 también incluye recomendaciones de seguridad sobre la verificación de llamadas de retorno, la confianza en el prestamista, la validación del iniciador y la acuñación flash.

Seguir ERC-3156 puede mejorar la compatibilidad, pero cumplir el estándar no garantiza que el prestamista, el receptor o los protocolos conectados sean seguros.

La lógica de negocio ajena a la interfaz básica del flash loan puede seguir teniendo vulnerabilidades explotables.

Ataques de manipulación de oráculos de precios

La manipulación de oráculos de precios es uno de los patrones más comunes asociados a los ataques con flash loan.

Un oráculo de precios proporciona información que un contrato inteligente utiliza para valorar criptoactivos.

Un protocolo vulnerable puede calcular el precio de un activo a partir del tipo de cambio actual de un único pool de liquidez descentralizado.

Si el pool tiene poca liquidez, una operación de gran tamaño puede modificar significativamente su precio.

Un atacante puede utilizar activos obtenidos mediante un flash loan para ejecutar esa gran operación y distorsionar temporalmente la ratio del pool.

A continuación, el atacante interactúa con un protocolo de préstamos, derivados, bóvedas o colateral que confía en el precio manipulado.

Un precio artificialmente alto puede hacer que el protocolo objetivo sobrevalore el colateral del atacante.

El atacante podría entonces pedir prestadas más criptomonedas de las que realmente vale el colateral.

Un precio artificialmente bajo puede hacer que posiciones solventes parezcan inseguras y provocar liquidaciones injustas.

El atacante también puede comprar activos del protocolo vulnerable por debajo de su valor en el mercado general.

La guía de seguridad de contratos inteligentes de Ethereum advierte expresamente de que un atacante puede utilizar un flash loan para inflar el precio spot antes de interactuar con un contrato de préstamos vulnerable.

Ejemplo de un ataque de manipulación de oráculos

Supongamos que un protocolo de préstamos valora Token A utilizando el precio actual de un pequeño pool de liquidez.

Token A suele cotizar a $10 y el atacante posee 10,000 unidades, con un valor aproximado de $100,000.

El atacante obtiene un flash loan de gran cuantía y lo utiliza para comprar Token A en el pool seleccionado.

La compra de gran tamaño eleva temporalmente el precio del pool de $10 a $50.

El protocolo de préstamos valora entonces incorrectamente las 10,000 unidades de Token A del atacante en $500,000.

El atacante deposita los tokens y pide prestados $350,000 de otro activo.

El atacante revierte parte de la operación original para obtener los fondos necesarios para devolver el flash loan.

Cuando el precio de mercado vuelve a acercarse a $10, el protocolo de préstamos se queda con un colateral de unos $100,000 que respalda una deuda mucho mayor.

Este ejemplo simplificado no contempla comisiones, deslizamiento, límites de colateral ni otros detalles prácticos, pero muestra cómo la manipulación temporal de precios puede generar deuda incobrable permanente.

Cómo se protegen los protocolos contra la manipulación de oráculos

Un protocolo de gran valor no debería depender por completo de un único mercado spot fácil de manipular.

Los desarrolladores pueden combinar información de precios de varias fuentes independientes.

Una mediana o una media diseñada cuidadosamente puede reducir la influencia de un mercado anómalo.

Los precios medios ponderados por tiempo pueden restar eficacia a una manipulación que dure un solo bloque.

Los feeds de precios también deberían incluir comprobaciones de actualidad para no aceptar indefinidamente datos obsoletos.

Las comprobaciones de liquidez pueden impedir que un pool pequeño controle la valoración de un mercado de préstamos de gran tamaño.

Los protocolos pueden limitar los préstamos, la acuñación, las retiradas y las liquidaciones cuando los precios superen límites razonables.

La guía de OWASP 2026 sobre la manipulación de oráculos de precios recomienda utilizar varias fuentes, rechazar desviaciones anómalas, aplicar ventanas de promedio suficientemente amplias y evitar depender de pools con poca liquidez.

Ataques de gobernanza con flash loan

Un ataque de gobernanza con flash loan se produce cuando la titularidad temporal de tokens proporciona suficiente poder de voto para influir en un protocolo descentralizado.

Un sistema de gobernanza vulnerable puede calcular el poder de voto a partir del saldo actual de tokens de un usuario.

Un atacante puede tomar prestada una gran cantidad de tokens de gobernanza y utilizarlos para crear, aprobar o ejecutar una propuesta.

La propuesta maliciosa puede transferir fondos de la tesorería, modificar permisos de contratos, sustituir una implementación o debilitar la configuración de seguridad.

El atacante devuelve los tokens de gobernanza antes de que finalice la transacción.

El atacante puede haber controlado el protocolo sin mantener una posición económica a largo plazo en su token de gobernanza.

Cómo reducen los sistemas de gobernanza el riesgo de los flash loans

Las instantáneas de saldos históricos permiten calcular el poder de voto a partir de la titularidad de tokens en un bloque anterior, en lugar de utilizar el saldo de la transacción actual.

Un atacante no puede utilizar tokens tomados prestados después de la instantánea para aumentar el poder de voto de esa propuesta.

Un periodo de espera para votar separa la creación de la propuesta del inicio de la votación.

Un timelock añade otro retraso entre la aprobación de la propuesta y su ejecución.

Estos retrasos dan tiempo a los participantes para detectar y responder a una acción de gobernanza maliciosa.

Los umbrales para presentar propuestas, los periodos de votación, los requisitos de cuórum, los guardianes de emergencia y la limitación de los poderes administrativos pueden aportar protección adicional.

La documentación actual de gobernanza de OpenZeppelin describe los puntos de control históricos de votación, los ciclos de vida de las propuestas y la ejecución mediante timelock.

Ningún diseño de gobernanza es seguro solo por utilizar un timelock, ya que los atacantes pueden dirigirse al administrador del timelock o a otro rol privilegiado.

Ataques de manipulación de participaciones de bóvedas

Las bóvedas tokenizadas suelen emitir participaciones que representan un derecho sobre criptoactivos agrupados.

El número de participaciones emitidas por un depósito puede depender de la relación entre los activos totales y el número total de participaciones.

Un ataque con flash loan puede aprovechar cálculos inseguros relacionados con esta ratio.

Un atacante puede manipular el saldo de la bóveda antes de depositar o retirar activos.

El ataque puede hacer que la bóveda emita demasiadas participaciones, muy pocas o una cantidad excesiva de activos subyacentes.

Las condiciones del primer depositante pueden resultar especialmente peligrosas cuando la oferta total es cero o muy pequeña.

Un redondeo que parece insignificante en depósitos normales puede generar grandes beneficios si se repite utilizando capital obtenido mediante flash loans.

La guía de OWASP 2026 sobre errores aritméticos advierte de que las debilidades de redondeo y precisión pueden amplificarse mediante flash loans y operaciones repetidas de gran valor.

Ataques de donación

Un ataque de donación se produce cuando un atacante transfiere tokens directamente a una bóveda o a un contrato de préstamos para alterar su saldo aparente de activos.

La transferencia puede eludir la función de depósito habitual del protocolo y, por tanto, no generar participaciones correspondientes.

Si el protocolo calcula el valor de las participaciones directamente a partir del saldo de su wallet, los activos donados pueden aumentar el valor aparente de las participaciones existentes.

Un atacante puede utilizar un flash loan para realizar una donación temporal de una cuantía muy elevada.

A continuación, el atacante utiliza el valor manipulado de las participaciones para pedir préstamos, canjearlas, liquidar o acuñar activos de forma injusta.

Los protocolos seguros deben distinguir entre los depósitos contabilizados previstos y las transferencias de tokens no solicitadas.

La contabilidad interna y los mecanismos de participaciones virtuales pueden reducir la dependencia del saldo bruto de tokens que mantiene el contrato.

Ataques de redondeo y precisión

Los contratos inteligentes representan los números como enteros con una precisión fija.

La división puede descartar fracciones pequeñas porque muchas operaciones de blockchain no permiten almacenar un número ilimitado de decimales.

Un protocolo puede redondear sistemáticamente en una dirección que beneficie al usuario en lugar de al protocolo.

En condiciones normales, el beneficio de una sola operación puede ser minúsculo.

Un atacante puede utilizar liquidez de un flash loan para ejecutar la operación con una cantidad elevada o repetirla muchas veces dentro de una transacción.

El beneficio combinado puede superar la comisión del préstamo y los costes de transacción.

Los desarrolladores deberían probar los cálculos cerca de cero, cerca de los valores máximos, en el primer depósito y cuando las ratios entre activos y participaciones sean extremas.

La dirección del redondeo debe elegirse según qué parte haya que proteger en cada operación.

Ataques con flash loan facilitados por reentrancia

La reentrancia se produce cuando un contrato externo vuelve a llamar a un protocolo antes de que la función original haya terminado de actualizar su estado.

Los receptores de flash loans utilizan llamadas de retorno de forma natural, por lo que crean varios límites de llamadas externas.

Un atacante puede combinar capital temporal con reentrancia para retirar fondos más de una vez, eludir las comprobaciones de colateral o utilizar un saldo desactualizado.

La reentrancia puede producirse mediante llamadas directas, hooks de tokens, llamadas de retorno de bóvedas, funciones fallback u otro contrato conectado.

Los desarrolladores deberían actualizar el estado interno crítico antes de transferir el control a una dirección externa.

La guía oficial de seguridad de Solidity recomienda el patrón checks-effects-interactions para reducir el riesgo de reentrancia.

Este patrón comprueba primero los requisitos, actualiza después el estado interno y solo entonces llama a contratos externos.

Las utilidades de OpenZeppelin Contracts también ofrecen protecciones contra la reentrancia y mecanismos de pausa para diseños compatibles de contratos inteligentes.

Una protección contra la reentrancia no corrige una lógica económica o unos cálculos de precios inseguros.

Reentrancia de solo lectura

La reentrancia de solo lectura se produce cuando otro protocolo lee un estado incoherente mientras una función está a medio ejecutar.

Puede que la función vulnerable no permita directamente una segunda retirada o un segundo depósito.

Sin embargo, una consulta externa de precios o saldos puede observar valores que aún no se han actualizado de forma coherente.

Un atacante con flash loan puede utilizar este estado temporal para influir en otro protocolo que confíe en el resultado de la consulta.

Los desarrolladores deben tener en cuenta cómo observan el estado los contratos conectados durante las llamadas de retorno, no solo si el contrato original pierde fondos por reentrada directa.

Ataques de colateral y liquidación

Los protocolos de préstamos cripto utilizan ratios de colateral para determinar cuánto puede pedir prestado un usuario y cuándo se puede liquidar una posición.

Un atacante con flash loan puede manipular el precio del colateral o de la deuda antes de que se calcule la ratio.

El atacante puede hacer que un colateral débil parezca más valioso y obtener un préstamo con colateral insuficiente.

También puede hacer que un colateral solvente parezca menos valioso y liquidar injustamente a otro usuario.

Algunos ataques manipulan la bonificación de liquidación, el cálculo de la devolución o la transferencia del colateral en vez del propio precio.

Los sistemas de colateral deberían utilizar precios robustos, límites de préstamo, requisitos mínimos de liquidez y fórmulas de liquidación probadas cuidadosamente.

Manipulación de pools de liquidez

Los pools automatizados de liquidez determinan los precios de las criptomonedas a partir de las cantidades de activos almacenadas en sus contratos inteligentes.

Una operación de gran tamaño modifica esas cantidades y, por tanto, el precio cotizado.

Este movimiento del precio es un comportamiento previsto, no un error de software.

La vulnerabilidad aparece cuando otro protocolo supone que el precio spot temporal del pool representa un valor de mercado general fiable.

Un flash loan proporciona al atacante capital suficiente para mover incluso un pool de tamaño razonable durante una transacción.

Los protocolos deberían analizar el coste necesario para manipular cada mercado que utilicen sus sistemas de precios.

Ataques con flash loan entre protocolos

Los protocolos de finanzas descentralizadas dependen con frecuencia de otros contratos para obtener precios, colateral, liquidez, conversiones de tokens y liquidaciones.

Un ataque con flash loan puede pasar por varios protocolos antes de volver al prestamista original.

Cada contrato individual puede parecer que funciona según sus reglas locales.

Aun así, la secuencia combinada puede incumplir una suposición económica del sistema en su conjunto.

Esta composabilidad dificulta la detección de ataques mediante pruebas unitarias aisladas.

Los desarrolladores deberían probar rutas de transacción completas en todas las dependencias externas utilizadas por el protocolo.

La guía de OWASP 2026 sobre vulnerabilidades de lógica de negocio explica que el código de un contrato inteligente puede ejecutarse exactamente como se ha escrito y, aun así, permitir resultados económicos inseguros.

Ataques al control de acceso

Un flash loan puede amplificar el daño causado por un control de acceso débil.

Un atacante puede obtener acceso temporal a un rol al cumplir una condición basada en el saldo de tokens.

El protocolo también puede exponer una función administrativa sin verificar correctamente quién la llama.

El capital temporal puede utilizarse entonces para acuñar, pedir prestada, retirar o redirigir una cantidad mucho mayor de criptomonedas.

Las comprobaciones de roles deben ser explícitas y no deberían depender únicamente de un saldo que pueda obtenerse dentro de una sola transacción.

Los roles de actualización, pausa, tesorería, acuñación, oráculos y gobernanza deberían revisarse como un único sistema de permisos interconectado.

Ataques de compatibilidad de tokens

No todos los tokens cripto siguen un comportamiento sencillo de transferencia y saldo.

Algunos tokens descuentan comisiones de transferencia, reajustan saldos, activan llamadas de retorno, bloquean direcciones o devuelven valores inusuales.

Un prestamista de flash loans o un protocolo objetivo puede calcular incorrectamente la devolución o el colateral al interactuar con uno de esos tokens.

Un atacante puede elegir un token cuyo comportamiento contradiga una suposición del contrato vulnerable.

Los activos admitidos deberían probarse individualmente; no basta con aceptarlos porque incluyan funciones de token conocidas.

Ataques de acuñación flash

La acuñación flash crea tokens temporalmente en lugar de prestar tokens que ya se encuentran en un pool de liquidez.

Los tokens recién creados deben quemarse o liquidarse antes de que finalice la transacción.

Un protocolo puede fallar si considera que la oferta acuñada temporalmente representa una titularidad económica permanente.

Un atacante podría utilizar el saldo temporal para votar, calcular colateral, cumplir los requisitos para recibir recompensas u otras funciones basadas en saldos.

Los protocolos conectados a tokens que permiten la acuñación flash deben tener en cuenta que puede existir temporalmente una oferta muy elevada dentro de una transacción.

Ataques con flash loan de NFT

Un flash loan de NFT transfiere temporalmente un token no fungible concreto y exige devolver ese mismo token dentro de una transacción.

Una aplicación vulnerable puede conceder beneficios basándose únicamente en la titularidad actual de un NFT.

Un atacante podría tomar prestado temporalmente el NFT para reclamar una recompensa, influir en la gobernanza, desbloquear contenido o cumplir una condición de acceso.

A continuación, devuelve el NFT después de recibir un beneficio previsto para un titular a largo plazo.

Las aplicaciones deberían utilizar el historial de titularidad, registros de reclamaciones, periodos de tenencia u otros controles cuando la titularidad temporal no deba ser suficiente.

Ataques con flash loan y MEV

Maximal Extractable Value (MEV) es el valor que se obtiene controlando la inclusión y el orden de las transacciones dentro de un bloque.

Un ataque con flash loan enviado a través de un pool público de transacciones puede quedar a la vista de buscadores automatizados antes de confirmarse.

Otro participante puede copiar el ataque, ofrecer una comisión más alta o situar transacciones antes o después de él.

Un atacante puede utilizar un sistema privado de envío de transacciones para reducir el riesgo de que lo copien.

Los constructores de bloques y los validadores aún pueden influir en si la transacción se incluye en un bloque y dónde.

La documentación de Ethereum sobre MEV explica cómo la inclusión, exclusión y ordenación de transacciones pueden generar valor adicional.

Cómo calculan los atacantes el beneficio

Un ataque solo tiene éxito económico cuando el valor extraído supera todos los costes.

El cálculo simplificado es:

Beneficio neto del ataque = valor extraído − comisión del flash loan − comisiones de trading − costes de gas − deslizamiento − otras pérdidas

El principal prestado se devuelve al prestamista, por lo que no se conserva como beneficio.

El atacante también puede pagar comisiones para conseguir una inclusión favorable en el bloque o utilizar un sistema privado de envío de transacciones.

Una transacción puede extraer valor del protocolo objetivo y, aun así, generar pérdidas si los costes de ejecución superan lo previsto.

Por qué los ataques con flash loan fallidos siguen teniendo un coste

La atomicidad revierte los cambios de estado, pero normalmente no devuelve el gas de blockchain consumido por la ejecución.

Un ataque fallido puede llamar a muchos contratos inteligentes antes de encontrar la condición que lo hace revertir.

El emisor paga por esta computación según las reglas de comisiones de la blockchain.

Las pruebas, la simulación de transacciones, la infraestructura privada y el desarrollo de contratos inteligentes también generan costes off-chain.

El coste financiero limitado de un intento fallido puede seguir siendo muy inferior al capital temporal que controla la transacción.

Cómo se detectan los ataques con flash loan

Los sistemas de seguridad de blockchain pueden supervisar los flash loans de gran cuantía y las transacciones que los siguen.

Un préstamo de gran cuantía no demuestra por sí solo que haya habido un ataque, ya que las transacciones legítimas de arbitraje y refinanciación pueden utilizar importes similares.

Los sistemas de detección analizan combinaciones de acciones, no un único evento.

Entre las señales de alerta puede haber un préstamo elevado seguido de un cambio extremo de precio, acuñación inusual, endeudamiento rápido, una retirada importante y la devolución dentro de la misma transacción.

Otros indicadores son cambios repentinos en las participaciones de una bóveda, ratios de colateral anómalas, acciones de gobernanza inesperadas o grandes diferencias entre precios internos y externos.

Las trazas de transacciones ayudan a los analistas a reconstruir cada llamada a contrato y transferencia de tokens.

Los eventos, cambios de almacenamiento, saldos de activos y movimientos de precios pueden mostrar cómo salió el valor del protocolo objetivo.

Supervisión en tiempo real y respuesta de emergencia

Los protocolos pueden supervisar retiradas de gran cuantía, endeudamiento inusual, desviaciones extremas de los oráculos y cambios rápidos en la liquidez.

Un mecanismo de pausa puede detener temporalmente las operaciones sensibles mientras los desarrolladores investigan.

Los controles de emergencia deben ser limitados, ya que un exceso de poder administrativo genera sus propios riesgos de seguridad y gobernanza.

Un plan de respuesta debería especificar quién puede pausar el protocolo, cómo se protege esa autoridad y cómo se puede reanudar la actividad normal.

También debería incluir comunicación, rastreo de activos, análisis de contratos y coordinación con los proveedores de infraestructura afectados.

La supervisión no puede prevenir de forma fiable todos los ataques atómicos, ya que toda la explotación puede completarse antes de que una persona pueda responder.

Los controles preventivos en los contratos inteligentes siguen siendo más importantes que la intervención manual.

Cómo pueden prevenir los desarrolladores los ataques con flash loan

Utilizar precios resistentes a la manipulación

Los protocolos deberían combinar fuentes de datos fiables y evitar depender de un único mercado spot con poca liquidez.

Antes de permitir acciones de gran valor, deberían validarse la actualidad, la desviación y la liquidez de los precios, así como la disponibilidad del mercado.

Proteger las invariantes económicas

Una invariante es una condición que debe seguir cumpliéndose antes y después de cada transacción válida.

Un protocolo de préstamos puede exigir que la deuda nunca supere el valor del colateral ajustado al riesgo.

Una bóveda puede exigir que los usuarios no puedan retirar más valor del que les corresponde proporcionalmente.

Las pruebas deberían intentar vulnerar estas condiciones utilizando saldos temporales de cuantía muy elevada.

Limitar la exposición de una sola transacción

Los límites de préstamo, acuñación, retirada, liquidación y canje pueden restringir el valor que puede verse afectado por una sola transacción.

Los límites no corrigen el error subyacente, pero pueden reducir la pérdida máxima posible.

Utilizar saldos históricos de gobernanza

Cuando no deba contar la titularidad temporal de tokens, el poder de voto debería basarse en una instantánea anterior.

Los retrasos en la votación y los timelocks pueden dar tiempo para impugnar propuestas sospechosas.

Aplicar protecciones contra la reentrancia

Las funciones críticas deberían actualizar la contabilidad interna antes de llamar a contratos externos no fiables.

Los bloqueos contra la reentrancia pueden impedir ciertas llamadas repetidas durante una misma ruta de ejecución.

Validar todas las llamadas de retorno

El receptor de un flash loan debería verificar el prestamista, el iniciador, el activo, la cantidad, la comisión y los datos de las instrucciones.

Un atacante no debería poder llamar directamente al receptor y activar un comportamiento privilegiado utilizando activos que ya se encuentren en él.

Redondear de forma prudente

Los protocolos deberían elegir direcciones de redondeo que no generen valor gratuito para los usuarios.

Los cálculos deberían probarse con una oferta igual a cero o mínima, depósitos muy grandes y ratios de activos inusuales.

Separar la contabilidad de los saldos brutos

Un protocolo no debería considerar automáticamente que toda transferencia de tokens a su dirección es un depósito normal.

La contabilidad interna puede impedir que las donaciones directas modifiquen inesperadamente el precio de las participaciones.

Utilizar pausas y disyuntores

Un disyuntor puede rechazar operaciones cuando los precios, saldos o retiradas se sitúen fuera de los rangos definidos.

Una función de pausa puede limitar los daños una vez detectada una actividad anómala.

Probar con capital del tamaño de un flash loan

Las pruebas de seguridad deberían partir de la premisa de que un atacante puede obtener la mayor cantidad de liquidez disponible en los mercados conectados.

Un protocolo que solo es seguro porque los usuarios normales no tienen suficiente capital no está protegido frente a los flash loans.

Pruebas de seguridad frente a ataques con flash loan

Las pruebas unitarias deberían verificar cada función del contrato inteligente en condiciones esperadas e inesperadas.

Las pruebas de integración deberían examinar flujos de trabajo completos que incluyan protocolos externos y fuentes de precios.

Las pruebas de invariantes deberían buscar secuencias de transacciones que infrinjan reglas contables básicas.

Las pruebas fuzz deberían enviar valores, órdenes y operaciones repetidas inusuales.

Las pruebas en una fork pueden ejecutar ataques propuestos contra una copia local del estado reciente de la blockchain.

Las simulaciones económicas pueden modelar cambios en la liquidez, el colateral, los precios de los tokens y el comportamiento de los usuarios.

Las auditorías independientes pueden detectar riesgos que el equipo de desarrollo original no haya identificado.

Una auditoría no garantiza la seguridad de un protocolo después de actualizaciones, cambios del mercado o integraciones con nuevos contratos.

Qué pueden hacer los usuarios de cripto

Los usuarios corrientes no pueden revisar todos los contratos inteligentes con el mismo nivel que un equipo profesional de seguridad.

Aun así, pueden comprobar si un protocolo explica sus fuentes de precios, límites de riesgo, auditorías, controles de emergencia y permisos de actualización.

Los usuarios deberían actuar con cautela si un protocolo ofrece una rentabilidad inusualmente alta sin explicar de dónde procede económicamente.

No deberían concentrar sus fondos en un único contrato inteligente nuevo o sin auditar.

Los usuarios deberían entender si se pueden pausar los depósitos, retrasar las retiradas y atribuir pérdidas a los depositantes.

Una auditoría anterior o un largo historial de actividad reducen parte de la incertidumbre, pero no eliminan el riesgo de los contratos inteligentes.

¿Qué ocurre después de un ataque con flash loan?

El protocolo objetivo puede pausar los depósitos, las retiradas, los préstamos o el trading.

Los desarrolladores y los investigadores de seguridad analizan la traza de la transacción para identificar la vulnerabilidad.

El protocolo puede actualizar los contratos si dispone de permisos de actualización.

Los participantes en la gobernanza pueden votar sobre indemnizaciones, gestión de la deuda, uso de la tesorería o recuperación del sistema.

Algunos proyectos intentan comunicarse con el atacante y pedirle que devuelva los activos.

Es posible supervisar direcciones de blockchain, pero el protocolo afectado normalmente no puede revertir una transferencia on-chain, a menos que el token o el contrato incluya controles especiales.

Los usuarios pueden sufrir bloqueos de fondos, una caída del valor del token, deuda incobrable o pérdidas parciales incluso después de corregirse la vulnerabilidad técnica.

¿Se puede revertir un ataque con flash loan?

El prestamista del flash loan o los usuarios afectados normalmente no pueden revertir una transacción confirmada en la blockchain.

El protocolo puede recuperar activos si el atacante los devuelve voluntariamente o los envía a una dirección controlada.

Los emisores de activos pueden tener la capacidad técnica de congelar determinados tokens, según su diseño.

Una tesorería del protocolo, un fondo de reserva o un acuerdo de seguro pueden cubrir parte de la pérdida.

La gobernanza también puede aprobar nuevos tokens o ajustes contables, pero estas acciones no eliminan la transacción original.

¿Son ilegales los ataques con flash loan?

Un flash loan, por sí mismo, es una herramienta neutral de contrato inteligente.

Utilizarlo para robar activos, manipular mercados, acceder a sistemas sin autorización o engañar a usuarios puede infringir leyes penales, civiles, financieras o sobre el uso indebido de sistemas informáticos.

El tratamiento jurídico depende de la jurisdicción, la estructura de la transacción, los activos afectados, la intención y la normativa aplicable.

Que un contrato inteligente haya aceptado una transacción no significa automáticamente que la acción estuviera autorizada legalmente.

Los desarrolladores y traders deberían solicitar asesoramiento jurídico cualificado antes de participar en actividades que puedan perjudicar a otro protocolo o a sus usuarios.

Ataque con flash loan frente a rug pull

Por lo general, un atacante externo realiza un ataque con flash loan para explotar una debilidad del protocolo.

Un rug pull suele implicar que personas internas o controladores del proyecto retiren liquidez intencionadamente, abandonen el proyecto o abusen de sus privilegios de acceso.

Un rug pull puede incluir vulnerabilidades de contratos inteligentes o liquidez de flash loans, pero ambos términos describen causas principales diferentes.

La distinción puede no estar clara cuando alguien interno explota de forma anónima una vulnerabilidad que esa misma persona creó.

Ataque con flash loan frente a ataque de reentrancia

Un ataque de reentrancia explota una llamada de retorno externa antes de que se haya finalizado el estado interno.

Un ataque con flash loan utiliza capital prestado temporalmente para amplificar una debilidad.

Una explotación puede ser a la vez un ataque de reentrancia y un ataque con flash loan si el atacante toma prestados activos y después utiliza la reentrancia para vaciar el protocolo objetivo.

En ese ejemplo, la liquidez del flash loan es el mecanismo de financiación y la reentrancia es la vulnerabilidad técnica.

Ataque con flash loan frente a ataque a un oráculo

Un ataque a un oráculo manipula o aprovecha los datos que utiliza un contrato inteligente.

Un flash loan puede proporcionar el capital necesario para manipular una fuente de precios on-chain.

No todos los ataques a oráculos utilizan flash loans ni todos los ataques con flash loan se dirigen a un oráculo.

Los términos se solapan cuando se utiliza capital temporal para distorsionar un precio que controla los préstamos, la liquidación o la liquidación de operaciones.

Ataque con flash loan frente a arbitraje

El arbitraje aprovecha las diferencias de precios entre mercados y puede ayudar a acercar los precios.

Un ataque con flash loan extrae valor mediante un comportamiento imprevisto del protocolo o una debilidad de seguridad.

Una transacción puede incluir el arbitraje como uno de sus pasos y, al mismo tiempo, explotar un protocolo vulnerable.

La diferencia clave está en si el beneficio procede de diferencias normales de mercado o de hacer que un sistema calcule o transfiera valor de forma incorrecta.

Ideas equivocadas habituales sobre los ataques con flash loan

Los flash loans no son intrínsecamente maliciosos.

Un ataque con flash loan no permite al atacante ignorar la devolución.

El atacante debe devolver el préstamo si la transacción se completa correctamente.

El flash loan no suele ser la vulnerabilidad original.

Bloquear a un proveedor de flash loans no hace que un protocolo sea seguro, ya que el atacante puede recurrir a otra fuente de liquidez o a su propio capital.

Que un precio vuelva a la normalidad después de la transacción no significa que no se hayan producido daños.

Puede que el protocolo vulnerable ya haya generado deuda incobrable o transferido activos de forma permanente.

Una auditoría de seguridad no garantiza protección frente a todos los ataques con flash loan.

Los únicos objetivos no son los protocolos pequeños, ya que los sistemas grandes también pueden presentar interacciones económicas imprevistas.

Un ataque revertido no siempre es gratuito, porque el emisor puede perder gas y otros costes de ejecución.

Preguntas frecuentes

¿Qué es un ataque con flash loan en cripto?

Un ataque con flash loan es una explotación que utiliza criptomonedas temporales sin garantía para manipular o aprovechar un contrato inteligente vulnerable dentro de una sola transacción.

¿Cómo obtiene beneficios un atacante con flash loan?

El atacante extrae activos de un protocolo vulnerable, devuelve el principal y la comisión del préstamo y conserva el valor restante como beneficio.

¿El atacante con flash loan tiene que devolver el préstamo?

Sí. Por lo general, la transacción revierte si no se devuelve el principal y la comisión exigida antes de que finalice la ejecución.

¿Por qué no revierte el ataque?

El ataque se completa cuando se devuelve el préstamo al prestamista del flash loan, aunque otro protocolo pierda activos debido a su propia lógica vulnerable.

¿Son ilegales los flash loans?

No. Los flash loans son herramientas neutrales de DeFi, aunque utilizarlos para robar activos o manipular mercados puede infringir la legislación aplicable.

¿Todos los flash loans son ataques?

No. Los flash loans legítimos se utilizan para arbitraje, refinanciación, cambios de colateral, liquidaciones y gestión de liquidez.

¿Cuál es el ataque con flash loan más habitual?

La manipulación de oráculos de precios es un patrón habitual en el que el capital temporal modifica el precio de un mercado con poca liquidez utilizado por otro protocolo.

¿Qué es un oráculo en un ataque con flash loan?

Un oráculo es una fuente de datos que proporciona a un contrato inteligente información como el precio de una criptomoneda.

¿Por qué son peligrosos los precios spot?

Una operación suficientemente grande puede modificar temporalmente el precio spot de un único pool de liquidez.

¿Puede un flash loan manipular la gobernanza?

Sí. Los tokens temporales pueden influir en la gobernanza cuando el poder de voto se calcula a partir de los saldos actuales sin instantáneas históricas ni periodos de espera.

¿Puede un flash loan atacar una bóveda?

Sí. Los atacantes pueden manipular los cálculos de participaciones, las donaciones, el redondeo o los saldos de activos de una bóveda tokenizada vulnerable.

¿Pueden los flash loans provocar reentrancia?

La llamada de retorno de un flash loan puede crear una oportunidad de llamada externa, pero solo se produce reentrancia cuando los contratos conectados gestionan esa llamada de retorno u otra llamada de forma insegura.

¿Qué es un ataque de donación?

Un ataque de donación transfiere activos directamente a un contrato para manipular su contabilidad, el precio de las participaciones, el valor del colateral o los cálculos de retirada.

¿Qué es un ataque de acuñación flash?

Un ataque de acuñación flash utiliza tokens creados temporalmente para aprovechar un protocolo que considera que los saldos de corta duración representan una titularidad económica permanente.

¿Se puede utilizar un NFT en un ataque con flash loan?

Sí. La titularidad temporal de un NFT puede aprovechar sistemas que conceden recompensas, derechos de voto o acceso basándose únicamente en la titularidad actual.

¿Los ataques con flash loan se producen en un bloque?

Normalmente ocurren dentro de una sola transacción, que también se incluye en un único bloque de blockchain.

¿Puede un ataque con flash loan abarcar varios protocolos?

Sí. Una transacción puede interactuar con numerosos contratos de trading, préstamos, bóvedas, oráculos y tokens.

¿Se puede perder dinero con un ataque fallido con flash loan?

Sí. Un intento revertido puede consumir gas y generar costes off-chain de desarrollo o infraestructura.

¿Cómo se detectan los ataques con flash loan?

Los sistemas de seguridad analizan las trazas de transacciones para detectar grandes préstamos temporales seguidos de cambios inusuales de precios, préstamos, acuñaciones, retiradas o acciones de gobernanza.

¿Cómo pueden prevenir los protocolos los ataques con flash loan?

Los protocolos pueden utilizar precios resistentes a la manipulación, saldos históricos de voto, contabilidad segura, redondeo prudente, límites por transacción, validación de llamadas de retorno, protección contra la reentrancia y pruebas exhaustivas.

¿Puede un protocolo bloquear sin más los flash loans?

Bloquear las direcciones de prestamistas conocidas es una protección débil, ya que los atacantes pueden utilizar otros prestamistas, activos acuñados mediante flash mint, contratos personalizados o su propio capital.

¿Un precio medio ponderado por tiempo detiene todos los ataques?

No. Aumenta el coste de la manipulación a corto plazo, pero puede fallar si la ventana es demasiado corta, la liquidez es escasa o el diseño de los datos es inseguro.

¿Se puede revertir un ataque con flash loan?

Una transacción confirmada normalmente no se puede revertir, aunque es posible recuperar los activos mediante una devolución voluntaria, facultades de congelación, acciones legales o compensaciones del protocolo.

¿Los protocolos auditados están protegidos frente a ataques con flash loan?

Una auditoría reduce algunos riesgos, pero no puede garantizar la seguridad frente a todos los cambios de código, condiciones económicas, integraciones o vulnerabilidades hasta entonces desconocidas.

¿Qué deberían hacer los usuarios después de un ataque con flash loan?

Los usuarios deberían seguir los anuncios verificados del protocolo, evitar firmar transacciones de recuperación inesperadas, revocar las autorizaciones inseguras cuando corresponda y conservar los registros de transacciones.

¿Un ataque con flash loan es lo mismo que un hackeo?

Un ataque con flash loan es un tipo de explotación cripto, mientras que el término hackeo puede referirse a diversas formas de vulneración técnica, operativa o de cuentas.

Conclusión

Un ataque con flash loan utiliza criptomonedas temporales sin garantía para amplificar una debilidad de la lógica de un contrato inteligente.

El atacante toma prestados activos, manipula el estado del protocolo, extrae valor y devuelve el préstamo dentro de una transacción atómica.

El flash loan no suele ser la vulnerabilidad subyacente, ya que el problema real suele encontrarse en los oráculos de precios, las fórmulas contables, las reglas de gobernanza, las llamadas de retorno, las comprobaciones de colateral o los controles de acceso.

La devolución atómica protege al prestamista frente al impago habitual, pero no protege a otros protocolos que confían en precios manipulados o saldos temporales inseguros.

Los desarrolladores deben diseñar sistemas partiendo de la premisa de que cualquier usuario puede controlar temporalmente cantidades muy elevadas de criptomonedas.

Los precios resistentes a la manipulación, las instantáneas históricas de gobernanza, la contabilidad prudente, la protección contra la reentrancia, los límites por transacción, las pruebas de invariantes y la supervisión en tiempo real pueden reducir el riesgo.

Los flash loans siguen siendo herramientas útiles de DeFi, pero su eficiencia de capital hace que sea más fácil explotar a gran escala cualquier suposición económica débil de un contrato inteligente.