Cuando apagas un servidor, el servidor no se apaga. Dentro sigue despierto un ordenador pequeño con su propio procesador, su propio firmware, su propia IP y su propia contraseña. Se llama BMC, y es la pieza más privilegiada del rack: enciende, apaga, monta una ISO y te da la pantalla como si estuvieras delante de la máquina. También es, casi siempre, la única pieza en la que nadie ha entrado desde el día del montaje. El 29 de julio se publicó el recuento: 36.872 de esos ordenadores están escuchando en internet, y 24.650 le entregan material derivado de la contraseña de la cuenta a quien lo pida, antes de iniciar sesión.
Operamos hierro propio en varios datacenters —clústers Proxmox con Ceph, red propia— y nos pagan por mantener infraestructura de otros, así que este recuento no lo leemos como una curiosidad de titular. Lo leemos como una lista de tareas que llevaba años sin dueño. Vamos con los números primero y con la parte incómoda después: esto no se cierra con un parche.
Qué es exactamente lo que está expuesto
El BMC (Baseboard Management Controller) es el procesador de gestión que llevan los servidores de rack. Según el fabricante se llama iLO, iDRAC, IPMI o simplemente «gestión», y se habla con él por un protocolo llamado IPMI en el puerto 623/UDP. Su gracia es que funciona fuera de banda: no depende del sistema operativo, ni de que el sistema operativo arranque, ni de que el servidor esté encendido. Mientras haya corriente en la fuente, el BMC está vivo.
Con acceso a un BMC no «se administra un servidor». Se hace todo lo que haría alguien de pie delante del rack con un teclado, una pantalla y un USB en la mano: apagar, encender, entrar en la BIOS, montar una imagen remota y arrancar de ella. Por eso no nos gusta llamarlo «interfaz de gestión»: es una consola física remota, y quien la controla no necesita ni tocar tu sistema operativo. Reinstalar el servidor tampoco lo echa de ahí.
Los números del recuento
El escaneo es del 6 de mayo de 2026 y busca todo lo que responde en 623/UDP desde internet. Lo publicaron el 28 y 29 de julio. Tal cual:
Sumando las dos categorías crackeables publicadas —cuenta vacía y cuenta con nombre— salen 8.580 controladores con la contraseña al alcance de un diccionario. La suma exacta es nuestra; la cobertura de la investigación lo publica como «alrededor de un tercio». Conviene leerlo bien: es uno de cada tres de los 24.650 que filtran material. No es el 100%, y decirlo importa. Pero uno de cada tres, en una muestra de 36.872 máquinas físicas que sostienen algo, es una barbaridad.
Por geografía, más de 14.000 están en Estados Unidos, con concentraciones en Alemania, China, Países Bajos y Reino Unido. Que España no aparezca en el titular no significa nada: el escaneo mide lo que está expuesto, no dónde está el problema.
Por qué esto no se arregla con un parche
El identificador es CVE-2013-4786, con CVSS 7,5 en la escala v3. La fecha del identificador es de 2013, pero el comportamiento viene de la especificación IPMI 2.0, de 2004: en el intercambio de establecimiento de sesión, el controlador responde con un HMAC-SHA1 calculado sobre la contraseña de la cuenta y valores de sesión que el solicitante ya tiene. Es decir: el protocolo está diseñado para entregar eso. No es un bug de implementación de un fabricante.
Dell lo dijo con una claridad que agradecemos: no hay parche, y esto es «un problema inherente a la especificación de IPMI v2.0». Supermicro reconoció que el escenario es viable y recomendó rotar contraseñas y aislar la gestión en VLAN con listas de acceso, además de anunciar que revisará su política de contraseñas por defecto en revisiones futuras de hardware. Ninguno de los dos prometió una actualización de firmware que lo cierre, porque no puede existir.
Aquí está la parte que nos parece más interesante del asunto, y la que explica los 36.872: el sector ha aprendido a gestionar vulnerabilidades como cosas que se parchean. Llega el aviso, entra en la cola, se aplica, se cierra el ticket. Un fallo que no tiene parche no encaja en ese circuito: no hay nada que instalar, así que no hay nada que cerrar, así que se queda abierto veintidós años. La mitigación no es una versión, es una decisión de topología —y las decisiones de topología no las toma un boletín de seguridad.
La contraseña de fábrica única tampoco te salva
Más de la mitad de los controladores que respondieron eran Supermicro, y Supermicro hace algo que está bien: desde noviembre de 2019 —para cumplir la ley californiana SB-327— dejó de enviar placas con el ADMIN/ADMIN compartido por todo el catálogo y asigna a cada unidad una contraseña distinta, impresa en una etiqueta del chasis. Si tu placa es anterior a esa fecha, sigues con la compartida, y ahí no hace falta romper nada. El problema del resto es el formato. Son exactamente diez letras mayúsculas, y eso es un espacio de 2610 ≈ 141 billones de combinaciones. Suena enorme hasta que alguien lo mide: con un servidor de ocho GPU y Hashcat, agotar ese espacio lleva alrededor de una hora.
En HPE iLO el formato de fábrica es más corto —ocho caracteres entre mayúsculas y dígitos, 368 ≈ 2,8 billones—, y ahí los tiempos publicados dejan de ser tranquilizadores del todo: en torno a un día en un Apple M3, y unos 32 segundos por respuesta en un equipo con ocho RTX 6000 PRO. Y no hablamos de hierro de la década pasada: entre los sistemas probados hay una placa Supermicro X13DEM de 2023.
La conclusión práctica se lee mal la primera vez, pero es la clave del asunto: una vez alguien alcanza el puerto, el hash lo vas a entregar de todos modos, así que tu único control real es que ese hash no se pueda romper. No importa que la contraseña sea «secreta». Importa que sea larga y aleatoria de verdad, y que no siga un formato que se pueda expresar como una máscara de Hashcat.
Nada de esto va a salir en tus alertas
Esta es la parte que hace que el problema envejezca en silencio. La petición que devuelve el hash no es un intento de inicio de sesión fallido: es una fase legítima del protocolo, así que no hay nada que contar en un panel de «autenticaciones rechazadas». Romper el hash ocurre después, offline, en el equipo del atacante, sin volver a tocarte. Y tu EDR corre dentro del sistema operativo, mientras que el BMC no es el sistema operativo: está debajo. Cuando el intruso vuelve, vuelve ya con credenciales válidas.
El patrón nos suena porque lo hemos escrito dos veces este mes con otros protagonistas: el orquestador de red que se despliega mirando a internet porque así es más cómodo y la consola de gestión que nadie contaba como superficie de ataque. Siempre es el plano de gestión, y siempre por el mismo motivo: se monta con prisa el día del despliegue y se documenta con un «ya lo cerramos luego».
El dato que más nos preocupa no es 36.872
Es 60. Durante los meses de observación aparecieron alrededor de sesenta IP nuevas cada día exponiendo IPMI. Sesenta al día no es un inventario heredado de servidores olvidados de 2011: es un flujo. Es hierro que alguien montó esta semana, con su cable de gestión enchufado a la primera boca libre del switch, la que tenía la VLAN de datos, porque era viernes y había que dejarlo arrancado.
La pieza que no está en tu contrato de mantenimiento
Coge cualquier contrato de mantenimiento y busca el BMC. Vas a encontrar parches del sistema operativo, copias de seguridad, antivirus, monitorización, quizá firmware de cabina y de switches. El firmware del controlador de gestión y la rotación de sus credenciales suelen no estar en ninguna línea. No por mala fe: porque el BMC no es de nadie. El de sistemas asume que es «cosa del hierro», el de red lo ve como una IP más, y quien montó el servidor se fue el mismo día.
Cuatro preguntas para hacerle a tu proveedor esta semana. O para hacértelas tú, si el proveedor eres tú:
- ¿Cuántos BMC tenemos y en qué VLAN están? Si la respuesta tarda más de cinco minutos, ya tienes el primer hallazgo.
- ¿Alguno sigue con la contraseña que venía en la pegatina? Ahora ya sabes cuánto vale esa pegatina: entre 32 segundos y una hora.
- ¿Qué versión de firmware llevan? No por este fallo, que no se parchea, sino por los otros —los de la interfaz web del propio controlador, que sí se parchean y salen cada pocos meses.
- ¿Quién se enteraría si alguien entrase? Y con qué señal, dado que no habrá un login fallido que alertar.
Y la honestidad que toca: si no tienes hierro propio, esto no va contigo. Si todo lo tuyo son máquinas virtuales en un cloud público, el BMC es del proveedor y es su problema. Pero si tienes servidores en un rack —propio o alquilado— el BMC es tuyo aunque el rack no lo sea; en colocation la jaula es de otro y la consola remota sigue siendo tu responsabilidad. Es exactamente el tipo de coste invisible del que hablábamos en la cuenta a cinco años del hierro propio frente al cloud: el hardware propio sale bien de precio, pero trae tareas que en una factura de cloud no aparecen porque las hace otro.
Qué se hace hoy, en este orden
- 1. Comprueba si estás en la lista. Desde fuera de tu red, contra tus propios rangos públicos:
nmap -sU -p 623 --script ipmi-version TU.RANGO/24. Si algo responde, ese algo es un ordenador con permiso para arrancar y apagar hierro tuyo, y lo puede ver cualquiera. - 2. Cierra
623/UDPen el borde —y con él la web del controlador y su KVM, que no viven en el mismo puerto. Matiz honesto: cerrar el puerto no arregla el protocolo, solo lo saca del alcance de internet. Quien ya esté dentro de tu red sigue recibiendo el mismo regalo. - 3. Sustituye toda contraseña de fábrica por una larga y aleatoria de gestor de contraseñas. No para que sea secreta —el hash sale igual—, sino para que romperla no quepa en el presupuesto de nadie.
- 4. Desactiva lo legado: IPMI 1.5, la cipher suite 0, las cuentas anónimas y la autenticación NONE. Son opciones de otra época que siguen ahí porque nadie las apagó.
- 5. Red de gestión aparte, de verdad aparte. VLAN dedicada, sin ruta a internet, y acceso solo por VPN desde los equipos de administración. Nosotros lo hacemos con WireGuard y llevamos el inventario en NetBox como fuente única de verdad: saber cuántos BMC hay y en qué VLAN está cada uno es la mitad del control.
- 6. Usa Redfish sobre TLS en el hierro que lo permita, en vez de IPMI. Con la advertencia de los propios investigadores: ni Redfish ni IPMI deberían mirar directamente a internet.
Ninguno de esos seis puntos requiere comprar nada. Requiere que alguien tenga la tarea asignada, que es precisamente lo que ha faltado todo este tiempo.
Lo que este recuento dice de verdad
No hay aquí un fabricante malo ni una campaña de ataque nueva. Hay un protocolo de 2004 que hace lo que documentó que haría, un identificador de 2013 que nadie podía cerrar porque no había nada que instalar, y 36.872 máquinas cuyo dueño no tenía apuntado que ese ordenador pequeño de dentro también cuenta. El titular dice «vulnerabilidad de veinte años». Nosotros lo leemos distinto: veintidós años de tarea sin asignar.
Si esta semana solo haces una cosa de este post, que sea el escaneo del punto 1 contra tus propios rangos. Tarda menos que leerlo entero.
Fuentes (verificadas): el escaneo del 6 de mayo de 2026, los 36.872 servicios IPMI en 623/UDP, los 24.650 que devuelven material derivado de la contraseña, los 6.240 con usuario vacío, los 2.340 con cuentas de diccionario, las ~60 IP nuevas al día, los formatos de contraseña de fábrica de Supermicro y HPE con sus tiempos de crackeo (una hora con ocho GPU; ~32 segundos con ocho RTX 6000 PRO; ~un día en un Apple M3), la placa X13DEM de 2023, el rescate de 0,3 BTC en un iLO 4 y las mitigaciones recomendadas — investigación de Lava, «How We Hacked Thousands of Data Centers in Minutes Using a 20-Year-Old Vulnerability» (29 de julio de 2026). Cobertura, reparto geográfico (más de 14.000 en EE.UU.), CVSS 7.5 y declaraciones de fabricante —Dell: «no hay parche», «problema inherente a la especificación de IPMI v2.0»; Supermicro sobre rotación de credenciales, VLAN y política de contraseñas futura— en The Hacker News y Help Net Security (28 de julio de 2026). Contraseña única por unidad de Supermicro desde noviembre de 2019 —diez letras mayúsculas impresas en una etiqueta del chasis, en sustitución del ADMIN/ADMIN compartido, para cumplir la SB-327 de California—: página oficial de Supermicro sobre la contraseña única del BMC. Identificador y descripción del fallo: CVE-2013-4786. La suma de 8.580 controladores crackeables (6.240 + 2.340) es nuestra aritmética sobre sus cifras publicadas; la lectura de por qué un fallo sin parche envejece veintidós años, el orden de los seis pasos y las cuatro preguntas al proveedor son nuestros. Imagen: parte trasera de un rack del centro de datos del NERSC (Wikimedia Commons, dominio público).
¿Quién tiene asignado el firmware de tus BMC?
En everyWAN el plano de gestión del hierro entra en el alcance del mantenimiento informático cuando toca: inventario de controladores, credenciales rotadas, firmware al día y red de gestión separada de la de datos. Operamos nuestros propios servidores en colocation, así que estos seis puntos los aplicamos primero en casa. Si solo quieres saber si tienes algo expuesto, dilo y lo miramos: eso es una tarde, no un proyecto.
Hablar con everyWAN