Una contraseña de 257 caracteres abrió cuentas sin contraseña en ciertos servidores Linux: qué pasó con OpenSSH y qué preguntar a tu proveedor

El titular que circula esta semana dice que una falla de OpenSSH permite entrar sin contraseña a servidores Linux. Es cierto a medias, y la mitad que falta decide si te toca o no. El 5 de noviembre se publicó OpenSSH 10.6p2 para corregir un fallo que afecta a una parte específica de Linux, no a todo Linux. Aquí va lo que dicen las fuentes primarias, qué tiene que ver con la inteligencia artificial y qué preguntar a quien administra tu sitio.

Qué pasó

• El aviso. OpenSSH es el programa que permite administrar un servidor de forma remota. Su versión 10.6p2 salió el 5 de noviembre con una solución crítica para sistemas Linux que usan la biblioteca musl y tienen PAM desactivado. El proyecto considera que la causa de fondo está fuera de sshd, pero que se puede explotar a través de él.
• El mecanismo. En Linux, una cuenta sin contraseña se marca con un asterisco. Según Alpine Linux, sshd compara lo que escribes con ese campo, y musl devuelve un asterisco cuando la contraseña supera 256 bytes. Dos asteriscos iguales cuentan como coincidencia y la sesión se abre.
• El alcance. El atacante necesita el nombre de una cuenta sin contraseña, y que en la misma máquina exista otra cuenta con contraseña normal. Con eso, una sola conexión con una contraseña de 257 a 1,024 caracteres basta, sin reintentos.
• El descubridor. Özgün Kültekin, de Wakefield, quien afirma que el defecto existe desde 2016. Esa antigüedad es dicho suyo.

«Hemos visto varios casos en que un error de seguridad identificado con herramientas de IA es descubierto después, de forma independiente, por otro investigador.» Equipo de OpenSSH, notas de la versión 10.6p2, 5 de noviembre de 2026 (traducción nuestra).

A quién afecta y a quién no

Según Alpine, BleepingComputer y el investigador, deben cumplirse todas estas condiciones: el sistema usa musl (Alpine, OpenWrt, Buildroot, Yocto); sshd corre sin PAM, lo normal en el paquete estándar de Alpine; el acceso por contraseña está activado, que es el valor por defecto; existe una cuenta con asterisco, como root o un usuario que solo entra con llave; y otra cuenta tiene una contraseña real.

No están afectados, según las mismas fuentes, los sistemas con glibc (Debian, Ubuntu, Fedora), los que usan PAM, los que tienen desactivada la contraseña por SSH y los contenedores que no ejecutan sshd. Tampoco permite saltarse la contraseña de una cuenta que sí la tiene. El caso más delicado son las imágenes oficiales de Alpine para nube: según su aviso, traen un usuario que puede volverse administrador sin contraseña.

La parte de inteligencia artificial

Kültekin cuenta que no halló el fallo leyendo código a mano: dice que lanzó enjambres de agentes de IA que corrieron unas 17,600 pruebas de inicio de sesión, y que todas las configuraciones coincidían salvo musl sin PAM. Es su relato, no una medición independiente. Encaja con lo que dice OpenSSH: recibe muchos reportes hechos con ayuda de IA, algunos sin impacto real, y por eso publicará versiones con más frecuencia en lugar de acumular correcciones.

La consecuencia para una pyme es de ritmo: si encontrar fallos se vuelve más barato, el tiempo entre «se publicó el parche» y «alguien lo intenta» se acorta. Lo vimos desde el otro lado con Gemini 4 Carbon, la IA de Google para buscar vulnerabilidades y con el aviso de PHP2Shell: actualizar deja de ser una tarea trimestral.

Lo que no está confirmado

• Cuántos sistemas están expuestos. El investigador dice que las cifras podrían publicarse después. No hallamos una medición independiente ni datos de México.
• Ataques reales. Redes Zone afirma que por ahora no se han detectado. No pudimos comprobarlo, y no haberlos visto no es garantía.
• Identificador CVE. Alpine indicó al publicar que aún no había uno. Algunos medios citan un número que no encontramos en una fuente primaria, así que no lo usamos.
• Otras distribuciones. Revisamos las versiones corregidas de Alpine y OpenSSH 10.6p2; no verificamos OpenWrt, Buildroot ni Yocto.

La perspectiva de Bit Farm para una pyme

Lo siguiente es criterio nuestro, no un requisito del proyecto OpenSSH. Si tu sitio está en un hosting compartido o administrado, el servidor lo operan otros y conviene preguntarles por escrito. Si tienes un servidor virtual propio, un router con firmware personalizado o contenedores armados por un proveedor anterior, la pregunta es tuya. Cinco preguntas útiles:

• ¿Qué sistema operativo y versión corre cada servidor? Si nadie lo sabe, ese es el primer hallazgo.
• ¿El acceso por SSH admite contraseña o solo llaves? Alpine y el investigador coinciden en que desactivar la contraseña cierra esta falla.
• ¿Quién actualiza y cada cuánto? Con fecha y responsable, no «alguien lo hace».
• ¿Se reinicia el servicio después de actualizar? Alpine advierte que instalar el paquete no reemplaza el sshd que ya está corriendo.
• ¿Quién revisa los registros de acceso? Alpine sugiere buscar inicios de sesión con contraseña en cuentas que no deberían tenerla; si no puedes descartar uno, trata la máquina como comprometida.

Cómo podemos ayudar

Bit Farm es una consultoría tecnológica mexicana: hacemos sitios, sistemas a la medida y hosting para pymes. Podemos ayudarte a levantar el inventario de servidores y accesos, revisar con tu proveedor las preguntas anteriores y definir un calendario de actualizaciones con responsables. Este artículo no sustituye una asesoría legal o de seguridad especializada.

Fuentes: Alpine Linux, aviso de seguridad del 5 de noviembre de 2026; Notas de la versión OpenSSH 10.6p2; *sshole, explicación del investigador; BleepingComputer; Redes Zone.