CashAddr OOB: qué pasó en Bitcoin ABC y por qué Tonalli Wallet no quedó afectada

El 28 de agosto, el desarrollador conocido como roqqit hizo pública una vulnerabilidad de severidad media relacionada con cashaddr::Decode(). El problema afectaba a una implementación nativa de CashAddr utilizada por software derivado del código de Bitcoin ABC: una entrada suficientemente corta podía atravesar parte de la validación y terminar en una operación de iteradores fuera de un rango válido.

La historia importante no es solamente que existiera un bug. También importa cómo fue tratado: Bitcoin ABC recibió el reporte, probó el caso relacionado y publicó una corrección antes de la divulgación pública. El commit de reparación identificado en la revisión es 8b31fb4780c6e02995214ab30e378aeb892e2904, incorporado en Bitcoin ABC 0.33.10 el 11 de agosto de 2026.

Qué fallaba exactamente

CashAddr incluye un checksum de ocho símbolos. Según la divulgación y el parche revisado, el decoder C++ podía llegar a una resta fija de iteradores sin haber demostrado primero que el vector decodificado contenía esos ocho elementos. Para ciertos inputs demasiado cortos, eso podía producir un rango inválido y terminar en excepción o crash.

La corrección añadió la condición que faltaba antes de operar sobre ese rango. Bitcoin Cash Node, que heredaba la misma familia de implementación nativa, también realizó un backport del arreglo.

Esto es distinto de otro hallazgo relacionado reportado en el firmware de Trezor. Allí se observó un IndexError en un decoder escrito en Python. El propio investigador señaló que no veía una vulnerabilidad aparente en el firmware de Trezor. Ambos casos comparten contexto de validación de CashAddr, pero no deben presentarse como el mismo fallo.

¿Y Tonalli Wallet?

La aparición de una vulnerabilidad en software eCash justificaba revisar Tonalli Wallet, pero no justificaba asumir exposición. xolosArmy ejecutó una calificación defensiva sobre el baseline bloqueado de RMZWallet/Tonalli Wallet, preservando main, el lockfile y las versiones exactas de dependencias.

El resultado fue NOT AFFECTED para esta vulnerabilidad concreta.

La diferencia de lenguaje por sí sola no habría sido suficiente para cerrar el análisis. La revisión siguió el linaje del código, el grafo de dependencias y las rutas reales de importación. El flujo relevante de Tonalli Wallet termina en ecashaddrjs.decodeCashAddress(), una implementación independiente que llegó al monorepo de Bitcoin ABC años después de que existiera la implementación C++ afectada.

En otras palabras: ambos componentes implementan el mismo formato de direcciones, pero no ejecutan la misma función vulnerable.

Por qué “npm install y ya” habría sido una mala respuesta

En seguridad de supply chain, actualizar por reflejo puede crear tanto ruido como claridad. Un npm install genérico no demuestra que una vulnerabilidad haya sido corregida, y puede incluso modificar el árbol de dependencias sin relación con el problema investigado.

La revisión hizo lo contrario: primero identificó el código afectado, después inventarió las dependencias exactas y sólo materializó el entorno con npm ci, conservando el lockfile. Ese orden permite responder una pregunta verificable: ¿el baseline actual ejecuta el código vulnerable?

Para Tonalli Wallet, la respuesta fue no.

ecashaddrjs 2.0.1: hardening, no parche de esta OOB

El 28 de agosto también se publicó ecashaddrjs@2.0.1 con una comprobación más temprana de la longitud correspondiente a los ocho símbolos del checksum. Ese cambio mejora el orden defensivo de validación y merece una evaluación normal de dependencia.

Pero confundirlo con el parche obligatorio de la OOB nativa sería impreciso. La revisión encontró que la versión 2.0.0 usada por Tonalli no entra en la ruta C++ fuera de límites; su lógica termina rechazando el caso posteriormente por una validación de tamaño. Por eso, una posible actualización a 2.0.1 debe tratarse como defense in depth, no como evidencia de que Tonalli Wallet estuviera explotablemente afectada por el bug divulgado.

El contexto más amplio para eCash

Este incidente muestra una propiedad saludable del software abierto: una vulnerabilidad encontrada en una implementación puede convertirse en una señal para que todo un ecosistema revise sus propios límites de confianza. La divulgación pública permitió que proyectos downstream dejaran de discutir por asociación de marca y pasaran a revisar identidad de código, versiones y rutas de ejecución.

También muestra por qué Bitcoin ABC ocupa una posición importante en la seguridad del ecosistema eCash. La corrección previa a la divulgación redujo la ventana de exposición para operadores que mantienen software actualizado. Al mismo tiempo, proyectos independientes como wallets, SDKs y servicios necesitan realizar su propia calificación en vez de asumir que todos comparten la misma superficie de ataque.

Para xolosArmy Network, este caso encaja con la línea de trabajo de Tonalli Shield: seguridad basada en evidencia reproducible, procedencia de código, dependencias bloqueadas, pruebas enfocadas y gates que separan “afectado”, “no afectado” e “inconcluso” antes de modificar software.

Lo que todavía falta revisar

El veredicto de Tonalli Wallet no debe extrapolarse automáticamente a Tonalli Core ni a un fork nativo de eCash. Allí la relación con el código C++ de Bitcoin ABC puede ser directa y la pregunta cambia: hay que comprobar si el baseline incorpora el commit de reparación o un cambio equivalente.

Ese es precisamente el valor de separar componentes. “Tonalli” no es una sola superficie técnica: wallet, librerías JavaScript, Core nativo y servicios asociados pueden tener procedencias y modelos de riesgo distintos.