Ataque de reentrada

¿Qué es un ataque de reentrada en el sector cripto?

Un ataque de reentrada es un exploit de un contrato inteligente en el que un contrato externo vuelve a llamar a un contrato vulnerable antes de que haya terminado la primera llamada a una función.

En el sector cripto, este ataque suele dirigirse a contratos inteligentes que almacenan fondos, llevan un registro de saldos, procesan retiradas, calculan recompensas, gestionan participaciones en bóvedas o interactúan con otros contratos.

El problema fundamental es que el contrato vulnerable cede el control a otro contrato antes de terminar de actualizar su propio estado interno.

Si el atacante puede volver a entrar en el contrato mientras ese estado sigue sin actualizarse, puede repetir una acción que solo debería haberse permitido una vez.

Un ejemplo habitual es una función de retirada que envía criptomonedas a un usuario antes de reducir el saldo registrado de ese usuario.

Si el destinatario es un contrato malicioso, puede utilizar su lógica de reserva o de callback para volver a llamar a la función de retirada antes de que se actualice el saldo.

Esto puede permitir al atacante retirar más de lo que tiene derecho a recibir.

La página de OWASP sobre ataques de reentrada del Smart Contract Top 10 de 2026 define la reentrada como una situación en la que un contrato realiza una llamada externa y el contrato llamado vuelve a llamar al contrato original antes de que se haya actualizado por completo su estado.

La reentrada es una de las vulnerabilidades más conocidas de los contratos inteligentes porque ataca directamente el modelo de confianza de la contabilidad on-chain.

Es especialmente peligrosa en las finanzas descentralizadas, ya que los contratos inteligentes suelen gestionar grandes pools de liquidez y dependen de otros contratos para realizar swaps, gestionar colateral y recompensas o consultar datos de precios.

Cómo funciona un ataque de reentrada

Un ataque de reentrada comienza cuando un contrato inteligente vulnerable realiza una llamada externa a otro contrato o dirección.

La llamada externa puede enviar criptomonedas nativas, transferir tokens, llamar a un hook, solicitar un callback, ejecutar una estrategia o interactuar con otro protocolo.

Al realizar esa llamada, el contrato vulnerable da temporalmente al contrato receptor la oportunidad de ejecutar su propio código.

Si el atacante controla el contrato receptor, puede aprovechar ese momento para volver a llamar al contrato vulnerable.

Es posible que el contrato vulnerable aún contenga valores de estado anteriores porque todavía no ha actualizado los saldos, la deuda, las participaciones, los índices de recompensas o los indicadores de bloqueo.

El atacante puede aprovechar esos valores anteriores para repetir una retirada, reclamar recompensas dos veces, pedir prestado más de lo permitido o manipular un cálculo.

El ataque continúa hasta que el contrato vulnerable se queda sin fondos, la transacción agota el gas o un mecanismo de protección detiene las llamadas repetidas.

La documentación de Solidity sobre llamadas externas advierte que interactuar con otro contrato le cede el control y que el contrato llamado puede volver a llamar al contrato original antes de que finalice la primera llamada.

Esta advertencia es la base de la defensa frente a la reentrada.

Debe considerarse que cualquier llamada externa puede ser un punto en el que se rompan las suposiciones del contrato.

Ejemplo sencillo de reentrada

Imagina un contrato de préstamos que registra el saldo de depósito de cada usuario.

Un usuario deposita 10 ETH en el contrato.

El contrato registra que el usuario tiene un saldo de 10 ETH.

Más tarde, el usuario llama a una función de retirada para recuperar los 10 ETH.

Un contrato seguro reduciría a cero el saldo del usuario antes de enviarle los ETH.

Un contrato vulnerable envía primero los ETH y actualiza el saldo después.

Si el usuario es en realidad un contrato malicioso, su función receive se ejecutará cuando se envíen los ETH.

Esa función receive puede llamar de inmediato otra vez a withdraw mientras el contrato vulnerable todavía cree que el usuario tiene 10 ETH.

La misma retirada puede repetirse una y otra vez en una sola transacción.

Por eso, el orden de la lógica de un contrato inteligente es tan importante.

En el software tradicional, un pequeño error de orden puede provocar un error contable normal.

En un contrato inteligente que almacena criptoactivos, el mismo error de orden puede abrir una vía directa para robar activos.

Por qué son peligrosos los ataques de reentrada

