Exploit de gobernanza en Term Finance: por qué el código auditado no protege tus depósitos DeFi

El 23 de agosto de 2026 salieron unos 8,5 millones de dólares de las bóvedas de depósito del protocolo de préstamo sobre Ethereum Term Finance. El atacante no necesitó ningún fallo de seguridad en el código. Compró suficientes derechos de voto para ganar en solitario la votación sobre esas bóvedas. Después aprobó el pago a su favor y ejecutó el acuerdo.

Para ti como inversor, esa es la parte más importante de la noticia. Un protocolo auditado puede vaciarse sin que se rompa una sola línea de código. Quien mantenga saldos en un protocolo DeFi debería saber, por tanto, quién puede votar sobre el uso de ese saldo y con qué rapidez surte efecto un acuerdo de ese tipo.

Exploit de gobernanza en Term Finance: qué ocurrió el 23 de agosto

Term Finance es un protocolo de préstamo sobre la cadena Ethereum que intermedia créditos a tipo fijo. Los usuarios depositan saldos en bóvedas, denominadas vaults, desde las que el protocolo concede préstamos con garantía. Lo desarrolla Term Labs.

Según Cryptobriefing, cuyo informe se apoya en las confirmaciones de las firmas de seguridad CertiK y PeckShield, unos 2.843 ETH y cerca de 1,6 millones de DAI se transfirieron a una única dirección receptora. Su identificador empieza por 0xD5183. A los precios actuales, la salida equivale a los 8,5 millones de dólares citados. Term Labs ha confirmado públicamente el incidente y ha anunciado una exposición más detallada cuando concluya su investigación. El equipo delimita expresamente el caso frente a una vulnerabilidad del contrato inteligente.

Ethereum es la cadena sobre la que corre el protocolo; cómo evoluciona el precio de la moneda asociada lo tienes en nuestra predicción del precio de Ethereum. Para valorar este incidente, sin embargo, el precio no desempeña papel alguno. Lo decisivo es quién puede disponer de una bóveda de depósito.

Ataque de gobernanza explicado: cómo una votación vacía una bóveda

En un protocolo DeFi, la gobernanza designa las reglas conforme a las cuales se deciden los cambios. Quien posee tokens de voto puede presentar propuestas y votarlas; cuando una propuesta alcanza la mayoría necesaria, se ejecuta. Esa es la construcción con la que un protocolo pretende funcionar sin administración central.

Un ataque de gobernanza da la vuelta precisamente a esa construcción. El atacante se hace con suficientes derechos de voto para reunir por sí solo una mayoría y acuerda entonces algo que le beneficia. Formalmente todo transcurre conforme a las reglas del protocolo. No hay allanamiento, ni contraseña robada, ni contrato manipulado, sino una votación ganada.

La diferencia frente a los tipos de ataque más conocidos tiene consecuencias prácticas. Un ataque con préstamo relámpago o un fallo de reentrada presupone un error de programación que una auditoría puede encontrar en principio. Un ataque de gobernanza solo presupone que el peso de voto sea comprable y que nadie intervenga a tiempo.

Strategy Vault y Meta Vault: qué bóvedas controló el atacante

En Term Finance, una bóveda es un fondo de depósito acotado con su propia estrategia de inversión. Un Meta Vault agrupa varias de esas bóvedas y reparte entre ellas los fondos depositados.

Cryptobriefing describe con mucha precisión el control alcanzado: en cuatro de las cinco Strategy Vaults en USDC el atacante llegó al 100 % de los derechos de voto, y en la Meta Vault de Ethereum a cerca del 91 %. Ambas cifras superan la mayoría ajustada. Con ese reparto de votos se puede sacar adelante una propuesta y sostenerla después frente a cualquier objeción.

Las cifras explican también por qué el daño quedó limitado a determinadas bóvedas. Resultó afectado aquello sobre lo que el atacante tenía la mayoría. Quien tenía su saldo en alguna de las otras bóvedas no se vio afectado del mismo modo, según la exposición publicada hasta ahora. No existe todavía un desglose completo de qué bóveda perdió qué fondos; Term Labs lo ha anunciado para el cierre de la investigación.

