SSHole ya se explota: CISA sumó a su catálogo la falla de OpenSSH que afecta a Alpine

La falla SSHole (CVE-2026-123158), que puede dejar entrar sin clave a ciertos servidores Linux con OpenSSH, ya se está usando en ataques. El 9 de noviembre de 2026, la agencia de ciberseguridad de Estados Unidos (CISA) la agregó a su catálogo de vulnerabilidades explotadas, y las firmas GreyNoise y Previdian registraron accesos que funcionaron en sus propios equipos de observación.

Si administrás un servidor con Alpine Linux y SSH abierto, esto va antes que el café: actualizá el paquete openssh, reiniciá el servicio SSH (sshd) y después revisá si alguien entró, porque cerrar la puerta no saca a quien ya pasó. Si no podés actualizar ya, apagá el ingreso por contraseña (PasswordAuthentication no), pero antes comprobá que entrás con llave.

Si tus servidores corren Windows o macOS, o un Linux común como Ubuntu, Debian o Fedora, esta no te toca: según The Hacker News, la falla no afecta a sistemas que no son Linux, a los Linux basados en la biblioteca glibc ni a los que validan contraseñas con PAM, el módulo de autenticación del sistema. OX Security nombra a esas tres distribuciones como no afectadas. Lo que cuenta es la máquina donde corre el servidor SSH, no la computadora desde la que te conectás. La excepción: un contenedor o una máquina virtual con Alpine y sshd adentro de ese servidor Ubuntu, u otro Linux con la biblioteca musl y sin PAM.

Qué cambió en cuatro días

Cuando contamos el arreglo de OpenSSH 10.6p2, el 5 de noviembre, Alpine decía que todavía no había número CVE y The Hacker News, que no había ataques reportados. Las dos cosas quedaron viejas.

El registro oficial del CVE le da un 8,1 sobre 10, severidad alta, con la complejidad de ataque marcada como alta. Y el catálogo de CISA, que reúne vulnerabilidades explotadas, trae dos datos que conviene leer con cuidado.

El primero es la fecha límite: en la entrada de esta falla figura el 12 de noviembre, tres días después de agregarla. Rige para las agencias federales de Estados Unidos alcanzadas por la directiva BOD 26-04, no para tu empresa en Córdoba o en Bogotá, pero sirve para medir la urgencia.

El segundo: la entrada marca como requerido el triaje forense, una revisión para determinar si ya hubo intrusión. La guía de CISA incluye preservar evidencia, contener y analizar, además de parchear. Sobre si la usan grupos de ransomware, el catálogo responde «Unknown»: no se sabe.

El CVE se publicó el 5 a las 15:46 UTC. Los primeros intentos llegaron el mismo día en la medición de GreyNoise, que etiquetó uno a las 18:34 UTC, y menos de nueve horas después del CVE en la de Previdian. Cuando alguien dice «tengo el fin de semana para parchear», esto es lo que le contesta internet.

Qué se vio y qué todavía no se sabe

La página de actividad de GreyNoise cuenta 16 explotaciones confirmadas. La firma llama así a una cadena de ataque en la que el servidor SSH de uno de sus equipos vulnerables de observación (los llama «gridpoints») llegó a ejecutar comandos del sistema, y la primera es del 7 de noviembre a las 00:46 UTC. BleepingComputer los describe como redes protegidas por GreyNoise, y agrega que esas cadenas salieron de seis direcciones IP y que no representan toda la actividad.

Previdian informa 20 intentos desde 13 direcciones IP en nueve países (Dinamarca, Irán, Japón, Países Bajos, Noruega, Singapur, Suecia, Suiza y Estados Unidos), el último el 8 de noviembre, y confirmó acceso root en un señuelo con Alpine, según The Hacker News. Sobre la primera tanda, ocho intentos desde una IP en Japón, su fundador, Ryan Dewhurst, contó:

«La IP observada […] usó contraseñas sobredimensionadas para saltearse la autenticación y ejecutó comandos de reconocimiento como id, uname y hostname a través de sesiones SSH no interactivas.»Ryan Dewhurst, Previdian, en declaraciones a The Hacker News (traducción de TCD)

BleepingComputer suma otras dos firmas: watchTowr dijo el 6 de noviembre que vio la falla usada en ataques asociados con botnets (redes de equipos tomados) y criptominería, y Defused observó «una pequeña cantidad de actores», sin que la actividad fuera masiva.