Los ataques de reentrada son peligrosos porque los contratos inteligentes suelen controlar activos que pueden ser difíciles de recuperar tras un exploit.

Las blockchains públicas están diseñadas para ejecutar transacciones válidas y conservar su historial.

Si una transacción maliciosa cumple las reglas de la blockchain, pero aprovecha un error del contrato, normalmente es difícil revertir los daños.

La guía de seguridad de contratos inteligentes de Ethereum.org explica que suele ser difícil modificar el código de los contratos inteligentes desplegados y que recuperar los activos robados resulta complicado debido a la inmutabilidad de la blockchain.

Por eso, prevenir el problema es mucho más importante que intentar repararlo después.

Un error de reentrada puede vaciar pools de liquidez, bóvedas, bridges, sistemas de staking, mercados de NFT, contratos de recompensas y protocolos de préstamos.

También puede dañar la confianza de los usuarios, aunque posteriormente se recuperen los activos robados.

En el sector cripto, el riesgo de los contratos inteligentes no es solo un problema para los desarrolladores.

Puede convertirse a la vez en un problema para los usuarios, la liquidez, la gobernanza y la reputación.

Reentrada clásica

La reentrada clásica se produce cuando un atacante vuelve a entrar en la misma función que realizó la llamada externa.

El ejemplo más habitual es una función withdraw vulnerable.

La función comprueba que el usuario tiene saldo, le envía los fondos y solo entonces actualiza el saldo.

El contrato del atacante recibe los fondos y vuelve a llamar a la misma función withdraw antes de que se reduzca el saldo.

Esto crea un bucle en el que el mismo saldo registrado puede utilizarse varias veces.

La reentrada clásica es fácil de entender, pero sigue siendo peligrosa porque muchos desarrolladores continúan realizando demasiado pronto las llamadas externas.

También es peligrosa porque los contratos modernos suelen utilizar una contabilidad más compleja que un simple registro de depósitos y retiradas.

Una función vulnerable puede incluir participaciones, posiciones de deuda, multiplicadores de recompensas, activos de bóvedas, tokens de liquidez o contabilidad de comisiones.

Aunque el patrón parezca distinto del ejemplo clásico, puede seguir existiendo el mismo problema de fondo.

Reentrada entre funciones

La reentrada entre funciones se produce cuando el atacante vuelve a entrar en otra función del mismo contrato.

Es más sutil que la reentrada clásica porque la función atacada puede parecer segura cuando se revisa por separado.

Por ejemplo, una función puede iniciar una retirada y realizar una llamada externa.

Durante esa llamada externa, el atacante puede llamar a otra función que dependa del mismo saldo, participación o estado de permisos.

Si la primera función aún no ha terminado de actualizar el estado, la segunda puede consultar información obsoleta.

Esto puede permitir al atacante reclamar recompensas, transferir participaciones, pedir activos prestados o cambiar una posición antes de que se complete la primera acción.

La reentrada entre funciones demuestra por qué los desarrolladores deben tener en cuenta las invariantes de todo el contrato, en lugar de proteger únicamente una función withdraw evidente.

Una invariante de un contrato es una regla que debe seguir cumpliéndose antes y después de cada operación válida.

Si las llamadas externas pueden vulnerar temporalmente una invariante, otras funciones pueden convertirse en vías de ataque.

Reentrada entre contratos

La reentrada entre contratos se produce cuando la ruta del callback pasa por varios contratos.

Puede ocurrir en sistemas DeFi donde interactúan bóvedas, estrategias, routers, contratos de tokens, lectores de oráculos, módulos de staking y distribuidores de recompensas.

Una bóveda puede llamar a una estrategia.

La estrategia puede llamar a un token o a otro protocolo.

El contrato llamado puede activar un callback que vuelva a la bóveda o llegue a un contrato relacionado del que dependa la bóveda.

El estado vulnerable quizá no esté en el mismo contrato que realizó la primera llamada externa.

La documentación de Solidity sobre consideraciones de seguridad señala que la reentrada no se debe únicamente a las transferencias de Ether y que también deben tenerse en cuenta las situaciones en las que participan varios contratos.

Esto es importante porque las aplicaciones cripto modernas son muy componibles.

La componibilidad permite que los protocolos se conecten y se construyan unos sobre otros, pero también crea más vías para callbacks inesperados.

Reentrada de solo lectura