Dos ETH desde Tornado Cash: cómo un capital inicial se convirtió en mayoría de votos

La financiación inicial del ataque fue llamativamente pequeña, según el informe de Cryptobriefing. Habría consistido en dos ETH obtenidos a través de Tornado Cash. Tornado Cash es un servicio que difumina la conexión entre la dirección emisora y la receptora en la cadena y dificulta así el seguimiento.

A partir de ese capital inicial, el atacante fue acumulando peso de voto paso a paso hasta alcanzar las mayorías descritas. Ahí reside precisamente la lección incómoda del caso: el coste de una toma de control se mide por el precio de los derechos de voto necesarios y apenas por el tamaño de la bóveda. Si esos derechos son baratos o están poco repartidos, una apuesta pequeña puede decidir sobre un patrimonio grande.

Código auditado, bóveda vacía: por qué una auditoría no frena un ataque de gobernanza

Una auditoría es el examen del código por parte de una firma especializada. En ella se comprueba si el código hace lo que debe hacer y si puede inducírsele a un comportamiento imprevisto. Sobre este caso, Cryptobriefing deja constancia de que la operación pasó por contratos auditados sin romper una sola línea de código.

No es un reproche a los auditores, sino una afirmación sobre el alcance de un examen así. Una auditoría responde a la pregunta de si el código trabaja correctamente. No responde a la de si el reparto de los derechos de voto permite un acceso hostil. Cryptobriefing clasifica por ello la debilidad como arquitectónica y la sitúa en la combinación de distribución de tokens, baja participación en las votaciones y ausencia de límites de acceso en la administración de las bóvedas.

Para ti esto significa que el sello de un informe de auditoría dice algo sobre el código y nada sobre cómo se reparte el poder en un protocolo. Si utilizas productos de préstamo DeFi, merece la pena mirar ambas cosas antes de depositar. Qué proveedores hay en este campo y en qué se diferencian lo muestra nuestra comparativa de plataformas de préstamos cripto.

Timelock: por qué el retardo entre acuerdo y ejecución resulta decisivo

Un timelock es un tiempo de espera incorporado entre el momento en que un acuerdo alcanza la mayoría y aquel en que se ejecuta realmente. Durante ese intervalo cualquiera puede leer el acuerdo en claro. Quien no quiera dejar su saldo en una bóveda sobre la que se acaba de acordar algo desfavorable puede retirarlo.

El timelock es así la única salvaguarda que sigue actuando cuando la votación ya se ha perdido. No impide la toma de control. Impide que acuerdo y salida de fondos coincidan en el mismo segundo.

El efecto de un timelock ausente puede leerse con detalle en un segundo caso. Si Term Finance había previsto un plazo de ese tipo, y de qué duración en su caso, no se desprende de las exposiciones publicadas hasta ahora. Dejo constancia, por tanto, de este punto como abierto y no como acreditado.

Token of Power: cómo la misma secuencia ya funcionó en junio de 2026

El caso Token of Power, TOP en abreviatura, es el gemelo mejor documentado de este patrón de ataque. TRM Labs y Blockaid lo han analizado y sus descripciones coinciden en los puntos que sostienen el relato.

TOP era un token de voto sobre Ethereum montado sobre Aragon, con una oferta total de apenas 16.384 unidades. Aragon es un conjunto de herramientas con el que se componen las reglas de votación de un protocolo. Según ese análisis, el atacante adquirió algo más de la mitad de la oferta total y utilizó después la función de votación para presentar, aprobar y ejecutar una propuesta en una sola transacción. Entre medias no hubo tiempo de espera alguno.

El acuerdo mismo acuñó diez mil millones de TOP nuevos a favor del atacante. Esa cantidad se volcó en un fondo de liquidez y allí se convirtió en 944,2 WETH, cifrados entre 1,5 y 1,6 millones de dólares según la fuente que se tome. Los análisis señalan un conjunto de causas: la minúscula oferta total original, la falta de tiempo de espera, la ausencia de un límite máximo para la emisión de nuevos tokens y unas salvaguardas demasiado débiles en la configuración de la votación.