Ahora la letra chica, que acá cambia la lectura. Todo lo que tiene cifra ocurrió en equipos de observación de las propias firmas. Eso prueba que el ataque funciona y que hay gente haciéndolo, pero no cuenta cuántos servidores de verdad cayeron; watchTowr y Defused no dicen dónde lo vieron.

En los informes que leímos no encontramos una lista pública de víctimas reales, ni ataques confirmados en América Latina. Que no aparezca no quiere decir que no existan: quien cae no suele avisar. También hay que leer con pinzas las cifras gordas: GreyNoise registró, siempre según BleepingComputer, 27,5 millones de escaneos del puerto 22 y 20,1 millones de intentos de sesión SSH, pero no son ataques confirmados de SSHole.

TAC Agent: instalado, pero sin órdenes

En uno de los casos que describe BleepingComputer, el atacante consiguió root (el usuario con control total) e instaló TAC Agent, un programa en Python para controlar la máquina a distancia. No llegó a su servidor de mando (tac.vpnla[.]org) y nunca recibió una orden. GreyNoise lo describe como un agente que reporta el sistema, lista y copia archivos, ejecuta comandos y se actualiza solo, y advierte que esa parte de su análisis fue generada con IA y puede cambiar.

Si falta un programa, el agente contesta en chino y pide reenviar la orden con herramientas disponibles. GreyNoise lo marca como inferencia: puede haber un planificador automático del otro lado. El idioma no alcanza para decir quién está detrás, y según BleepingComputer, GreyNoise solo lo presenta como un indicio para sumar a otras pruebas.

Quién tiene que mirar esto

El catálogo de CISA habla de «OpenSSH en Linux», y el registro del CVE, de versiones anteriores a la 10.6p2. Leídos solos asustan de más. El mismo registro aclara la condición que importa: la biblioteca musl y sin PAM, con Alpine como ejemplo. Y el aviso de Alpine pide que se cumplan todas estas cosas a la vez:

• Usás el paquete openssh-server de Alpine, compilado sin PAM, o openssh-server-pam con UsePAM no.
• El ingreso por contraseña está activado (PasswordAuthentication yes, lo que trae de fábrica si no lo cambiaste).
• Hay una cuenta cuyo campo de contraseña es un asterisco (*), como una que entra solo con llave. También cuentan los usuarios que vienen de un directorio externo por musl-nscd.
• Hay al menos una cuenta local con una contraseña real (guardada como hash $5$ o $6$).

Además, el atacante tiene que conocer el nombre de la cuenta. Alpine aclara que root queda protegido por la configuración de fábrica salvo con PermitRootLogin yes, pero que eso no sirve si otra cuenta que puede entrar puede pasar a root, por ejemplo con doas, el equivalente de sudo en Alpine.

Ojo con las imágenes de nube: según Alpine, las tiny-cloud (las oficiales para nube) de la 3.18.11 a la 3.24.3 traen un usuario alpine sin contraseña y con doas sin contraseña; son seguras al primer arranque, pero quedan al alcance apenas aparece en la máquina cualquier contraseña real con hash $6$. Las configuradas con cloud-init no están afectadas. La firma Safe Security agrega a la lista de prioridades los equipos y sistemas a medida con musl, y aclara que los contenedores Alpine solo cuentan si corren un SSH vulnerable y alcanzable.

Otro detalle que confunde: el número de versión no alcanza para decidir. Salvo en edge, la rama en desarrollo, Alpine no pasó a la 10.6p2: arregló cada rama sobre la versión que ya tenía. Si en una 3.24 ves 10.3_p1-r2 o posterior y reiniciaste sshd, estás cubierto aunque el CVE diga «antes de la 10.6p2».

Cómo cerrarlo hoy

Alpine pide correr apk upgrade -U -a y después rc-service sshd restart: actualizar el paquete no reemplaza al sshd que ya está corriendo. Estas son las versiones corregidas por rama:

Si no podés actualizar todavía, poné PasswordAuthentication no en la configuración de sshd y reinicialo, pero antes comprobá que tu ingreso con llave funciona y dejá abierta la sesión actual hasta probar una nueva. El aviso de Alpine trae los comandos completos, incluidos los bloques Match, y en la nota anterior los resumimos. Para confirmar, sshd -T | grep -i passwordauthentication tiene que responder passwordauthentication no.

Cómo saber si ya entraron

Esta es la parte que se saltea todo el mundo. Si el servidor estuvo expuesto, al menos desde el 5 de noviembre, parchear es la mitad del trabajo.