La reentrada de solo lectura se produce cuando una función view o de lectura devuelve información engañosa durante una transición de estado que aún no ha terminado.

Al principio puede parecer inofensiva porque las funciones view no modifican directamente el estado.

Sin embargo, otros contratos pueden utilizar funciones view para calcular precios, participaciones, valores de colateral, tipos de cambio o cantidades de recompensas.

Si se produce un callback mientras un contrato se encuentra en un estado intermedio, una función view puede devolver un valor temporal en el que no debería confiarse.

Un atacante puede utilizar ese valor temporal en otro contrato que dependa de él.

Esto puede provocar una manipulación similar a la de un oráculo o errores contables sin vaciar directamente el primer contrato mediante una función de retirada normal.

La reentrada de solo lectura recuerda que la seguridad no depende únicamente de si una función escribe en el almacenamiento.

También depende de si otros contratos pueden observar un estado incompleto y tomar decisiones financieras basándose en él.

Reentrada basada en hooks

La reentrada basada en hooks se produce cuando las interfaces de protocolos o los estándares de tokens llaman deliberadamente a la lógica del receptor durante una transferencia u operación.

Algunos estándares de tokens y NFT incluyen hooks del receptor para que los contratos puedan reaccionar cuando reciben activos.

Los sistemas de préstamos flash también utilizan callbacks para que quien los toma pueda usar la liquidez prestada y devolverla dentro de la misma transacción.

Estos hooks son útiles, pero también crean oportunidades para los callbacks.

Un contrato que dé por hecho que la transferencia de un token es una acción sencilla que no ejecuta código externo puede estar equivocado.

Según el estándar y la implementación del token, una transferencia puede activar lógica del receptor, hooks del operador u otros comportamientos de contratos.

Los desarrolladores deben revisar cada interacción externa con tokens como un posible punto de reentrada.

Esto es especialmente importante para los contratos que admiten muchos tokens, activos de bóveda o integraciones externas.

Objetivos habituales de los ataques de reentrada

Las funciones de retirada son el objetivo más habitual de los ataques de reentrada porque suelen enviar fondos fuera de un contrato.

Las funciones de depósito y retirada de bóvedas también son objetivos frecuentes, ya que actualizan los saldos de participaciones y la contabilidad de activos.

Los protocolos de préstamos pueden ser un objetivo porque llevan el control del colateral, la deuda, los intereses, los umbrales de liquidación y los saldos prestados.

Los contratos de staking pueden ser un objetivo porque calculan recompensas a lo largo del tiempo y pueden transferir tokens de recompensa al reclamarlas.

Los mercados de NFT pueden ser un objetivo porque las compras y los pagos pueden activar hooks de recepción de tokens o lógica externa de royalties.

Los contratos de bridges pueden ser un objetivo porque gestionan mensajes entre cadenas, bloqueos de activos y procesos de liberación.

Los contratos de ejecución de gobernanza pueden ser un objetivo porque realizan llamadas externas al ejecutar propuestas.

Los receptores y proveedores de préstamos flash pueden ser objetivos porque su diseño depende de los callbacks.

Cualquier contrato inteligente que envíe valor o llame a código no fiable antes de terminar su contabilidad interna debe considerarse un posible objetivo de reentrada.

El patrón Checks-Effects-Interactions

El patrón Checks-Effects-Interactions es una de las defensas más importantes frente a los ataques de reentrada.

Checks significa que el contrato comprueba primero si el usuario puede realizar la acción.

Effects significa que el contrato actualiza su estado interno antes de realizar cualquier llamada externa.

Interactions significa que el contrato solo realiza llamadas externas después de completar las comprobaciones y las actualizaciones de estado.

En una función de retirada, el contrato debe comprobar que el usuario tiene saldo, reducirlo y solo entonces enviar los fondos.

Así, si el destinatario intenta volver a entrar, el contrato ya reflejará el saldo actualizado.

La documentación de Solidity sobre Checks-Effects-Interactions describe este patrón como una forma habitual de evitar ataques de reentrada.

El patrón es sencillo, pero es imprescindible en los contratos que interactúan con código externo no fiable.

Los desarrolladores deben adoptarlo como práctica predeterminada siempre que una función modifique el estado y realice llamadas fuera del contrato.

Protecciones contra la reentrada