El paralelismo con Term Finance está en la secuencia, menos en los detalles. En ambos casos se compró peso de voto, en ambos se financió a través de un servicio de ocultación del origen y en ambos la operación terminó con un acuerdo conforme a las reglas a costa de los depositantes.

Siete tomas de control en tres cadenas: qué muestra el recuento de Blockaid

Que se trata de un patrón y no de dos casos aislados puede cuantificarse. El proveedor de seguridad Blockaid contabilizó siete tomas de control por gobernanza en tres cadenas para el periodo de junio a principios de agosto de 2026 y cifró en su análisis el daño total en unos 22 millones de dólares. El análisis es de acceso público.

También en nuestro archivo hay un caso así. El 7 de julio de 2026 informamos sobre un ataque de gobernanza contra la BONK DAO, en el que estaba en juego una caja común de dos dígitos de millones. Ese dato procede de nuestra propia cobertura de aquel día y no constituye aquí una prueba independiente, sino una referencia a los antecedentes.

El mes en curso ha sido movido de todos modos. Antes de la salida de fondos en Term Finance, el servicio de datos DefiLlama había registrado ya para agosto de 2026 diecisiete incidentes de seguridad con un daño de unos 18,8 millones de dólares.

Comprobar el riesgo de gobernanza: las cinco preguntas que resuelves antes de cada depósito

Los puntos siguientes pueden consultarse en la documentación de un protocolo o en su página de gobernanza. Cuestan unos pocos minutos y responden a con qué facilidad puede abrirse una bóveda mediante una votación.

¿Quién puede votar y cómo se reparte el peso de voto? Si la oferta total del token de voto es pequeña o una parte grande está en pocas direcciones, una mayoría sale barata. En TOP bastó algo más de la mitad de una oferta total de solo 16.384 tokens.

¿Hay un tiempo de espera entre acuerdo y ejecución? Si no encuentras ninguna indicación sobre un timelock, parte de que no lo hay. Sin ese plazo no te queda ocasión de retirar tu saldo cuando llegue el momento.

¿Puede una votación mover saldos directamente? Algunos protocolos solo permiten modificar parámetros por acuerdo, como tipos de interés o límites máximos. Otros permiten la salida de depósitos hacia una dirección cualquiera. El segundo caso es el peligroso.

¿Existe un límite máximo para la emisión de nuevos tokens? Si falta, una mayoría puede ampliarse a voluntad por acuerdo, o diluirse la oferta. En el caso TOP esa fue la palanca verdadera.

¿Cuál fue la participación en las últimas votaciones? Una participación baja rebaja considerablemente el umbral de una toma de control, porque el atacante solo tiene que superar los votos efectivamente emitidos.

Lo que esta comprobación no consigue

No te protege de un ataque, solo te muestra lo caro que resultaría. Un protocolo con derechos de voto ampliamente repartidos y un tiempo de espera de varios días es bastante más difícil de tomar que uno sin ninguna de las dos cosas. Un riesgo residual queda en cualquier caso.

Revocar las autorizaciones de tokens: por qué sirve de poco frente a un ataque de gobernanza

Tras un incidente en el mundo DeFi, el consejo estándar es revocar las autorizaciones de tokens concedidas. Una autorización es el permiso que das a un contrato para disponer de una determinada cantidad de tus tokens. Es un reflejo sensato y deberías conservarlo.

Frente a este tipo de ataque, sin embargo, solo llega hasta cierto punto. En un ataque de gobernanza no se vacía tu monedero, sino la bóveda en la que ya has ingresado. De ese saldo dispone el protocolo con normalidad de todos modos; el acuerdo solo cambia su destino. Revocar una autorización impide accesos futuros a tu monedero y no recupera un saldo ya depositado.

Lo que resulta eficaz en esta situación es únicamente la retirada de la bóveda afectada, y esa sigue siendo posible justo cuando un tiempo de espera lo permite. Con ello se cierra el círculo sobre el timelock.