• Registros. Buscá en /var/log/messages las líneas de sshd con Accepted password for para una cuenta que no tiene contraseña: alpine, root o cualquier usuario que entra solo con llave.
• Llaves. Revisá los archivos authorized_keys: los atacantes que vio GreyNoise intentaron modificarlos para volver a entrar, según BleepingComputer, y también trataron de leer los hashes de contraseñas y las llaves SSH de root.
• Usuarios y archivos. Alpine pide mirar el uso de doas y los usuarios, archivos y llaves creados hace poco en las máquinas expuestas.
• TAC Agent. BleepingComputer recomienda buscar sus archivos o servicios de arranque. No trae persistencia propia, por eso los atacantes intentan configurar un servicio.

Y el criterio de cierre lo pone Alpine, sin vueltas: «si no podés descartar un ingreso, tratá la máquina como comprometida» (traducción de TCD). Ahí conviene pensar en qué más tenía a mano ese servidor, porque, como escribió Safe Security en su análisis, «las consecuencias de SSHole dependen de los privilegios de la cuenta comprometida», y un atacante puede llegar a credenciales de despliegue, secretos de aplicaciones e infraestructura conectada (traducción de TCD). Nuestra lectura: si no podés descartarlo, además de reinstalar desde una imagen limpia, cambiá las claves y tokens que vivían en esa máquina.

Una falla armada con tres decisiones razonables

Lo más incómodo de SSHole es que nadie hizo algo evidentemente mal. OX Security la describe como el choque de tres decisiones separadas: la biblioteca musl rechaza contraseñas de más de 256 bytes y devuelve un asterisco como error; OpenSSH cambió en 2016 su forma de comprobar contraseñas para no delatar si un usuario existe, a raíz de la falla CVE-2016-6210, según The Hacker News; y desde Alpine 3.16, en 2022, el usuario root trae un asterisco en el campo de contraseña.

Cuando un atacante manda una contraseña gigante, el resultado del error (*) coincide con lo que la cuenta tiene guardado (*), y el servidor entiende que todo está en orden. No hay criptografía rota ni memoria corrompida: hay un símbolo que significaba dos cosas distintas.

OpenSSH ya había avisado en sus notas de la versión que va a sacar versiones más seguido porque cada vez llegan más reportes hallados con IA. Nuestra lectura: si encontrar fallas se acelera, el tiempo para parchear se achica.

Por qué importa en América Latina

No encontramos ataques confirmados ni víctimas en la región, y sería inventar decir que los hay. Lo que sí hay es un perfil que acá abunda: la pyme que alquila un servidor virtual barato, el desarrollador que levantó una imagen Alpine porque pesa poco y el servidor «que anda y nadie toca». Si tenés uno de esos, hoy pedile a quien lo administra tres cosas: la versión del paquete, la salida de sshd -T y una mirada a los registros. Y si la respuesta es «¿qué es Alpine?», mejor averiguarlo antes de que te lo explique otro.

Fuentes

• CISA, catálogo de vulnerabilidades explotadas (en inglés). Entrada de CVE-2026-123158: agregada el 9 de noviembre de 2026, vence el 12, triaje forense requerido y uso en ransomware desconocido.
• Registro CVE-2026-123158 (en inglés). Descripción, versiones y severidad 8,1.
• Alpine Linux, aviso de seguridad (en inglés), 5 de noviembre de 2026. Condiciones, versiones corregidas, imágenes de nube y revisión de registros. Traducción de TCD.
• OpenSSH, notas de la versión 10.6p2 (en inglés), 5 de noviembre de 2026.
• CISA, guía de BOD 26-04 (en inglés). Pasos del triaje forense.
• GreyNoise, actividad de SSHole (en inglés), consultada el 9 de noviembre de 2026. Explotaciones confirmadas en sus equipos de observación y análisis de TAC Agent.
• Previdian, ficha de CVE-2026-123158 (en inglés), actualizada el 9 de noviembre de 2026. Cronología e intentos observados.
• BleepingComputer, «Hackers exploit SSHole OpenSSH flaw to breach Linux systems» (en inglés), 9 de noviembre de 2026.
• The Hacker News, «Hackers Target OpenSSH SSHole Flaw Within Hours of Disclosure, Gain Root on Honeypot» (en inglés), 6 de noviembre de 2026, actualizada el 8.
• OX Security, análisis técnico (en inglés), 5 de noviembre de 2026.
• Safe Security, análisis de SSHole (en inglés), 6 de noviembre de 2026.
• Créditos de imagen: fotomontajes editoriales asistidos por IA con los logos oficiales de OpenSSH y Alpine Linux y una fotografía de archivo de racks en NERSC (Derrick Coetzee, Wikimedia Commons, CC0), sin relación con los ataques.