Una protección contra la reentrada es un bloqueo que impide volver a acceder a una función protegida antes de que termine la primera llamada.

En los contratos Solidity, suele implementarse con una variable de estado que indica que se está ejecutando una función.

Si una llamada reentrante intenta acceder a la misma ruta protegida, el bloqueo la rechaza.

La documentación de OpenZeppelin Contracts 5.x sobre ReentrancyGuard describe ReentrancyGuard como un módulo que proporciona el modificador nonReentrant para impedir llamadas reentrantes anidadas.

Las protecciones contra la reentrada son útiles porque añaden una capa de seguridad clara a las funciones de alto riesgo.

Sin embargo, una protección no sustituye a una contabilidad correcta.

Los desarrolladores deben seguir utilizando Checks-Effects-Interactions y revisar todas las llamadas externas.

OpenZeppelin también señala que, al existir un único bloqueo nonReentrant, las funciones marcadas con nonReentrant no pueden llamarse directamente entre sí.

Una solución habitual consiste en hacer privada la lógica interna y ofrecer puntos de entrada externos independientes protegidos con nonReentrant.

Almacenamiento transitorio y bloqueos de reentrada

El almacenamiento transitorio es una función más reciente de la EVM que puede utilizarse para valores temporales que solo duran durante una transacción.

Puede resultar útil para los bloqueos de reentrada porque no siempre es necesario conservar un bloqueo en el almacenamiento permanente después de que termine la llamada.

La documentación de OpenZeppelin ReentrancyGuardTransient describe una variante de ReentrancyGuard basada en almacenamiento transitorio para blockchains compatibles con EIP-1153.

La documentación de Solidity sobre almacenamiento transitorio indica que es seguro utilizarlo para bloqueos de reentrada que se eliminan al finalizar el marco de llamada.

Esto no significa que todos los contratos deban utilizar automáticamente el almacenamiento transitorio.

Los desarrolladores deben confirmar que la blockchain de destino admite la función requerida y que el bloqueo se elimina correctamente.

Un bloqueo mal gestionado puede romper la componibilidad o dificultar el uso del contrato en transacciones complejas.

La mejor opción depende de la blockchain de destino, la versión del compilador, la versión de la biblioteca, el patrón de actualización y los requisitos de auditoría.

Por qué transfer y send no son defensas completas

Las guías antiguas de Solidity consideraban a menudo que las transferencias con gas limitado eran una medida práctica para mitigar la reentrada.

Las recomendaciones actuales son más prudentes porque los costes de gas y el comportamiento de la EVM pueden cambiar con el tiempo.

La documentación de Solidity sobre los miembros de address advierte que send y transfer están obsoletos y recomienda otros métodos para protegerse frente a la reentrada.

Esto es importante porque confiar únicamente en una cantidad limitada de gas puede generar una falsa sensación de seguridad.

Un contrato debe ser seguro porque la lógica de su estado es correcta, no porque suponga que el destinatario no tendrá gas suficiente para realizar una acción peligrosa.

La opción más segura es actualizar el estado antes de las llamadas externas, utilizar protecciones contra la reentrada cuando corresponda, comprobar los valores devueltos y diseñar cuidadosamente los procesos de retirada.

Los desarrolladores también deben revisar el código antiguo que aún utiliza transfer o send como principal defensa contra la reentrada.

Las prácticas de seguridad cripto cambian a medida que evolucionan las reglas de los protocolos, los costes de gas y las técnicas de ataque habituales.

Pagos pull como defensa

Un patrón de pagos pull permite que los destinatarios retiren los fondos por sí mismos, en lugar de que un contrato les envíe los fondos durante otra operación.

Esto reduce el riesgo porque el contrato puede registrar el importe que debe pagar y permitir que el destinatario lo reclame en un paso aparte.

Por ejemplo, un mercado puede registrar los ingresos del vendedor en lugar de enviarle los fondos dentro de la transacción de compra del comprador.

Más adelante, el vendedor llama a una función de retirada para reclamar los fondos.

Este patrón puede limitar los daños causados por un destinatario malicioso que rechace los pagos o intente volver a entrar durante un desembolso.

La documentación de las utilidades de seguridad de OpenZeppelin describe PullPayment como un patrón que puede ayudar a evitar ataques de reentrada.

Los pagos pull no son perfectos para todos los diseños, ya que pueden añadir pasos para los usuarios.