Pérdida tras un exploit DeFi: qué conviene documentar para tu expediente fiscal

Si un incidente así te alcanza, la documentación es lo primero que puedes resolver y lo único que después no se recupera. Anota cuándo depositaste, en qué bóveda y por qué importe, y guarda los justificantes de transacción de la cadena junto con las comunicaciones fechadas del proveedor.

Cómo debe tratarse fiscalmente una pérdida de este tipo es una cuestión del caso concreto y en parte discutida. Corresponde a tu asesor fiscal y no a un artículo; cualquier afirmación general sería aquí poco seria. Lo que tú puedes aportar es una relación sin lagunas. Las herramientas que reúnen transacciones de varios monederos te ahorran en buena medida ese trabajo.

Term Finance en mayo de 2025: por qué el incidente anterior era de otra naturaleza

Term Finance ya había registrado una pérdida en mayo de 2025. Según la exposición de Cryptobriefing, entonces se perdieron unos 1,5 millones de dólares por un decimal mal colocado en un servicio de datos de precios durante una actualización rutinaria. Aquel error no fue malintencionado y los fondos acabaron devolviéndose, según esa misma exposición.

La diferencia con el caso actual es esencial para la valoración. Un error interno se corrige y la otra parte está localizable. En el incidente del 23 de agosto, en cambio, al otro lado hay un actor externo que obtuvo su capital inicial a través de un servicio de ocultación. Cryptobriefing califica en consecuencia de inciertas las perspectivas de recuperar los fondos para los depositantes afectados.

Exploit de gobernanza en Term Finance: qué está acreditado y qué queda abierto

Está acreditada la secuencia en sus rasgos generales: el importe de la salida, unos 2.843 ETH y cerca de 1,6 millones de DAI, el reparto de votos en las bóvedas afectadas, la dirección receptora, el origen del capital inicial y la confirmación por parte de Term Labs, CertiK y PeckShield. Estos datos proceden de la exposición de Cryptobriefing del 23 de agosto de 2026, que coincide con la cobertura de CoinDesk y BeInCrypto sobre los mismos hechos.

Queda abierto más de lo que un titular deja suponer. No existe un desglose de qué bóveda perdió qué fondos ni de cuántos depositantes están afectados. Si se había previsto un tiempo de espera entre acuerdo y ejecución, y de qué duración, no se ha publicado. Nada se sabe sobre una indemnización, y tampoco nada sobre la identidad del atacante. Term Labs ha anunciado una exposición más detallada; hasta entonces, cualquier afirmación sobre responsabilidades es especulación, y aquí no sostenemos ninguna.

Límites de esta exposición

Este texto se apoya en informes de acceso público y en los análisis de Blockaid y TRM Labs. No hemos realizado un análisis propio de los datos de la cadena. Las indicaciones de precio en el momento de la salida de fondos proceden de las fuentes citadas y pueden haber variado desde entonces.

Comprobar el riesgo de gobernanza: qué te llevas de todo esto

1. Mira quién puede votar sobre tu bóveda de depósito. Antes de entregar saldo a un producto de préstamo DeFi, resuelve las cinco preguntas anteriores, ante todo la del tiempo de espera entre acuerdo y ejecución. Una panorámica de los proveedores de este campo la ofrece nuestra comparativa de préstamos cripto.
2. Separa lo que reposa de lo que trabaja. Los fondos que mantienes a largo plazo no deben estar en una bóveda que una votación pueda abrir. Para la custodia fuera del poder de disposición ajeno ayuda nuestra comparativa de carteras de hardware. Quien prefiera quedarse en una plataforma supervisada está mejor con un proveedor autorizado que en una bóveda cuyo uso decide una votación.
3. Documenta de inmediato si un incidente te alcanza. Guarda los justificantes de ingreso, los datos de transacción y las comunicaciones fechadas del proveedor antes de que se desconecten las interfaces. Una herramienta de nuestra comparativa de software fiscal cripto y rastreadores de cartera reúne tus transacciones de varios monederos.

(23 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)