✨︎ Resumen (TL;DR):
- Bitcoin Core publicará cuanto antes los parches y avisos de vulnerabilidades fáciles de descubrir, incluidas las que una consulta sencilla a un modelo de IA puede detectar.
- Bitcoin Core integró el cambio el 22 de octubre de 2026 y aplicará la corrección a cada rama principal que siga bajo mantenimiento.
- Al 23 de octubre de 2026, las ramas mantenidas son 31.x, 30.x y 29.x; la 28.x llegó al fin de soporte el 19 de abril.
Bitcoin Core cambió su política de seguridad para publicar cuanto antes los parches de vulnerabilidades fáciles de descubrir junto con sus avisos de seguridad, incluidas las que una consulta sencilla a un modelo de IA puede detectar. El proyecto aplicará las correcciones a cada rama principal bajo mantenimiento, porque los modelos de lenguaje reducen el esfuerzo para redescubrir ciertos fallos.
El desarrollador Antoine Poinsot propuso la modificación y Bitcoin Core la integró el 22 de octubre de 2026. La etiqueta de fácil descubrimiento también cubre fallos hallados sin IA.
Un modelo de lenguaje es un sistema de IA que, según Poinsot, puede reducir el esfuerzo para hallar ciertos errores o identificar una corrección discreta.
La vía rápida es un procedimiento de divulgación que publica el aviso junto con las versiones corregidas, lo antes posible, cuando una vulnerabilidad es fácil de descubrir.
La IA acorta el valor del embargo
Poinsot atribuyó buena parte del aumento de reportes fáciles de redescubrir a los modelos de lenguaje. Según su explicación, estos modelos reducen el esfuerzo para hallar ciertos errores o identificar una corrección discreta.
Los embargos buscaban dar tiempo para actualizar antes de revelar los detalles. Sin embargo, también dificultaban trasladar los arreglos a versiones anteriores, explicó el desarrollador.
Antoine Poinsot escribió sobre estos fallos: “El periodo de embargo logra poco, pero retrasa la disponibilidad de una versión corregida”.
Poinsot reconoció que los arreglos pasarán menos tiempo en las ramas de desarrollo antes de publicarse. Defendió acompañarlos con detalles para que cada operador pueda evaluar si está afectado.
Qué ramas recibirán las correcciones
Según el calendario oficial, al 23 de octubre de 2026, Bitcoin Core mantiene las tres ramas principales más recientes: 31.x, 30.x y 29.x. La rama 28.x llegó al fin de soporte el 19 de abril.
Bitcoin Core entregará una actualización de mantenimiento con el arreglo a cada rama que siga bajo soporte. Quienes usen una versión principal anterior que todavía tenga mantenimiento podrán obtenerlo sin esperar al siguiente lanzamiento mayor.
Las ramas fuera de soporte generalmente dejan de recibir parches de seguridad. El proyecto advierte que trasladar cambios a versiones anteriores también depende de la disponibilidad de voluntarios.
Bitcoin Core recomienda ejecutar la actualización de mantenimiento más reciente de la versión principal más nueva a la que cada operador pueda migrar.
La gravedad conserva sus propios plazos
La facilidad para descubrir una vulnerabilidad se evalúa por separado de su gravedad. Los fallos que no entran en la vía rápida conservan plazos ligados a su gravedad y al estado de soporte de la versión.
- Fácil de descubrir, bajo la vía rápida: Bitcoin Core publica el aviso junto con las versiones corregidas, lo antes posible.
- Gravedad baja, fuera de la vía rápida: Bitcoin Core publica el aviso dos semanas después del lanzamiento de una versión principal con la corrección.
- Gravedad media o alta, fuera de la vía rápida: Bitcoin Core publica el aviso dos semanas después del fin de soporte de la última versión afectada.
- Gravedad crítica: el caso queda fuera del calendario estándar y puede seguir un procedimiento específico.
Para las vulnerabilidades de gravedad media o alta sujetas a embargo, el proyecto sitúa la divulgación aproximadamente un año después del primer lanzamiento principal con la corrección.
La nueva política cambia el tratamiento de los fallos que resultan fáciles de redescubrir: esperar puede retrasar la disponibilidad de un parche para versiones anteriores. El costo que Poinsot reconoce es que la corrección pasa menos tiempo en las ramas de desarrollo antes de publicarse.
Por eso, los operadores deben mantener la actualización de mantenimiento más reciente de la versión principal más nueva a la que puedan migrar y revisar los detalles del aviso para determinar si están afectados.