Sin embargo, pueden resultar muy útiles cuando muchos usuarios o contratos necesitan recibir pagos del mismo sistema.

Controles de pausa de emergencia

Un control de pausa de emergencia permite a cuentas autorizadas o sistemas de gobernanza pausar funciones sensibles durante un incidente.

Esto puede ayudar a limitar los daños si se detectan comportamientos sospechosos o un posible exploit de reentrada.

Una función de pausa puede detener retiradas, depósitos, reclamaciones de recompensas, nuevos préstamos u otras acciones de riesgo mientras el equipo investiga.

OpenZeppelin incluye Pausable entre los mecanismos habituales de respuesta de emergencia para pausar funciones mientras se resuelve el problema.

Un sistema de pausa debe diseñarse con cuidado porque implica concesiones en materia de gobernanza y centralización.

Si la autoridad de pausa tiene demasiado poder, los usuarios pueden temer la censura o un uso indebido.

Si tiene demasiado poco poder o actúa con demasiada lentitud, quizá no ayude durante un exploit activo.

En los protocolos cripto de gran valor, la planificación de la respuesta de emergencia debe formar parte del diseño de seguridad desde el principio.

Cómo pueden detectar los desarrolladores el riesgo de reentrada

Los desarrolladores pueden detectar el riesgo de reentrada revisando todas las llamadas externas del contrato.

Entre las llamadas externas se incluyen las transferencias de monedas nativas y tokens, las llamadas de bajo nivel, las llamadas a interfaces, los callbacks de préstamos flash, los hooks de recepción de NFT y las llamadas a módulos de protocolos.

Ante cada llamada externa, los desarrolladores deben preguntarse si ya se ha actualizado el estado interno.

También deben preguntarse si es posible llamar a otra función durante la llamada externa y que esta observe un estado obsoleto.

Deben revisar si varios contratos comparten suposiciones que podrían verse vulneradas por un callback.

Deben probar contratos receptores maliciosos que intenten volver a llamar a todas las funciones públicas y externas.

Deben combinar análisis estático, pruebas fuzz, pruebas unitarias, pruebas de invariantes y revisión manual.

La documentación de Solidity SMTChecker incluye las propiedades de reentrada entre los comportamientos que pueden analizarse en torno a llamadas externas a código desconocido.

Ninguna herramienta puede garantizar por sí sola que un contrato sea seguro.

La detección de reentradas funciona mejor cuando se combinan herramientas automatizadas con una revisión de seguridad experta.

Cómo pueden valorar los usuarios el riesgo de reentrada

La mayoría de los usuarios no puede auditar por completo un contrato inteligente antes de utilizarlo.

Sin embargo, pueden reducir el riesgo buscando indicios de buenas prácticas de seguridad.

Un protocolo debe ofrecer información clara sobre auditorías, programas de recompensas por errores, controles de emergencia, permisos de actualización y divulgación de riesgos.

Los usuarios deben tener cuidado con los contratos nuevos que controlan grandes cantidades de valor, pero apenas han sido revisados públicamente.

También deben desconfiar de los protocolos que ofrecen rendimientos inusualmente altos sin explicar de dónde proceden ni cuáles son los riesgos de los contratos inteligentes.

Puede existir riesgo de reentrada aunque la interfaz del usuario tenga un aspecto cuidado y profesional.

Una buena interfaz no demuestra que la lógica del contrato subyacente sea segura.

Los usuarios deben evitar depositar en contratos no auditados o experimentales más de lo que puedan permitirse perder.

También deben entender que las auditorías reducen el riesgo, pero no lo eliminan por completo.

Reentrada y componibilidad DeFi

La componibilidad DeFi significa que los contratos inteligentes pueden conectarse entre sí como piezas de construcción financiera.

Esta es una de las funciones más potentes del sector cripto, ya que permite que interactúen wallets, bóvedas, mercados de préstamos, swaps, derivados, sistemas de staking y herramientas de gobernanza.

Sin embargo, la componibilidad también aumenta el riesgo de reentrada porque una transacción puede pasar por muchos contratos.

Una operación que parece segura en un contrato puede activar un comportamiento complejo en otro.

Un callback puede llegar a un tercer contrato que cambie un valor del que depende el primero.

Un precio, el valor de una participación o un saldo pueden consultarse durante un estado temporal que nunca debió quedar expuesto externamente.

