Miles de nodos de Bitcoin permitieron que extraños anónimos superaran los límites de seguridad.

**Cambios en el proceso de verificación de confianza:** - **Antes de la corrección**: La lista blanca se utilizaba para determinar los nodos remotos confiables. - **Después de la corrección**: La lista blanca se actualiza para evitar errores en la asignación de permisos. - Las conexiones entrantes de tipo “onion” ignoran la comparación basada en la dirección IP, evitando así errores en la asignación de permisos. **Conclusión:** La corrección de estos errores ha mejorado la seguridad de las conexiones de tipo “onion”, asegurando que solo los nodos confiables reciban permisos.

Se omite la comprobación de que la dirección de la conexión “onion” sea válida. No se otorgan privilegios según esta regla. La IP del daemon no puede conceder confianza. El parche excluye las conexiones “onion” entrantes de las autorizaciones basadas en listas blancas de direcciones. Antes de la corrección, era necesario utilizar una versión vulnerable de Bitcoin Core y una lista blanca no predeterminada que coincidiera con la dirección del daemon Tor. El cambio afecta únicamente los permisos basados en listas blancas, no todos los posibles permisos entre pares. Las fuentes y pruebas de este problema provienen de la divulgación de información sobre Bitcoin Core (versión 33395). En las versiones vulnerables de Bitcoin Core, la vulnerabilidad afectaba a los nodos cuyo rango de IP de la lista blanca no predeterminada coincidía con la dirección del daemon Tor. Para las conexiones Tor entrantes, Bitcoin Core utiliza la dirección IP del daemon Tor (generalmente en la misma máquina o red local), en lugar de la dirección real de la red del peer remoto. El ajuste de la lista blanca exime a los pares de confianza de ciertas restricciones y medidas de protección de la privacidad; sin embargo, al coincidir con la dirección del daemon Tor, estos privilegios se extendían erróneamente a los pares Tor entrantes. El parche impide que los permisos basados en listas blancas se apliquen a las conexiones “onion” entrantes, ya que las direcciones de red de los pares remotos no se revelan.Los marcadores de pares ilustran múltiples conexiones remotas y no codifican ningún tipo de información sobre su cantidad o escala. El estado previo a la corrección requería una versión del software vulnerable, así como una lista blanca no predeterminada que coincidiera con los parámetros del daemon Tor. El cambio afecta únicamente los permisos basados en la dirección de los pares, no todos los permisos posibles relacionados con los pares en la red. Esa distinción es importante porque las listas blancas eliminan varias restricciones diseñadas para prevenir ataques de tipo “denial of service” (negación de servicio), así como medidas de protección contra fugas de datos personales. El problema radicaba en las exenciones otorgadas a los pares de la red; los privilegios descritos en los documentos técnicos no implican acceso a billeteras digitales ni robos de monedas. La corrección de privacidad de Bitcoin Core ya ha alcanzado la versión 32, mientras que el parche de la versión 31 sigue estando disponible para su aplicación. Algunos softwares clientes también necesitaban utilizar listas blancas y, por lo general, se ejecutaban junto con Tor; estas configuraciones hicieron que miles de nodos de la red principal aceptaran automáticamente todas las conexiones provenientes de Tor. Martin Zumsande y Antoine Poinsot informaron sobre este problema en septiembre de 2025; el parche correspondiente se aplicó el 17 de septiembre, eliminando así los permisos basados en la dirección de los pares para las conexiones provenientes de Tor. Las versiones 30.0, 29.2 y 28.3 de Bitcoin Core incluyeron esta corrección en octubre de 2025.La solución ya está disponible en todas las versiones a partir de la 30.0, así como en las versiones menores posteriores de las ramas 28.x y 29.x.

¿Qué deben verificar ahora los operadores de nodos?

Esos umbrales de actualización antiguos son diferentes de las guías de actualización actuales. El calendario de mantenimiento de Bitcoin Core ahora cubre las versiones 30.x, 31.x y 32.x; las versiones 28.x y 29.x han llegado al final de su ciclo de vida. El proyecto recomienda adoptar la última versión de mantenimiento de la versión principal disponible. Su página de descarga indica que la versión 32.1 es la más reciente (a fecha del 11 de noviembre).

Para los operadores que utilizan software de nodos empaquetado, verifiquen qué versión de Bitcoin Core está en ejecución y si su lista blanca incluye la dirección del daemon Tor.