Saltar al contenido
Est. MMXXVIVol. VI · № 273RSS
Blockchain Breaches

Archivo de incidentes de seguridad en criptomonedas — hackeos, exploits, fallos de puentes y rug pulls, documentados con evidencia on-chain.

Expediente № 149Fallo de compilador

Reentrada Vyper en Curve Finance

Un bloqueo de reentrada defectuoso en tres versiones del compilador Vyper expuso varios stablepools de Curve a un ataque clásico de reentrada.

Fecha
Cadena(s)
Estado
Parcialmente recuperado

El 30 de julio de 2023, varios pools de stablecoins de Curve Finance fueron drenados mediante ataques de reentrada por un total de aproximadamente 73 M$. El bug no estaba en la lógica equivalente en Solidity de Curve, sino en el propio compilador Vyper.

Qué ocurrió

Tres versiones de Vyper (0.2.15, 0.2.16, 0.3.0) implementaban el decorador @nonreentrant con un bloqueo defectuoso que en realidad no impedía la reentrada en ciertos caminos de código. Varios pools de Curve —incluidos alETH/ETH, msETH/ETH, pETH/ETH y el pool CRV/ETH— se habían desplegado con estas versiones del compilador y, por tanto, eran vulnerables al ataque canónico de reentrada de 2016.

El atacante llamaba a remove_liquidity en mitad de un swap, lo que disparaba una transferencia de ETH a un contrato controlado que volvía a entrar en el pool antes de que se actualizara el almacenamiento, permitiendo retiros repetidos por encima de la participación real del atacante.

Consecuencias

  • Vyper publicó versiones parcheadas y un aviso claro listando las versiones afectadas.
  • Una coalición de buscadores MEV de sombrero blanco ("c0ffeebabe.eth") adelantó (front-run) ~5,4 M$ del exploit y los devolvió a Curve.
  • Varias porciones de la pérdida se recuperaron mediante negociación; el resto sigue pendiente.
  • Las firmas de auditoría incluyen ahora de forma rutinaria comprobaciones de versión del compilador en sus listas de verificación para despliegues de Vyper.

Por qué importa

Curve es uno de los protocolos más auditados de DeFi. El ataque subrayó que las auditorías del contrato en sí no pueden garantizar la seguridad si el compilador que produce el bytecode tiene bugs. Las builds reproducibles y la transparencia de versiones del compilador se han convertido desde entonces en práctica estándar.