Por eso, el análisis moderno de la reentrada debe abarcar toda la ruta de interacción.

Los desarrolladores no deben revisar cada contrato como si existiera de forma aislada.

Deben analizar cómo se comportan los contratos al combinarse con routers, tokens, bóvedas, préstamos flash y estrategias externas.

Reentrada y préstamos flash

Los préstamos flash pueden hacer que los ataques de reentrada sean más potentes porque permiten a los atacantes acceder a una gran liquidez temporal dentro de una transacción.

Un préstamo flash no es por sí mismo un ataque de reentrada.

Es una herramienta que puede utilizarse para arbitraje legítimo, refinanciación, liquidaciones y operaciones eficientes en cuanto al capital.

Sin embargo, si se puede manipular un contrato vulnerable dentro de una transacción, un préstamo flash puede proporcionar al atacante capital suficiente para que el exploit resulte rentable.

Los callbacks de préstamos flash también exigen un diseño cuidadoso, ya que los sistemas basados en callbacks ceden deliberadamente el control a otro contrato.

Los desarrolladores deben tratar todos los callbacks como llamadas externas no fiables, salvo que exista una razón sólida para no hacerlo.

Siempre que sea posible, deben actualizar el estado antes de los callbacks y comprobar los reembolsos finales, los saldos y las invariantes cuando el callback haya finalizado.

Las integraciones de préstamos flash deben probarse con contratos prestatarios maliciosos, no solo con ejemplos de prestatarios normales.

Reentrada y contratos actualizables

Los contratos actualizables requieren especial atención al utilizar protecciones contra la reentrada.

Un proxy actualizable separa el almacenamiento visible para los usuarios de la lógica de implementación.

Si una protección contra la reentrada utiliza almacenamiento, los desarrolladores deben comprobar que la disposición del almacenamiento sea correcta y compatible entre actualizaciones.

Modificar incorrectamente la disposición del almacenamiento puede desactivar la protección o corromper variables de estado importantes.

Al crear contratos actualizables, los desarrolladores deben utilizar bibliotecas compatibles con actualizaciones.

También deben probar las actualizaciones con estados anteriores del contrato, no solo con despliegues nuevos.

Un contrato puede ser seguro en su primera versión y volverse vulnerable después de una actualización que cambie el orden de las llamadas o añada una nueva integración externa.

Las revisiones de actualizaciones deben incluir un análisis de reentrada de cada nueva llamada externa.

Los sistemas de gobernanza o administración que ejecutan actualizaciones también deben contar con demoras, revisiones y controles de emergencia cuando el protocolo gestione un valor significativo.

Buenas prácticas para prevenir ataques de reentrada

Actualiza el estado interno antes de realizar llamadas externas.

Utiliza el patrón Checks-Effects-Interactions en retiradas, reclamaciones, transferencias, swaps y cambios contables.

Aplica una protección contra la reentrada a los puntos de entrada externos de alto riesgo.

No des por hecho que las transferencias de tokens son siempre sencillas, ya que algunos estándares e implementaciones pueden activar hooks o callbacks.

No confíes únicamente en los límites de gas de transfer o send para protegerte frente a la reentrada.

Utiliza patrones de pagos pull cuando los pagos directos introduzcan riesgos innecesarios.

Revisa la reentrada entre funciones y entre contratos, no solo la reentrada clásica en una misma función.

Prueba contratos receptores maliciosos que intenten volver a entrar durante cada llamada externa.

Utiliza pruebas de invariantes para confirmar que los saldos totales, las participaciones, la deuda y las reservas siguen siendo correctos durante interacciones complejas.

Incluye planes de pausa de emergencia y respuesta a incidentes para los sistemas de gran valor.

Solicita una revisión de seguridad independiente antes de desplegar contratos que almacenen fondos de usuarios.

Mantén las dependencias actualizadas y consulta las notas de migración de las bibliotecas antes de cambiar a versiones principales nuevas.

Errores habituales de los desarrolladores

Un error habitual es actualizar los saldos después de enviar los fondos.

Otro error frecuente es proteger únicamente la función withdraw y dejar otras funciones relacionadas expuestas a la reentrada entre funciones.

También es habitual suponer que una transferencia de tokens no puede ejecutar código externo.

Otro error consiste en aplicar una protección contra la reentrada a un contrato e ignorar las llamadas a contratos relacionados que comparten supuestos contables.

