Braiins alerta: firmware reciente de Bitmain puede limitar software de terceros
Publicación de la fuente: 2026-09-18 · Análisis editorial publicado: 2026-09-20
El aviso del 18 de septiembre procede de un proveedor y no demuestra que todos los modelos estén afectados. Proponemos un proceso seguro mientras continúa la investigación.
Análisis e implicaciones prácticas
Esta sección contiene nuestro análisis y cálculos ilustrativos, separados del informe original.
Qué publicó exactamente Braiins
El 18 de septiembre de 2026, Braiins publicó un aviso operativo pidiendo no actualizar el firmware de fábrica de Bitmain a la versión más reciente. Afirmó que algunas versiones recientes podrían restringir la instalación de firmware de terceros y recomendó a quienes ya usan Braiins OS en un S21 no volver a la imagen stock más nueva. También indicó que seguía investigando. Es una advertencia de un proveedor alternativo, no un boletín de Bitmain, una lista completa de modelos afectados ni una prueba aplicable a todos los archivos recientes.
Qué sigue sin conocerse
El aviso no identifica nombre de archivo, fecha de compilación, checksum, familia de controladora ni una prueba reproducible. Tampoco aclara si la restricción afecta a la actualización web, recuperación por SD, herramientas de servicio, política de imágenes firmadas o solo a una ruta concreta. No afirma que falle la minería, el pool o la seguridad del firmware stock. Hasta disponer de una matriz de modelos y compilaciones, no debe generalizarse. Antes de cambiar nada, registre versión exacta y placa de control de cada unidad, porque un mismo nombre comercial puede incluir placas distintas.
Por qué es arriesgado actualizar sin plan
Actualizar el firmware de un ASIC no es un cambio cosmético. Puede modificar la verificación de arranque, reglas de downgrade, almacenamiento de configuración, control térmico, API y herramientas aceptadas por la placa. Si se actualizan cientos de equipos sin ensayo, un retroceso bloqueado puede exigir visitas, sustitución de placas o muchas horas de parada. Pero rechazar todas las actualizaciones stock también puede dejar correcciones de seguridad sin aplicar. La respuesta es gestionar el cambio: definir el motivo, beneficio esperado, conservar evidencias y probar actualización y recuperación en hardware representativo antes de ampliar el despliegue.
Procedimiento canary seguro
Elija uno o dos mineros no críticos por cada combinación exacta de modelo, controladora y versión actual. Exporte pools y red, fotografíe etiquetas, guarde identificadores y mida hashrate aceptado, potencia en pared, temperatura, ventiladores y shares rechazadas. Descargue solo del origen previsto y registre el hash. Actualice durante una ventana con personal; pruebe arranque en frío, pool de respaldo, DHCP o IP fija, monitorización, alarmas y retroceso planificado. Acceder al panel web no basta. Mantenga el canary durante un ciclo térmico normal antes de ampliar a un lote pequeño y defina condiciones de parada.
La recuperación necesita su propia prueba
No suponga que un archivo llamado recovery sirve para toda revisión de placa. Confirme interfaz física, formato de imagen, medio extraíble, secuencia LED y si borra la configuración. Guarde copias locales exactas y autorizadas de imágenes stock y alternativas, con hashes e instrucciones, respetando licencias. El equipo debe poder localizar una unidad cuya dirección cambió tras el reset. Si el retorno exige bypass no soportado, herramientas de desbloqueo desconocidas o acceso remoto de terceros no verificados, deténgase y escale. El tiempo de recuperación debe formar parte de la ventana de mantenimiento.
Controles de seguridad y procedencia
El riesgo de cadena de suministro existe en ambas opciones. Una imagen stock puede cambiar rutas de migración; una de terceros puede añadir dev fee, servicios remotos o comportamiento no soportado. Use páginas HTTPS del proveedor o repositorios documentados, valide firmas o checksums y conserve la aprobación interna. No acepte un archivo recibido solo por chat privado sin hash independiente. Separe la red de gestión, cambie credenciales tras recovery y revise conexiones salientes y destinos de pool. Compatibilidad no demuestra integridad y una promesa de rendimiento no sustituye la revisión de seguridad.
Cómo decidir hoy
Si la versión stock corrige un problema crítico real, obtenga el changelog exacto y consulte a Bitmain y al proveedor alternativo sobre ese modelo y placa. Pruebe, no adivine. Si no hay urgencia, pausar el despliegue masivo mientras Braiins investiga es reversible. No haga downgrade de una flota sana solo por el mensaje. Exija responsable, hash aprobado, resultado canary, prueba de rollback y pérdida máxima aceptable de hashrate. Revise la decisión cuando existan evidencias por modelo o documentación de Bitmain.
Qué evidencias buscar después
La continuación útil no es otro aviso general, sino una tabla reproducible: modelo, placa, compilación inicial y objetivo, método, error observado y archivo de prueba firmado o con hash. Un changelog, respuesta de soporte o instrucción de recuperación de Bitmain aportaría la posición del fabricante. Braiins puede reforzar su afirmación con versiones exactas y prueba documentada. Hasta entonces, el aviso debe cambiar la prudencia operativa, pero no demuestra un bloqueo deliberado. asic.tools tratará cualquier aclaración como actualización separada y conservará el texto original del 18 de septiembre.
Registro que debe conservar la granja
Para cada equipo probado conserve número de serie, controladora, firmware anterior y posterior, SHA-256, URL de origen, operador, horas y resultados medidos. Las capturas son apoyo; texto y logs exportados resultan más útiles durante un incidente. Vincule el registro con pools y medio de recuperación. Así un aviso social se convierte en respuesta de ingeniería controlada y las futuras aclaraciones se comparan con evidencia propia.
Fuente: Braiins ↗
Calculadora de minería ↗
