En las criptomonedas existe una fórmula casi sagrada: "No confíes, verifica." Cada usuario puede ejecutar su propio nodo, comprobar las reglas de la red por sí mismo y no depender ni del equipo de desarrollo ni de ninguna autoridad central.
Pero esta fórmula tiene una limitación seria. Por mucho que audite el código con cuidado, no voy a detectar una vulnerabilidad que hace falta un hacker experimentado para encontrar: simplemente no tengo la pericia. Así que me veo obligado a confiar de todos modos: a confiar en las personas que revisan todo en mi nombre y me dicen lo que encuentran.
El 5 de mayo de 2026, los desarrolladores de Bitcoin Core divulgaron la vulnerabilidad CVE-2024-52911. Afectaba a las versiones de Bitcoin Core desde la 0.14.0 en adelante y se corrigió en la 29.0. El fallo permitía a un minero provocar de forma remota la caída de los nodos de otras personas.
Pero el detalle más llamativo aquí es cuánto tiempo había estado conocida esta vulnerabilidad. Cory Fields la reportó en privado a los desarrolladores el 2 de noviembre de 2024. Para el 6 de noviembre de 2024, Pieter Wuille comprometió una corrección oculta. El 3 de diciembre de 2024, el parche apareció en el repositorio oficial sin ningún anuncio público y fue descrito simplemente como "actualizaciones menores." El 12 de abril de 2025, Bitcoin Core 29.0 se lanzó con la corrección incluida. La divulgación pública llegó solo el 5 de mayo de 2026, después de que la última rama vulnerable, la 28.x, alcanzara su fin de soporte.
Durante un año y medio, el cliente de Bitcoin más ampliamente confiado funcionó con una vulnerabilidad que los desarrolladores conocían —mientras que los operadores de nodos que ejecutaban ese software no lo sabían. Y esto no es un incidente aislado; es un patrón recurrente en las criptomonedas. Desarrolladores de distintos proyectos cripto han estado haciendo esto durante años.
Quiero repasar otros ejemplos de lo mismo y, en última instancia, responder a la pregunta: ¿qué tan seguro es, realmente, mantener tus ahorros en criptomonedas?
Bitcoin: Cómo un bug de DoS resultó ser un bug de inflación
En septiembre de 2018, Bitcoin Core apresuró el lanzamiento de la versión 0.16.3. A los usuarios se les dijo que parcheaba una vulnerabilidad de denegación de servicio.
Dos días después, resultó que eso era solo la mitad de la historia. El mismo fallo en las versiones 0.15.x y 0.16.x podía permitir a un minero inflar la oferta de bitcoin —efectivamente gastando la misma salida dos veces dentro de un solo bloque y embolsándose BTC extra. Los desarrolladores reconocieron que inicialmente habían divulgado solo el componente menos peligroso de DoS, reteniendo deliberadamente la descripción completa de la amenaza de inflación para dar tiempo a mineros, empresas y otros participantes críticos a actualizarse.
En el peor de los casos, esto habría sido un ataque no contra ninguna cartera individual, sino contra la promesa central de Bitcoin: una oferta fija. Si la regla de los 21 millones puede romperse por un bug en el cliente, toda la mitología económica de Bitcoin se desmorona.
La vulnerabilidad nunca fue explotada. Pero CVE-2018-17144 ilustra perfectamente el dilema ético. Por un lado, la divulgación completa e inmediata podría haber entregado a los atacantes un manual listo para usar. Por otro lado, los usuarios efectivamente no fueron informados de la verdad sobre cuán crítica era la actualización.
Zcash: Monedas falsificadas invisibles
La historia de Zcash fue aún más inquietante, porque se trata de una moneda de privacidad donde no todo es visible en la cadena de bloques. En 2018, el equipo descubrió una vulnerabilidad en la criptografía subyacente de sus pruebas de conocimiento cero. Antes de que se corrigiera, un atacante podría haber creado ZEC falsos de una manera que nadie habría sido capaz de detectar. Con una cadena transparente, un bug de inflación es al menos teóricamente visible mediante análisis de saldos; un sistema de privacidad hace que ese tipo de verificación sea mucho más difícil.
Zcash solucionó el problema en la actualización Sapling, activada el 28 de octubre de 2018, y lo divulgó públicamente solo meses después. En la divulgación oficial, el equipo escribió sin rodeos: "hace once meses descubrimos una vulnerabilidad" —y reconoció que, antes del parche, un atacante podría haber acuñado Zcash falsos sin detección.
La justificación para el silencio aquí es fácil de entender. Divulgar este fallo antes de parchearlo habría sido dar a alguien una receta para destruir Zcash. Pero la otra cara es igual de clara: durante casi un año, los usuarios poseyeron un activo en el que la falsificación invisible era teóricamente posible —y no tenían ni idea.
Esto apunta a una paradoja real:
- Cuanto más grave es la vulnerabilidad, más fuerte es el argumento a favor del secreto.
- Pero cuanto mayor es el secreto, más socava la idea de verificabilidad. (¿De qué sirve "verificar todo" si me faltan las habilidades para entender lo que veo, y los auditores calificados no me dicen lo que han encontrado?)
Monero: La verdad oculta tras un DoS inexistente
En 2017, Monero se enfrentó a una amenaza similar. El equipo descubrió un bug crítico en CryptoNote, el protocolo base que impulsa Monero y varias otras monedas de privacidad. La vulnerabilidad permitía la creación de un número ilimitado de monedas de una manera que habría sido invisible para cualquier observador que no supiera exactamente qué buscar.
El parche en Monero fue introducido de forma encubierta. Además, la publicación pública se explicó como protección contra un ataque de denegación de servicio de RingCT —uno que, según la propia posterior admisión del equipo, en realidad nunca existió. Fue una historia de cobertura, construida para lograr que intercambios y pools de minería actualizaran sin revelar el verdadero riesgo inflacionario.
Para Monero, la historia terminó bien: el equipo informó que había revisado la cadena de bloques y no encontró signos de explotación. Pero la vulnerabilidad se extendía más allá de Monero. Después de que Monero se actualizara, el equipo comenzó a notificar a otros proyectos basados en CryptoNote. Pero uno de ellos, Bytecoin, fue pronto atacado, y se crearon 693 millones de monedas adicionales en él.
Esto abre otra capa del problema de mantener vulnerabilidades en secreto. Cuando el código se comparte entre docenas de proyectos, anunciar una amenaza descubierta en un lugar puede convertirse en una pista para atacantes que apuntan a otro. Los desarrolladores deben decidir no solo cuándo avisar a sus propios usuarios, sino a qué proyectos competidores advertir, y en qué orden —sabiendo que un competidor que reciba la información primero podría potencialmente usarla contra otro que aún no la haya recibido.
Monero otra vez: El bug que permitía a atacantes quemar el dinero de otros
En 2018, Monero enfrentó otro incidente diferente, menos fundamental —pero muy instructivo— conocido como el burning bug. No permitía a nadie imprimir XMR de la nada ni romper el calendario de suministro. Pero sí permitía a un atacante causar daño financiero real a intercambios, comerciantes y otros servicios. El bug hacía posible enviar fondos de tal manera que algunas de las salidas recibidas se volvían intransitables.
Un servicio de intercambio como rabbit.io podría haber sido vulnerable a tal ataque.
Así es como funcionan los swaps de criptomonedas en rabbit.io:
- un usuario envía criptomoneda, por ejemplo XMR, a la dirección de depósito mostrada en el formulario de pedido;
- nuestro sistema automatizado detecta el pago entrante y envía la criptomoneda solicitada a la dirección de pago especificada por el usuario.
Nuestro servicio no existía en ese momento, pero de haber existido, el ataque podría haber sido así:
- un atacante crea un pedido para intercambiar XMR por BTC;
- el atacante envía XMR y recibe BTC;
- nos quedamos sin BTC ni XMR porque las salidas de XMR recibidas son inutilizables;
- el atacante no obtiene nada directamente, pero destruye los negocios que aceptan XMR.
El equipo de Monero preparó un parche silencioso y notificó directamente a los intercambios y a los comerciantes conocidos de XMR a los que pudieron llegar. En el informe post-mortem, los desarrolladores reconocieron con honestidad que este enfoque inevitablemente dejaba fuera a organizaciones con las que no tenían contacto y creaba la impresión de acceso privilegiado a la información.
Esta es la realidad práctica de la divulgación selectiva: algunos participantes del mercado siempre conocerán un riesgo antes que otros. Esa asimetría es en sí misma un problema de seguridad.
Stellar: Un bug oculto que ya había sido explotado
La historia de Stellar difiere de la mayoría de las demás porque el bug no estaba solo presente en silencio, desconocido para cualquiera salvo los desarrolladores. Ya había sido utilizado.
En 2017, un atacante explotó un fallo de concurrencia en el protocolo Stellar y creó 2.25 mil millones de XLM —aproximadamente 10 millones de dólares en ese momento, y cerca de una cuarta parte de todos los tokens en circulación. Según Messari, el XLM recién acuñado se transfirió a intercambios y presumiblemente se vendió.
La Stellar Development Foundation posteriormente quemó una cantidad equivalente de XLM de sus propias reservas para evitar la dilución de la oferta. Pero no hizo ningún anuncio público —hasta que Messari sacó a la luz el incidente en 2019, dos años después. En respuesta, los representantes de Stellar dijeron que habían mencionado el bug en las notas de la actualización del protocolo. Técnicamente, eso no es un silencio completo. Pero una entrada discreta en las notas técnicas de la versión que el mercado no conoció hasta una investigación de Messari dos años después es, en la práctica, silencio.
Este caso es particularmente incómodo para la industria. No puedes decir: "Mantenemos la vulnerabilidad en secreto para que nadie pueda explotarla." Alguien ya la había explotado. El silencio protegió no a los usuarios de un ataque, sino a los desarrolladores de un escrutinio.
Ethereum Geth: Cómo un parche silencioso dividió la red
En Geth, el cliente de Ethereum más utilizado, la práctica del parche silencioso se formalizó en esencia. La documentación del equipo establece explícitamente que para vulnerabilidades que amenacen la salud de la mainnet de Ethereum, se reserva el derecho de enviar correcciones silenciosamente en nuevas versiones sin divulgar las vulnerabilidades en sí. La lógica es simple: los operadores de nodos pueden pasar semanas o meses sin actualizar, y si detallas exactamente qué bug corrige una versión, alguien puede intentar explotarlo más rápido de lo que la mayoría de los nodos puede actualizarse.
Pero en agosto de 2021, esta lógica se volvió en su contra. Geth parcheó CVE-2021-39137, lanzando la corrección el 24 de agosto sin divulgar detalles. Alguien, sin embargo, descubrió qué se había arreglado —y el 27 de agosto, la vulnerabilidad fue explotada, provocando que una porción de nodos Geth antiguos se bifurcara fuera de la cadena principal.
Este es el otro filo de la navaja del secreto. Dices demasiado y puedes acelerar un ataque. Dices muy poco y algunos operadores no entenderán que actualizar es urgente. La red puede acabar exactamente con lo que intentaba evitar: explotación activa de la vulnerabilidad.
Polygon: $24 mil millones en riesgo, pérdidas reales incurridas
En diciembre de 2021, Polygon afrontó el mismo dilema. Investigadores de seguridad informaron de una vulnerabilidad crítica en el contrato génesis de Polygon PoS —una que podría permitir a un atacante drenar aproximadamente 24.000 millones de dólares en tokens MATIC. El equipo decidió proceder en silencio: como dijeron después, "dada la naturaleza de esta actualización, debía ejecutarse sin llamar demasiado la atención." Los validadores y operadores de nodos completos fueron notificados, y la red se actualizó rápidamente.
Pero incluso una respuesta rápida no fue lo bastante veloz para cerrar la ventana por completo. Antes de que la actualización entrara en vigor, un atacante logró robar 801,601 MATIC —poco menos de 2 millones de dólares. Los desarrolladores confirmaron que la Polygon Foundation cubriría la pérdida. Los investigadores que habían reportado la vulnerabilidad fueron pagados aproximadamente 3.46 millones de dólares en recompensas de bug bounty.
El equipo no intentó enterrar el problema, pero los usuarios conocieron la escala completa de lo que casi ocurrió solo después de que todo terminara. Dos razones impulsaron el enfoque: primero, la prioridad era actuar, no deliberar; segundo, antes de que se resolviera el problema, cada persona adicional que lo supiera era alguien que potencialmente podría abusar de ese conocimiento.
Quizá esto sea lo que parece un compromiso razonable: no divulgar un ataque antes de parchearlo, pero tampoco convertir la corrección en un secreto que dure meses o años.
¿Están los desarrolladores protegiendo a los usuarios o engañándolos?
A veces el secreto realmente salva a la red. Sin una corrección silenciosa, Zcash podría haber sufrido inflación invisible. Sin un parche encubierto, Monero podría haber enfrentado falsificación indetectable. Sin la rápida acción a puertas cerradas de Polygon, el daño potencial a esa red habría sido incomparablemente mayor.
Pero el secreto no es gratis. Crea niveles de insiders y outsiders. Da ventaja a quien el equipo logra advertir en privado. Reduce la urgencia de los operadores de nodos para actualizar cuando una versión parece mantenimiento rutinario. Y socava una de las bases psicológicas más importantes de usar criptomonedas: la sensación de que las reglas del juego son conocidas por todos al mismo tiempo.
Esa sensación, resulta, es una ilusión. Cada una de estas historias sigue el mismo arco: un parche silencioso, un largo silencio y luego la admisión de que todo el tiempo la seguridad de la red había descansado en la confianza hacia un pequeño grupo de personas que sabían más que todos los demás.
