Una contraseña demasiado larga basta para abrir la puerta
Una vulnerabilidad identificada como CVE-2026-123158, bautizada por la comunidad como “*sshole” y escrita también SSHole, ha puesto bajo la lupa una de las combinaciones más habituales en la infraestructura moderna: el servidor OpenSSH ejecutándose sobre distribuciones Linux que emplean la biblioteca C musl y que tienen PAM deshabilitado. Ese es precisamente el escenario del paquete openssh-server por defecto de Alpine Linux, la distribución minimalista que sirve de base a una enorme cantidad de imágenes de contenedores Docker. El fallo permite que un atacante no autenticado, con acceso de red al puerto SSH, inicie sesión en cuentas que en teoría no tienen ninguna contraseña utilizable, simplemente enviando una contraseña excesivamente larga, de aproximadamente entre 257 y 1.024 bytes.
El problema fue descubierto por el investigador Ozgun Kultekin, de la firma de pruebas de seguridad Wakefield, y llevaba alrededor de diez años presente en el código. El proyecto OpenSSH y Alpine Linux publicaron las correcciones el 5 de noviembre de 2026, con la versión OpenSSH 10.6p2 como referencia. Cinco días después, a fecha de 10 de noviembre de 2026, administradores de sistemas y equipos de plataforma de todo el mundo revisan sus flotas de servidores y contenedores para determinar si están expuestos. La razón de la urgencia es evidente: el vector no requiere credenciales, no exige interacción del usuario y afecta a un servicio que, por su propia naturaleza, suele estar accesible desde la red.
Qué es exactamente CVE-2026-123158
En términos sencillos, la vulnerabilidad es un fallo de autenticación. El servidor sshd, encargado de aceptar conexiones remotas seguras, debería rechazar cualquier intento de acceso con contraseña dirigido a una cuenta que no tiene contraseña válida. En los sistemas afectados, esa comprobación puede resolverse de forma incorrecta cuando la contraseña recibida supera cierta longitud, y el servidor acaba concediendo el acceso.
La consecuencia práctica es grave. Un atacante que pueda alcanzar el puerto SSH de una máquina vulnerable no necesita robar credenciales, adivinar contraseñas ni explotar fallos de memoria complejos. Le basta con conocer o suponer el nombre de una cuenta del sistema cuyo campo de contraseña esté bloqueado y enviar una cadena lo bastante larga. A partir de ahí, obtiene una sesión con los privilegios de esa cuenta.
Conviene subrayar el alcance exacto del fallo para no generar alarma innecesaria. No se trata de un problema universal de OpenSSH. Requiere tres condiciones simultáneas: que el sistema use musl como biblioteca C, que sshd esté compilado o configurado sin PAM y que la autenticación por contraseña esté habilitada. Los sistemas basados en glibc, que son la mayoría de las distribuciones de propósito general, no presentan esta combinación de forma predeterminada.
El asterisco que debía cerrar el paso
Para entender el origen del fallo hay que detenerse en un detalle muy antiguo de la administración de sistemas Unix: el archivo shadow. En Linux, las contraseñas de los usuarios no se guardan en texto plano, sino como un hash dentro de /etc/shadow. Cada línea corresponde a una cuenta, y uno de sus campos contiene ese hash.
Cuando una cuenta no debe poder autenticarse mediante contraseña, es habitual que ese campo contenga un valor que nunca podrá coincidir con el hash de ninguna entrada real. Uno de los valores más comunes es un simple asterisco. Por convención, un “*” en el campo de contraseña significa que la cuenta no tiene contraseña utilizable: puede existir para ejecutar servicios, para ser destino de autenticación por clave o para cualquier otro propósito, pero no debería aceptar nunca una contraseña escrita por alguien.
Esta convención depende de un supuesto implícito: que la función que calcula el hash de la contraseña introducida jamás producirá un resultado igual a ese asterisco, y que la comparación posterior fallará siempre. Es exactamente ese supuesto el que se rompe en los sistemas afectados. Según la información publicada, la raíz del fallo está en la interacción de sshd con la función crypt de musl, la rutina encargada de calcular el hash de la contraseña. Ante contraseñas excesivamente largas, el comportamiento de esa función provoca que la comparación con el valor almacenado no se resuelva como debería, y el inicio de sesión termina teniendo éxito contra cuentas marcadas con el asterisco.
El rango de longitudes señalado, aproximadamente entre 257 y 1.024 bytes, es relevante porque explica por qué el fallo pasó desapercibido durante tanto tiempo. Ningún usuario humano introduce contraseñas de ese tamaño en el uso cotidiano, y la mayoría de las pruebas funcionales se limitan a longitudes razonables. Es el tipo de caso límite que solo aflora cuando alguien se dedica de forma deliberada a explorar los bordes de una implementación.
musl y glibc, dos filosofías para la misma tarea
Toda aplicación escrita en C para Linux se apoya en una biblioteca estándar que proporciona funciones básicas: gestión de memoria, entrada y salida, manejo de cadenas, acceso a la red y, entre muchas otras, el cálculo de hashes de contraseñas mediante crypt. La implementación más extendida es glibc, la biblioteca C del proyecto GNU, presente en Debian, Ubuntu, Fedora, Red Hat Enterprise Linux y la mayoría de distribuciones de escritorio y servidor.
musl es una alternativa nacida con objetivos distintos. Sus responsables priorizan la simplicidad, el tamaño reducido, la corrección frente a los estándares y la facilidad para generar binarios enlazados estáticamente. Esas virtudes la convierten en una opción muy atractiva para sistemas embebidos, entornos con recursos limitados y, sobre todo, imágenes de contenedores en las que cada megabyte cuenta.
La coexistencia de dos bibliotecas C con implementaciones independientes tiene una consecuencia que los desarrolladores de software multiplataforma conocen bien: el mismo código fuente puede comportarse de manera ligeramente diferente según la biblioteca con la que se compile. Las diferencias suelen ser menores, como mensajes de error, gestión de configuraciones regionales o resolución de nombres de dominio. Sin embargo, cuando una de esas divergencias afecta a una función crítica para la seguridad, como crypt, el impacto puede ser considerable. CVE-2026-123158 es un ejemplo de manual de este riesgo: un programa ampliamente auditado, como OpenSSH, hereda un comportamiento inesperado de la biblioteca sobre la que se ejecuta.
Para quienes trabajan a diario con servidores, conocer estas capas del sistema no es un ejercicio académico. Repasar los Fundamentos de Linux para desarrolladores y administradores ayuda a comprender cómo se relacionan el núcleo, la biblioteca C, los servicios y los archivos de configuración, y por qué un detalle aparentemente lejano puede terminar abriendo una brecha de acceso remoto.
Por qué Alpine está en el centro del problema
Alpine Linux se ha convertido en una de las piezas más populares del ecosistema de contenedores. Su imagen base ocupa muy poco espacio, arranca con rapidez y reduce la superficie de software instalado, lo que la ha hecho muy habitual como punto de partida para imágenes Docker de aplicaciones, herramientas de integración continua y microservicios.
Alpine utiliza musl como biblioteca C, y su paquete openssh-server por defecto se distribuye sin PAM habilitado. Esa es, exactamente, la combinación vulnerable. Por eso la noticia ha tenido una repercusión especial entre los equipos de DevOps y plataforma: un servidor SSH instalado con la configuración predeterminada de Alpine reúne las condiciones técnicas necesarias para que el fallo se manifieste si la autenticación por contraseña está activa.
La buena práctica en el mundo de los contenedores desaconseja ejecutar un servidor SSH dentro de cada contenedor. La filosofía dominante es que un contenedor ejecute un único proceso principal y que el acceso para depuración se haga mediante las herramientas del propio motor de contenedores o del orquestador. Aun así, la realidad de muchas organizaciones es más diversa: existen imágenes heredadas, entornos de laboratorio, bastiones ligeros, contenedores usados como máquinas de desarrollo remotas y sistemas embebidos basados en Alpine que sí ejecutan sshd. En todos esos casos, la vulnerabilidad de OpenSSH en Alpine obliga a revisar con detalle qué imágenes incluyen el servidor y cómo están configuradas.
Quienes necesiten mantener ese tipo de acceso pueden consultar cómo se plantea en la práctica en Cómo acceder a contenedores Docker mediante SSH, teniendo presente que, tras este fallo, cualquier configuración de ese estilo debe priorizar la autenticación por clave y evitar las contraseñas.
El papel de PAM y por qué su ausencia importa
PAM, siglas de Pluggable Authentication Modules, es el marco modular que muchas distribuciones Linux utilizan para centralizar la autenticación. En lugar de que cada programa compruebe por su cuenta las contraseñas leyendo /etc/shadow, delega esa tarea en una pila de módulos configurables que pueden validar contra el archivo local, contra un directorio corporativo, contra un segundo factor o contra cualquier otro mecanismo.
Cuando sshd se ejecuta con PAM, la verificación de la contraseña pasa por esos módulos. Cuando se ejecuta sin PAM, el propio sshd lee el hash almacenado y llama directamente a crypt para comparar. Es en este segundo camino donde se produce la interacción problemática con la implementación de musl.
La ausencia de PAM en Alpine no es un descuido, sino una decisión coherente con su filosofía minimalista: menos componentes, menos dependencias y menos código que mantener. Paradójicamente, esa simplificación es la que deja a sshd en contacto directo con el comportamiento de crypt que origina el fallo. El caso ilustra bien que reducir capas no siempre equivale a reducir riesgos; a veces, una capa intermedia absorbe comportamientos imprevistos que, sin ella, quedan expuestos.
Diez años inadvertido: el hallazgo de Ozgun Kultekin
El descubrimiento se atribuye a Ozgun Kultekin, investigador de la firma de pruebas de seguridad Wakefield. Según la información difundida tras la publicación del parche, el comportamiento defectuoso llevaba aproximadamente una década presente, lo que significa que generaciones enteras de imágenes y versiones de distribuciones habrían reunido las condiciones del fallo sin que nadie lo detectara.
El hallazgo encaja en un patrón conocido en la investigación de seguridad: los errores más persistentes no suelen estar en el código más complejo, sino en las fronteras entre componentes. OpenSSH es uno de los proyectos de software libre más revisados del mundo, y musl tiene fama de biblioteca cuidadosa y compacta. El problema no residía de forma aislada en ninguno de los dos, sino en cómo se combinaban sus supuestos. Ese tipo de fallos de integración escapa con facilidad a las auditorías centradas en un único proyecto.
El nombre informal de la vulnerabilidad, “*sshole”, juega con el asterisco que marca las cuentas sin contraseña utilizable y con la palabra hole, agujero en inglés. Como ocurre con otros fallos bautizados con nombres llamativos, la etiqueta ha contribuido a su difusión, aunque lo relevante para los equipos técnicos sigue siendo el identificador CVE y la versión corregida.
Alta o crítica: el debate sobre la severidad
Uno de los aspectos que más conversación ha generado es la discrepancia en la valoración de la gravedad. MITRE asigna al fallo una puntuación CVSS 3.1 de 8,1, lo que lo sitúa en la franja de severidad alta. El proyecto OpenSSH, por su parte, lo califica como crítico.
Estas diferencias no son inusuales. El sistema CVSS intenta medir la gravedad de una vulnerabilidad de forma estandarizada, combinando factores como el vector de ataque, la complejidad, los privilegios necesarios o el impacto sobre confidencialidad, integridad y disponibilidad. Las condiciones previas que limitan el alcance, en este caso la combinación concreta de musl, ausencia de PAM y autenticación por contraseña activa, pueden reducir la puntuación numérica. Los mantenedores de un proyecto, en cambio, suelen valorar el peor escenario realista para sus usuarios: un acceso remoto sin autenticación a un servidor SSH es, en esencia, lo que cualquier equipo de seguridad más teme.
Para los responsables de sistemas, la lección práctica es que una puntuación numérica no sustituye al análisis del propio contexto. Una organización con decenas de contenedores Alpine que exponen sshd con contraseñas habilitadas debería tratar el fallo como crítico, independientemente de la cifra oficial. Una organización que solo usa distribuciones con glibc y autenticación por clave puede considerarlo de baja prioridad para su entorno, aunque conviene igualmente aplicar las actualizaciones.
¿Culpa de OpenSSH o de musl?
Como ocurre a menudo cuando un fallo surge de la interacción entre dos proyectos, la discusión sobre la responsabilidad no se ha hecho esperar. Parte de la comunidad ha señalado que OpenSSH ha cargado con la culpa de un comportamiento que, en origen, pertenece a la función crypt de musl. Desde esa perspectiva, el nombre del fallo y su asociación directa con OpenSSH resultarían injustos para un proyecto cuyo código hacía lo que cabía esperar de una implementación estándar.
Otros participantes en el debate sostienen una postura distinta: un componente tan sensible como un servidor de acceso remoto debería protegerse frente a comportamientos inesperados de las bibliotecas sobre las que se ejecuta, limitando por ejemplo la longitud de las entradas o validando de manera explícita los valores especiales almacenados en shadow. Según esta visión, la programación defensiva en el punto de autenticación es parte de la responsabilidad del software de seguridad.
Ambas posiciones son opiniones y no hechos técnicos verificables en sí mismas, pero reflejan una tensión estructural del software libre. Los proyectos dependen unos de otros, y la seguridad de un sistema es la suma de sus piezas y de los supuestos que cada una hace sobre las demás. En la práctica, lo que importa a los usuarios es que la corrección ya está disponible y que la publicaron de forma coordinada tanto el proyecto OpenSSH como Alpine.
Un historial que obliga a la prudencia
OpenSSH tiene una reputación excelente en materia de seguridad, pero no es inmune a fallos graves, y el sector conserva fresco el recuerdo de episodios recientes. El más citado es regreSSHion, identificado como CVE-2024-6387 y divulgado por la firma Qualys el 1 de julio de 2024. Aquel fallo consistía en una condición de carrera en un manejador de señales de sshd que podía permitir la ejecución remota de código sin autenticación en sistemas Linux basados en glibc. Era, además, una regresión de un error corregido mucho antes, CVE-2006-5051, reintroducido en las versiones desde la 8.5p1 hasta la anterior a la 9.8p1.
La comparación entre ambos casos resulta ilustrativa. regreSSHion afectaba a sistemas con glibc y su explotación práctica era difícil: en condiciones de laboratorio y sobre sistemas de 32 bits, ganar la condición de carrera requería horas de intentos. SSHole, en cambio, afecta a sistemas con musl y su mecanismo es conceptualmente mucho más simple, aunque está acotado por condiciones de configuración muy concretas. En ambos casos, la recomendación fue la misma: actualizar de inmediato y reducir la exposición del servicio mientras tanto.
Ambos episodios recuerdan también que las regresiones y los casos límite tienen una vida sorprendentemente larga. Un error reintroducido años después o un comportamiento de borde que sobrevive una década son señales de que incluso los proyectos más maduros necesitan pruebas de regresión específicas para seguridad y técnicas de exploración automatizada, como el fuzzing, orientadas a entradas anómalas.
Quién está realmente expuesto
El análisis de exposición debe hacerse con precisión, porque la combinación vulnerable es concreta. Un sistema está en riesgo si cumple simultáneamente las siguientes condiciones:
- Ejecuta sshd en una distribución basada en musl, siendo Alpine Linux el caso más extendido.
- El servidor funciona sin PAM, como ocurre con el paquete openssh-server por defecto de Alpine.
- La autenticación por contraseña está habilitada en la configuración de sshd.
- Existen cuentas con un asterisco en el campo de contraseña de shadow, es decir, cuentas sin contraseña utilizable.
- El puerto SSH es accesible para el atacante a través de la red.
La última condición merece atención especial. Un sshd que solo escucha en una red interna aislada reduce mucho el riesgo, pero no lo elimina: en un incidente real, un atacante que ya haya comprometido otro equipo de la misma red podría usar este fallo para moverse lateralmente. En entornos de contenedores, redes compartidas entre servicios o puertos publicados por descuido en el anfitrión pueden ampliar la exposición más de lo que los equipos suponen.
También es importante recordar que las cuentas sin contraseña utilizable son habituales. Muchas cuentas de servicio y algunas cuentas de usuario configuradas exclusivamente para autenticación por clave tienen el campo de contraseña bloqueado precisamente para que nadie pueda iniciar sesión con contraseña. La paradoja del fallo es que esas cuentas, pensadas para ser las más cerradas, son justamente las que quedan abiertas.
Por el contrario, los sistemas basados en glibc, los que usan PAM para autenticar en sshd y los que tienen la autenticación por contraseña desactivada no reúnen las condiciones descritas. Eso no exime de actualizar, pero permite priorizar.
La respuesta: OpenSSH 10.6p2 y los paquetes de Alpine
La corrección llegó con OpenSSH 10.6p2. El proyecto OpenSSH y Alpine Linux publicaron sus respectivas actualizaciones el 5 de noviembre de 2026, lo que permitió a los usuarios de Alpine obtener un paquete corregido a través de su gestor de paquetes habitual el mismo día de la divulgación.
Para los entornos de contenedores, sin embargo, actualizar no es tan sencillo como ejecutar una orden en un servidor. Las imágenes Docker son artefactos inmutables: un contenedor en ejecución seguirá usando la versión de OpenSSH con la que se construyó su imagen. La corrección efectiva exige reconstruir las imágenes con la versión actualizada del paquete, publicarlas de nuevo en el registro correspondiente y redesplegar los contenedores. En organizaciones con muchas imágenes derivadas unas de otras, el proceso puede requerir días.
Esta particularidad convierte el inventario en la primera tarea. Los equipos necesitan saber qué imágenes incluyen openssh-server, de qué versión de Alpine derivan y en qué entornos se ejecutan. Las herramientas de análisis de imágenes y los inventarios de componentes de software ayudan a responder esas preguntas con rapidez, siempre que la organización las tenga integradas en su flujo de trabajo antes de que llegue la emergencia.
Mitigación cuando no se puede parchear
No todas las organizaciones pueden actualizar de inmediato. Hay sistemas embebidos con ciclos de actualización lentos, imágenes heredadas cuyos procesos de construcción ya no están documentados y entornos regulados que requieren validaciones antes de cualquier cambio. Para esos casos existe una mitigación clara y eficaz.
Basta con establecer la directiva PasswordAuthentication no en el archivo sshd_config y reiniciar el servicio sshd. Con ese cambio, el servidor deja de aceptar autenticación por contraseña y el vector de ataque queda bloqueado por completo, ya que el fallo depende precisamente de que sshd procese una contraseña. A partir de ese momento, el acceso debe hacerse únicamente mediante claves.
Antes de aplicar la medida, conviene asegurarse de que los usuarios legítimos tienen sus claves públicas instaladas en el servidor, para evitar quedarse sin acceso a la máquina. En contenedores, la mitigación implica igualmente reconstruir la imagen con la nueva configuración o montar un archivo de configuración corregido, de modo que el esfuerzo no siempre es menor que el de actualizar el paquete. En muchos casos, lo más sensato es combinar ambas acciones: desactivar las contraseñas y actualizar a la versión corregida.
Para quienes todavía dependen de contraseñas por costumbre, este es un buen momento para dar el paso. La Guía Definitiva para Configurar Claves SSH explica cómo generar, distribuir y proteger pares de claves, una transición que elimina de raíz toda una familia de riesgos, incluido el que describe este fallo.
Buenas prácticas para endurecer SSH
Más allá de la corrección puntual, SSHole es una oportunidad para endurecer la configuración de SSH de forma sistemática. Las recomendaciones que suelen repetir los especialistas en seguridad de sistemas incluyen varias medidas complementarias.
La primera es la ya mencionada: priorizar la autenticación por clave pública SSH y desactivar las contraseñas siempre que sea posible. Las claves resisten los ataques de fuerza bruta y, como demuestra este caso, eliminan la superficie asociada al procesamiento de contraseñas.
La segunda es restringir quién puede iniciar sesión. Directivas como AllowUsers o AllowGroups limitan el acceso a cuentas concretas, de modo que las cuentas de servicio no puedan utilizarse para entrar aunque existan en el sistema. Desactivar el inicio de sesión directo como root con PermitRootLogin es otra medida clásica que reduce el impacto de cualquier acceso indebido.
La tercera es limitar la exposición de red. Un servidor SSH no tiene por qué estar abierto a todo internet. Cortafuegos, listas de direcciones permitidas, redes privadas virtuales y bastiones centralizados reducen drásticamente el número de actores que pueden siquiera intentar una conexión. En entornos de contenedores, la recomendación es no publicar el puerto 22 de un contenedor en el anfitrión salvo necesidad justificada.
La cuarta es mantener una vigilancia activa. Revisar los registros de autenticación, alertar ante inicios de sesión inusuales y monitorizar intentos con contraseñas anormalmente largas puede ayudar a detectar intentos de explotación de este y otros fallos. Las herramientas que bloquean direcciones tras varios intentos fallidos añaden una capa adicional de defensa.
Por último, conviene revisar periódicamente las cuentas del sistema. Eliminar las cuentas que no se usan y asegurarse de que las cuentas de servicio tienen un intérprete de órdenes no interactivo reduce el valor de cualquier acceso que un atacante pudiera lograr.
Lecciones para equipos de desarrollo y operaciones
El caso deja varias enseñanzas que van más allá de OpenSSH y de Alpine. La primera tiene que ver con los supuestos implícitos. Durante una década, la seguridad de las cuentas bloqueadas dependió de que una función de biblioteca se comportara de cierta manera ante entradas que nadie esperaba recibir. Los equipos de desarrollo pueden extraer de ello una regla general: las comprobaciones de seguridad deben ser explícitas. Si un valor especial significa “esta cuenta nunca debe autenticarse con contraseña”, el código debería tratarlo como tal antes de cualquier cálculo, en lugar de confiar en que la comparación fallará.
La segunda lección afecta a la elección de imágenes base. Las imágenes de contenedores basadas en Alpine ofrecen ventajas reales de tamaño y velocidad, pero introducen una biblioteca C distinta de la que se usa en la mayoría de entornos de desarrollo. Esa diferencia debe formar parte del análisis de riesgos, de las pruebas y de las auditorías. No se trata de abandonar Alpine, sino de reconocer que una imagen más pequeña no es automáticamente una imagen más segura.
La tercera lección se refiere a la gestión de dependencias en contenedores. Un fallo en un paquete del sistema operativo base se propaga a todas las imágenes construidas sobre él. Sin un inventario actualizado, una canalización de reconstrucción automatizada y una política clara de actualización de imágenes base, cada vulnerabilidad de este tipo se convierte en un ejercicio de búsqueda manual.
La cuarta lección es cultural. El debate sobre si la responsabilidad corresponde a OpenSSH o a musl es comprensible, pero desde la perspectiva de quien opera los sistemas resulta secundario. Lo que protege a una organización es asumir que cualquier componente puede fallar y diseñar defensas en profundidad: menos servicios expuestos, menos métodos de autenticación débiles y más capas independientes de control.
Finalmente, el episodio refuerza el valor de la investigación de seguridad independiente. El trabajo de profesionales como Ozgun Kultekin, dedicados a explorar casos límite que ninguna prueba funcional contempla, es lo que permite cerrar agujeros que llevaban años abiertos sin que nadie lo supiera.
Situación actual
A 10 de noviembre de 2026, cinco días después de la publicación de las correcciones, la situación puede resumirse en varios puntos. La versión corregida, OpenSSH 10.6p2, está disponible, y Alpine Linux ofrece paquetes actualizados desde el 5 de noviembre. La mitigación mediante PasswordAuthentication no está documentada y bloquea por completo el vector para quienes no puedan actualizar de inmediato.
En cuanto a la explotación activa, circulan informes contradictorios. Algunas voces apuntan a posibles intentos de aprovechamiento del fallo, mientras que otras no han observado actividad atribuible a esta vulnerabilidad. Por ahora no existe una confirmación sólida de explotación en entornos reales, lo que no debe interpretarse como motivo para relajar la respuesta: la simplicidad conceptual del mecanismo hace razonable suponer que los atacantes intentarán aprovecharlo, especialmente contra servidores expuestos a internet.
La discrepancia sobre la severidad persiste: MITRE mantiene la puntuación CVSS 3.1 de 8,1, en la categoría alta, mientras que el proyecto OpenSSH sostiene la calificación de crítica. El debate comunitario sobre el reparto de responsabilidades entre OpenSSH y musl continúa abierto, sin que ello afecte a la disponibilidad de la corrección.
Para los equipos técnicos, la tarea inmediata es clara: identificar las máquinas y contenedores con sshd sobre musl sin PAM, verificar si la autenticación por contraseña está activa, actualizar a la versión corregida, reconstruir las imágenes afectadas y, como medida de refuerzo, desactivar la autenticación por contraseña allí donde no sea imprescindible.
Conclusiones
CVE-2026-123158, conocida como “*sshole” o SSHole, demuestra que una configuración perfectamente habitual puede esconder durante años un fallo de enorme impacto. La combinación de OpenSSH, musl y la ausencia de PAM, presente por defecto en el paquete openssh-server de Alpine Linux, permitía que una contraseña desmesuradamente larga abriera cuentas que, por diseño, nunca deberían aceptar contraseña alguna. El hallazgo de Ozgun Kultekin, de Wakefield, ha sacado a la luz un problema de cerca de diez años de antigüedad que afecta especialmente al mundo de los contenedores.
La respuesta ha sido rápida y coordinada: OpenSSH 10.6p2 y los paquetes de Alpine publicados el 5 de noviembre de 2026 corrigen el fallo, y la directiva PasswordAuthentication no ofrece una mitigación completa para quienes necesitan tiempo. La diferencia de criterio entre MITRE, que lo puntúa como alto, y el proyecto OpenSSH, que lo considera crítico, invita a cada organización a evaluar su propia exposición en lugar de depender únicamente de una cifra.
Más allá del parche, el caso deja una enseñanza duradera para desarrolladores y administradores: las fronteras entre componentes son terreno fértil para los errores, las bibliotecas de base importan tanto como las aplicaciones y la autenticación por clave, unida a una exposición de red mínima, sigue siendo la defensa más sólida para un servicio tan crítico como SSH. Mientras no haya confirmación firme sobre su explotación activa, la prudencia aconseja actuar como si ya estuviera ocurriendo.