También se suele confiar en las antiguas suposiciones sobre transfer y send en lugar de diseñar correctamente la lógica del estado.

Otro error es añadir una nueva integración externa durante una actualización sin volver a comprobar toda la ruta de llamadas.

También es un error considerar inofensivas las funciones view aunque otros contratos dependan de sus valores durante transacciones complejas.

Otro error es olvidar que los contratos maliciosos pueden comportarse deliberadamente de forma distinta a los usuarios normales.

Las pruebas de seguridad deben dar por hecho un comportamiento hostil, no solo un uso normal de la interfaz.

Preguntas frecuentes

¿Qué significa ataque de reentrada?

Un ataque de reentrada se produce cuando un contrato malicioso vuelve a llamar a un contrato inteligente vulnerable antes de que termine la primera llamada a una función y antes de que el estado se actualice de forma segura.

¿Por qué es peligrosa la reentrada en el sector cripto?

Es peligrosa porque puede permitir a los atacantes vaciar fondos, reclamar recompensas varias veces, manipular la contabilidad o vulnerar las suposiciones del contrato en una sola transacción.

¿La reentrada solo está relacionada con las transferencias de ETH?

No. La documentación de Solidity advierte de que la reentrada no se limita a las transferencias de Ether, ya que cualquier llamada externa a un contrato puede generar el riesgo de un callback.

¿Cuál es la defensa más conocida contra la reentrada?

El patrón Checks-Effects-Interactions es una de las defensas más conocidas porque actualiza el estado del contrato antes de realizar llamadas externas.

¿Qué es ReentrancyGuard?

ReentrancyGuard es una utilidad para contratos inteligentes que proporciona el modificador nonReentrant para impedir llamadas anidadas a funciones protegidas.

¿ReentrancyGuard puede prevenir todos los errores de reentrada?

No. ReentrancyGuard ayuda a proteger determinados puntos de entrada, pero los desarrolladores siguen necesitando una contabilidad correcta, un orden seguro de las llamadas y una revisión entre contratos.

¿Qué es la reentrada entre funciones?

La reentrada entre funciones se produce cuando un atacante vuelve a entrar en otra función del mismo contrato mientras la primera sigue sin haber terminado.

¿Qué es la reentrada de solo lectura?

La reentrada de solo lectura se produce cuando una función view devuelve un estado temporal engañoso durante una operación inconclusa y otro contrato depende de ese valor.

¿Las transferencias de tokens pueden provocar reentrada?

Sí. Algunos estándares e implementaciones de tokens pueden activar hooks o callbacks, por lo que las transferencias de tokens deben revisarse como posibles llamadas externas.

¿Deben evitar los usuarios todos los contratos inteligentes por el riesgo de reentrada?

No. Los usuarios no tienen que evitar todos los contratos inteligentes, pero deberían dar preferencia a protocolos con auditorías rigurosas, documentación clara, supervisión activa y controles de riesgos responsables.

Conclusión

Un ataque de reentrada es un exploit de un contrato inteligente que aprovecha que el estado no se ha actualizado durante una llamada externa.

El atacante vuelve a entrar en el contrato vulnerable antes de que finalice la primera llamada y aprovecha una contabilidad obsoleta para obtener más valor del permitido.

Aunque el ejemplo clásico es la repetición de una retirada, la reentrada moderna también puede implicar llamadas entre funciones y contratos, estados de solo lectura, hooks de tokens, callbacks de préstamos flash y componibilidad DeFi.

La lección principal es que toda llamada externa debe considerarse una posible cesión del control a código no fiable.

Los desarrolladores pueden reducir el riesgo de reentrada aplicando Checks-Effects-Interactions, utilizando protecciones contra la reentrada, evitando patrones de pago inseguros, probando callbacks maliciosos y revisando todas las rutas de interacción de los contratos.

Los usuarios pueden reducir su exposición eligiendo protocolos que se tomen en serio la seguridad de los contratos inteligentes y evitando sistemas no auditados que gestionen un valor significativo.

La reentrada sigue siendo un concepto fundamental de la seguridad cripto porque puede convertir un pequeño error en el orden de la lógica en un exploit financiero potencialmente grave.

Entender la reentrada ayuda a los desarrolladores a crear contratos más seguros y a los usuarios a comprender la importancia de las auditorías de contratos inteligentes, los patrones de seguridad y los controles de riesgos.