SixHack Academy Formación ofensiva
ES Español ✓ EN English ✓
Entrar
CVE-2026-123158 en OpenSSH: cómo una contraseña demasiado larga podía saltarse la autenticación SSH
06 de noviembre de 2026

CVE-2026-123158 en OpenSSH: cómo una contraseña demasiado larga podía saltarse la autenticación SSH

Análisis técnico de CVE-2026-123158, el bypass de autenticación que afecta a determinadas configuraciones de OpenSSH sobre musl Linux: cómo funciona, qué sistemas son vulnerables, por qué el fallo llevaba años oculto y cómo detectarlo y corregirlo.

OpenSSH es una de las tecnologías de administración remota más desplegadas en infraestructuras modernas, por lo que cualquier fallo que afecte directamente al proceso de autenticación de sshd merece un análisis especialmente cuidadoso. CVE-2026-123158 resulta además particularmente interesante porque no nace de una corrupción de memoria convencional, de un algoritmo criptográfico roto ni de un error evidente contenido dentro de un único proyecto. La vulnerabilidad aparece como consecuencia de la interacción entre OpenSSH, musl libc, la semántica histórica de las contraseñas Unix, mitigaciones introducidas años atrás contra ataques de temporización y la forma en que determinados sistemas Linux representan cuentas que no deberían aceptar nunca una contraseña.

La vulnerabilidad fue divulgada públicamente el 5 de noviembre de 2026 y afecta a configuraciones concretas de OpenSSH sobre sistemas Linux que utilizan musl libc, ejecutan OpenSSH sin PAM y permiten autenticación SSH mediante contraseña. Cuando además se cumplen determinadas condiciones relacionadas con las cuentas locales, un atacante remoto que pueda alcanzar el servicio SSH y conozca el nombre de una cuenta susceptible puede llegar a autenticarse correctamente enviando una contraseña anormalmente larga, incluso aunque esa cuenta no tenga ninguna contraseña válida con la que normalmente pudiera iniciar sesión.

El detalle fundamental es que el atacante no está recuperando, adivinando, crackeando ni evitando una contraseña real en el sentido habitual. La cuenta vulnerable puede no tener siquiera una contraseña utilizable. Lo que ocurre es que un fallo dentro del proceso de hashing devuelve un valor especial que, de forma inesperada, coincide exactamente con el valor almacenado para la cuenta objetivo. OpenSSH termina así alcanzando una comparación en la que dos valores con significados completamente distintos resultan idénticos como cadenas de texto.

CVE-2026-123158 ha recibido una puntuación CVSS 3.1 de 8.1 HIGH, mientras que OpenSSH describió la protección incluida en la versión 10.6p2 como un critical security workaround. No existe necesariamente una contradicción entre ambas clasificaciones: CVSS intenta expresar la explotabilidad y el impacto mediante un modelo estandarizado, mientras que la terminología utilizada por el propio proyecto refleja la prioridad que sus mantenedores atribuyen a la corrección.

Este artículo analiza la causa raíz, los prerrequisitos necesarios para la explotación, los entornos afectados, las posibilidades de detección, las medidas de mitigación y las principales lecciones de ingeniería que deja CVE-2026-123158. Cualquier validación práctica de la vulnerabilidad debe realizarse únicamente sobre sistemas propios o dentro de un alcance de pruebas expresamente autorizado.

En esta guía

CVE-2026-123158 en pocas palabras

En sistemas Linux donde OpenSSH comprueba las contraseñas sin delegar la operación a PAM, sshd puede apoyarse finalmente en la implementación de crypt() proporcionada por la biblioteca C del sistema para transformar la contraseña recibida en un valor comparable con la información de autenticación almacenada para la cuenta. En una situación normal, ese proceso deriva un hash utilizando el algoritmo y la sal codificados en el campo de contraseña, y la autenticación solo se acepta cuando el resultado coincide con el valor esperado.

En musl libc, sin embargo, determinadas rutas de hashing rechazan entradas excesivamente largas. Cuando la contraseña supera la longitud soportada por los algoritmos afectados, crypt() no devuelve un hash válido. En el comportamiento relevante para esta vulnerabilidad, la operación termina produciendo la cadena * como marcador de error.

Por sí mismo, este comportamiento no tendría por qué suponer una vulnerabilidad. El problema aparece porque * ya posee desde hace años un significado dentro de las bases de datos de contraseñas Unix. Determinadas cuentas que no deberían autenticarse mediante una contraseña convencional pueden contener valores especiales como * o ! en el campo de contraseña. Estos valores no representan hashes generados a partir de una contraseña real, sino marcadores elegidos precisamente porque ninguna contraseña legítima debería producirlos.

CVE-2026-123158 introduce, por tanto, una colisión semántica. El * almacenado significa que la cuenta no dispone de un hash de contraseña utilizable, mientras que el * devuelto por la función de hashing significa que la operación ha fallado. Si la lógica de autenticación termina comparando ambas cadenas sin validar previamente que el valor almacenado representa realmente un hash legítimo, ambas resultan iguales aunque sus significados sean completamente distintos.

La vulnerabilidad no consiste en descubrir una “contraseña mágica”. El atacante fuerza deliberadamente una condición de error en el procesamiento de la contraseña y aprovecha que el marcador utilizado para expresar ese error puede resultar indistinguible del marcador especial almacenado para una cuenta que no debería aceptar contraseñas.

Las condiciones necesarias para explotarla

Resumir CVE-2026-123158 diciendo que “una contraseña larga permite saltarse OpenSSH” resulta técnicamente incorrecto. OpenSSH se despliega sobre una enorme variedad de sistemas operativos y configuraciones, mientras que la vulnerabilidad depende de una combinación muy concreta de detalles de implementación y estado de las cuentas. Que un servidor ejecute una versión numéricamente anterior a OpenSSH 10.6p2 no significa automáticamente que sea explotable.

La cadena documentada requiere la coexistencia de varias condiciones:

Condición Por qué importa
Linux utilizando musl libc El comportamiento específico de crypt() que devuelve * ante esta condición de error pertenece a la ruta afectada de musl. Sistemas que utilizan otra biblioteca C no reproducen automáticamente ese comportamiento.
OpenSSH funcionando sin PAM La ruta vulnerable requiere que OpenSSH participe directamente en la comprobación de la contraseña. Cuando PAM gestiona la autenticación, no se utiliza de la misma forma la interacción OpenSSH-musl descrita.
PasswordAuthentication yes El servidor debe aceptar intentos de autenticación mediante contraseña. Si este método está completamente deshabilitado, la ruta de ataque desaparece.
Una cuenta objetivo cuyo campo de contraseña sea exactamente * El error generado durante el hashing debe poder compararse con el mismo valor especial almacenado para la identidad atacada.
Otra cuenta local con un hash compatible $5$ o $6$ OpenSSH puede utilizar información obtenida de otra cuenta para realizar una operación de hashing incluso cuando la cuenta objetivo no contiene un hash convencional.
Acceso de red a sshd El atacante debe poder alcanzar el servicio SSH y conocer o adivinar el nombre de una cuenta susceptible.

La interacción entre estos requisitos reduce de forma importante la cantidad de sistemas realmente expuestos. Un servidor Linux puede utilizar OpenSSH y permitir contraseñas, pero estar basado en glibc en lugar de musl; otro puede utilizar musl pero tener deshabilitada la autenticación por contraseña; otro puede combinar musl y OpenSSH, pero delegar la autenticación en PAM. Ninguno de estos entornos reproduce necesariamente la ruta vulnerable descrita.

Alpine Linux merece especial atención porque varias de estas condiciones suelen coincidir de forma natural. Alpine utiliza musl libc por diseño, su paquete estándar de OpenSSH se compila sin PAM y la autenticación mediante contraseña puede permanecer habilitada salvo que el administrador la desactive expresamente. Determinadas configuraciones de cuentas pueden proporcionar entonces las piezas restantes necesarias para que la vulnerabilidad sea explotable.

Por qué importa el valor *

La forma más sencilla de comprender la vulnerabilidad es analizar cómo representan los sistemas Unix las contraseñas locales. En Linux moderno, la información relacionada con las contraseñas suele almacenarse en /etc/shadow. Un hash convencional contiene normalmente algo más que el resultado de aplicar una función criptográfica: también codifica información sobre el algoritmo utilizado y, generalmente, una sal u otros parámetros necesarios para verificar futuros intentos de autenticación.

Por ejemplo, los formatos SHA-crypt tradicionales utilizan identificadores como:

  • $5$ para SHA-256 crypt;
  • $6$ para SHA-512 crypt.

Una entrada que empiece por uno de esos identificadores permite al sistema saber qué algoritmo debe utilizar y con qué parámetros debe procesar la contraseña introducida por el usuario. El resultado se compara posteriormente con el valor completo almacenado en la base de datos.

Los estados especiales de una cuenta funcionan de otra manera. Un sistema necesita también representar situaciones en las que una identidad existe, pero no debería poder autenticarse mediante una contraseña convencional. Históricamente se han utilizado valores como * o ! para indicar esos estados. No son hashes válidos en el mismo sentido que una entrada $6$..., sino marcadores expresamente diseñados para que ninguna contraseña normal pueda verificarse contra ellos.

Esta diferencia es fundamental. Una cuenta cuyo campo contiene exactamente * depende de la suposición de que ninguna operación de hashing válida devolverá jamás ese mismo valor. Mientras la función criptográfica genere hashes reales para operaciones correctas y valores inequívocamente distintos para los errores, esa suposición es segura.

El problema aparece porque musl utiliza también * como representación de error en la ruta implicada. Una misma cadena termina teniendo dos significados completamente distintos: en un caso representa el estado de una cuenta que no dispone de una contraseña utilizable y, en el otro, representa que la función encargada de calcular el hash ha fallado.

Nos encontramos así ante un ejemplo clásico de un problema de seguridad producido entre distintas capas de abstracción. Dos subsistemas utilizan exactamente la misma representación para conceptos que no deberían ser intercambiables. Si el código consumidor no valida la estructura o el tipo lógico del valor antes de compararlo, un estado imposible desde el punto de vista de un componente puede convertirse accidentalmente en un estado válido para otro.

El papel de crypt() y musl libc

La familia de interfaces crypt() existe desde hace décadas y tradicionalmente proporciona a aplicaciones Unix una forma común de verificar contraseñas mediante los algoritmos soportados por el sistema operativo. En lugar de que cada daemon de autenticación implemente por separado todos los esquemas de hashing, el programa puede delegar esa operación en la biblioteca del sistema.

En el caso habitual, la aplicación proporciona la contraseña en texto claro y la información derivada del hash almacenado. La función genera entonces una cadena que puede compararse con el valor esperado. Si la contraseña es correcta, ambos valores coinciden; si no lo es, el resultado es diferente.

La gestión de errores complica ese modelo aparentemente sencillo. Una implementación puede encontrarse con algoritmos no soportados, parámetros incorrectos, limitaciones de recursos, entradas malformadas o tamaños de contraseña que no está dispuesta a procesar. Tradicionalmente, algunas implementaciones podían señalar esas condiciones devolviendo NULL. Semánticamente resulta claro, porque un puntero nulo no es un hash, pero plantea problemas cuando la aplicación llamante olvida comprobar el valor antes de utilizar funciones de cadenas o comparaciones.

musl modificó este comportamiento de manera que determinadas condiciones de error devolvieran una cadena válida en lugar de NULL. El valor elegido fue *. Desde el punto de vista de la biblioteca, la decisión resultaba razonable porque * no podía representar un hash criptográfico legítimo y, al mismo tiempo, evitaba que programas poco cuidadosos terminaran desreferenciando un puntero nulo.

La implicación de seguridad solo aparece cuando se analiza el ecosistema completo. Las bases de datos de contraseñas ya utilizaban exactamente ese carácter para representar cuentas que no debían aceptar contraseñas. La biblioteca eligió, por tanto, un valor imposible como salida criptográfica válida, pero perfectamente posible como valor almacenado en la base de datos de autenticación.

El segundo comportamiento relevante de musl está relacionado con el tamaño de la contraseña. La implementación afectada de SHA-crypt limita el tamaño de la entrada que está dispuesta a procesar. Una vez que la contraseña supera los 256 bytes, la operación deja de seguir la ruta habitual, se produce un error y ese error termina representándose mediante el valor especial *.

Este límite explica por qué una contraseña corta no desencadena la vulnerabilidad. El atacante necesita superar expresamente el umbral que hace que musl abandone el hashing normal y entre en la ruta de error.

Por qué otra cuenta local puede influir en la autenticación

Uno de los aspectos menos intuitivos de CVE-2026-123158 es que la existencia de otra cuenta local con un hash $5$ o $6$ puede determinar si una identidad cuyo campo contiene * resulta explotable. Para entenderlo hay que remontarse a las protecciones de OpenSSH frente a la enumeración de usuarios mediante diferencias de tiempo.

Los sistemas de autenticación deben tener cuidado no solo con el resultado que devuelven, sino también con el tiempo que necesitan para producirlo. Si un usuario inexistente pudiera rechazarse inmediatamente mientras que un usuario real requiriese ejecutar un cálculo criptográfico costoso, un atacante podría realizar múltiples mediciones y deducir estadísticamente qué nombres de usuario existen, incluso aunque el mensaje de error fuera idéntico en ambos casos.

OpenSSH introdujo mitigaciones para reducir este tipo de diferencias, procurando que las rutas de error realizaran un trabajo computacional comparable al de una comprobación legítima. Eso significa que, incluso cuando la cuenta consultada no contiene un hash de contraseña normal, OpenSSH puede necesitar parámetros adecuados para ejecutar un cálculo ficticio y mantener tiempos de respuesta más uniformes.

Un hash perteneciente a otra cuenta local puede proporcionar esos parámetros. Si OpenSSH obtiene una entrada SHA-256 crypt o SHA-512 crypt, identificada respectivamente por $5$ o $6$, puede terminar llamando a la ruta correspondiente de crypt(). Si la contraseña controlada por el atacante supera entonces la longitud aceptada por musl, el cálculo falla y produce el valor especial que resulta central para la vulnerabilidad.

Esto significa que la explotación no depende únicamente de la cuenta objetivo, sino del estado de la base de datos de autenticación local en su conjunto. Una identidad que contiene * puede no ser explotable en un momento determinado y convertirse en explotable posteriormente porque un administrador crea otra cuenta aparentemente no relacionada y le asigna una contraseña convencional.

Este comportamiento dependiente del estado es una de las características operativas más importantes de la vulnerabilidad. La exposición no puede determinarse únicamente mirando la versión de OpenSSH ni la cuenta objetivo, porque también depende de qué otras cuentas existan en el sistema y de cómo estén representadas sus contraseñas.

Cómo evolucionó el comportamiento vulnerable

CVE-2026-123158 resulta especialmente útil como caso de estudio porque no puede explicarse observando únicamente un commit publicado en 2026. El bypass final aparece como resultado de varias decisiones introducidas durante años, cada una de ellas relacionada con un problema legítimo de seguridad, robustez o administración.

2012: musl modifica la representación de errores en crypt()

Una de las piezas más antiguas se encuentra en la gestión de fallos de crypt(). Devolver NULL es una forma clara de representar un error, pero resulta peligrosa cuando las aplicaciones no comprueban correctamente el valor recibido. Utilizar una cadena especial reduce el riesgo de fallos provocados por llamantes que manipulen el resultado como si siempre fuera un puntero válido.

El marcador seleccionado fue *, una cadena que no debería representar nunca un hash legítimo. Esta decisión resolvía una clase de problemas de robustez, pero introducía sin saberlo una ambigüedad con otro subsistema que ya utilizaba exactamente el mismo valor para representar estados especiales de cuentas.

2012: aparece el límite de 256 bytes

Algunos esquemas de hashing de contraseñas realizan trabajo cuyo coste aumenta con el tamaño de la entrada. Permitir datos arbitrariamente grandes puede convertirse en un problema de denegación de servicio cuando un atacante puede enviar contraseñas diseñadas para consumir recursos de forma innecesaria. La implementación relevante de musl estableció, por tanto, un límite sobre la cantidad de datos que procesaría.

Ese límite se convierte años después en una pieza esencial de CVE-2026-123158, porque determina cuándo la operación deja de producir un hash convencional y pasa a la ruta de error que devuelve *.

2016: OpenSSH mitiga la enumeración de usuarios

OpenSSH 7.3p1 corrigió CVE-2016-6210, una vulnerabilidad relacionada con la posibilidad de distinguir usuarios válidos e inválidos mediante diferencias observables en el tiempo necesario para procesar intentos de autenticación. El problema general consistía en que las cuentas reales podían requerir cálculos de contraseña más costosos que los usuarios inexistentes, proporcionando así un canal lateral de información.

La mitigación buscó que las rutas de error realizasen un trabajo computacional más parecido al de una verificación legítima. Como consecuencia, el proceso de autenticación podía terminar ejecutando operaciones de hashing incluso cuando la identidad solicitada no contenía un hash de contraseña normal.

Años después, ese comportamiento defensivo pasó a formar parte de la cadena necesaria para activar CVE-2026-123158. Esto no significa que la mitigación original fuera conceptualmente incorrecta; demuestra, más bien, que el modelo de amenazas puede cambiar cuando evolucionan los componentes que rodean a una protección.

2016: OpenSSH limita también las contraseñas excesivamente largas

OpenSSH introdujo además protección frente a entradas de contraseña extremadamente grandes capaces de forzar un consumo excesivo de CPU dentro de crypt(). Las solicitudes por encima de 1024 caracteres comenzaron a rechazarse, creando el límite superior que resulta relevante para el bypass actual.

La vulnerabilidad surge así en un espacio muy particular entre dos límites defensivos independientes: musl entra en su ruta de error cuando la contraseña supera 256 bytes, mientras que OpenSSH permite todavía procesar la entrada hasta alcanzar su propio máximo.

Cambios posteriores hacen relevante el valor *

Otra pieza procede de la forma en que determinadas distribuciones representan cuentas diseñadas para utilizar autenticación SSH mediante claves pero sin una contraseña local convencional. En ciertos escenarios de Alpine, utilizar ! podía afectar al comportamiento esperado cuando PAM no estaba implicado, por lo que algunas configuraciones comenzaron a representar esas cuentas mediante *.

Desde la perspectiva administrativa, esas identidades seguían sin poder utilizar una contraseña. La premisa de seguridad era que ninguna operación normal de hashing podría producir el valor *. La ruta de error de musl rompía precisamente esa suposición.

2026: la interacción se identifica finalmente como un bypass

La vulnerabilidad fue comunicada a comienzos de noviembre de 2026 tras comprobarse que una combinación concreta de musl, OpenSSH sin PAM, determinados valores de /etc/shadow, hashes compatibles en otras cuentas y contraseñas largas podía producir autenticaciones exitosas allí donde todas las expectativas convencionales indicaban que debían fallar.

El problema fue reportado el 3 de noviembre y OpenSSH publicó la versión 10.6p2 el día 5, junto con las correspondientes actualizaciones en las distribuciones afectadas. La rapidez de la respuesta resulta comprensible teniendo en cuenta que el fallo podía convertir un error de hashing en una sesión SSH válida.

Por qué importa el rango de 257 a 1024 bytes

El rango asociado a CVE-2026-123158 puede parecer arbitrario a primera vista, pero refleja directamente la interacción entre protecciones implementadas de forma independiente por musl y OpenSSH.

El límite inferior procede de musl. La implementación afectada permite entradas de hasta 256 bytes, pero cuando la contraseña supera ese tamaño la operación falla. Por tanto, una entrada de exactamente 256 bytes sigue encontrándose dentro del límite, mientras que 257 bytes constituye el primer tamaño que fuerza la ruta de error relevante.

El límite superior procede de OpenSSH. Desde las protecciones introducidas años atrás frente a entradas excesivamente grandes, sshd evita procesar contraseñas de tamaño indefinido y rechaza las que superan su propio máximo. El atacante no puede, por tanto, enviar cantidades arbitrarias de datos para provocar el fallo.

La ventana práctica de explotación existe porque musl considera la contraseña demasiado grande en un punto en el que OpenSSH todavía está dispuesto a procesarla. El bypass vive precisamente dentro de esa diferencia semántica entre dos límites que se crearon por motivos de seguridad distintos.

Por esta razón, la descripción más precisa del rango documentado empieza en 257 bytes y no en 256. La condición relevante no es “256 o más”, sino “más de 256”.

Qué consigue realmente un atacante

Si se cumplen todos los prerrequisitos, el impacto es directo y serio: un atacante remoto capaz de conectar con el servicio SSH e identificar un nombre de usuario afectado puede obtener una sesión autenticada válida sin poseer la clave privada SSH de la víctima y sin conocer ninguna contraseña legítima.

No estamos ante un ataque de fuerza bruta ni ante cracking de contraseñas. No es necesario recorrer grandes diccionarios, recuperar hashes o realizar millones de intentos. El atacante tampoco está intentando encontrar el valor originalmente elegido por el propietario de la cuenta; de hecho, la identidad vulnerable puede no tener ninguna contraseña utilizable. El objetivo es conseguir que la operación de verificación falle de una forma concreta y que ese fallo termine siendo interpretado como si coincidiera con el valor almacenado.

El impacto posterior depende por completo de los privilegios y relaciones de confianza asociados a la cuenta comprometida. Una identidad muy restringida puede limitar inicialmente el daño, mientras que una cuenta capaz de ejecutar comandos privilegiados, utilizar doas o mecanismos equivalentes, controlar contenedores, leer secretos, modificar servicios o acceder a credenciales de despliegue puede convertir un bypass de autenticación inicial en compromiso completo del servidor.

Por este motivo, el análisis de exposición no debería terminar al determinar si existe una cuenta técnicamente vulnerable. Es necesario comprender también qué puede hacer esa identidad una vez iniciada la sesión, qué secretos puede leer, qué grupos privilegiados la incluyen, si tiene acceso a claves de otras máquinas y si el servidor proporciona oportunidades de movimiento lateral hacia otros sistemas.

Este punto es especialmente importante en infraestructura moderna, donde una cuenta aparentemente poco privilegiada puede poseer acceso a tokens de automatización, sockets de runtimes de contenedores, credenciales cloud, claves de despliegue, repositorios de configuración o sistemas de CI/CD. El impacto real puede ser mucho mayor que el simple acceso a una shell.

Por qué Alpine Linux es el principal entorno afectado

La vulnerabilidad suele explicarse en el contexto de Alpine Linux, aunque su causa raíz no sea exclusiva de esta distribución. Lo que hace especialmente relevante a Alpine es que reúne de forma natural varios de los requisitos necesarios para alcanzar la ruta vulnerable.

Alpine utiliza musl libc como biblioteca C estándar, proporcionando el comportamiento de crypt() implicado. Su paquete convencional openssh-server se compila sin PAM, lo que significa que OpenSSH participa directamente en la verificación de las contraseñas. Además, la autenticación mediante contraseña puede seguir habilitada salvo que se configure lo contrario, y determinados estados de cuentas pueden utilizar precisamente el marcador *.

Esta combinación convierte a Alpine en el escenario real más importante para CVE-2026-123158 y explica por qué el proyecto publicó recomendaciones específicas y paquetes corregidos para varias ramas, incluidas algunas que se encontraban ya fuera de su ciclo habitual de soporte.

Que root tenga * no implica automáticamente acceso root remoto

La presencia de * en el campo de contraseña de root puede parecer especialmente alarmante, pero debe evaluarse siempre junto con la configuración efectiva de SSH. OpenSSH utiliza habitualmente PermitRootLogin prohibit-password, que impide expresamente la autenticación de root mediante contraseña aunque este método continúe habilitado para otros usuarios.

Por tanto, encontrar * en la cuenta root no significa automáticamente que un servidor Alpine expuesto a Internet pueda ser comprometido directamente como root mediante CVE-2026-123158. Para que eso ocurriera harían falta condiciones adicionales, como permitir explícitamente el acceso root mediante contraseña.

Esto no reduce necesariamente la gravedad del problema. Una cuenta distinta puede acabar proporcionando compromiso total si dispone de permisos de elevación, acceso a credenciales administrativas o control sobre servicios sensibles.

El escenario de las imágenes cloud

Las imágenes cloud constituyen uno de los escenarios más delicados porque muestran claramente cómo una máquina que inicialmente no cumple todos los requisitos puede convertirse en vulnerable posteriormente sin que cambie la versión de OpenSSH.

Determinadas imágenes tiny-cloud de Alpine incluyen una cuenta alpine cuyo campo de contraseña utiliza *. En esas imágenes, el usuario puede además disponer de elevación de privilegios mediante doas sin necesidad de introducir una contraseña. Si el resto de condiciones de CVE-2026-123158 también se encuentran presentes, una autenticación SSH exitosa sobre esa cuenta puede convertirse casi inmediatamente en acceso privilegiado.

Sin embargo, una máquina recién desplegada puede no ser explotable en ese mismo instante. Si no existe ningún usuario local con un hash compatible $5$ o $6$, falta una de las piezas necesarias para alcanzar la ruta vulnerable de musl. El sistema puede, por tanto, parecer seguro justo después del despliegue.

La situación puede cambiar después. Un administrador puede crear una cuenta local adicional, establecer una contraseña para recuperación por consola o realizar cualquier otra modificación que introduzca un hash SHA-256 crypt o SHA-512 crypt. Esa operación aparentemente rutinaria proporciona la pieza que faltaba y puede modificar el estado de exposición del servidor sin tocar OpenSSH.

CVE-2026-123158 constituye así un buen ejemplo de por qué la gestión de vulnerabilidades no puede limitarse siempre al inventario estático de versiones. El software puede permanecer idéntico mientras que la seguridad real del sistema cambia a medida que evolucionan la configuración y las identidades locales.

Un servidor que no era explotable cuando se desplegó puede convertirse en explotable posteriormente sin haber cambiado el paquete OpenSSH. La creación de usuarios y las operaciones de gestión de contraseñas pueden modificar si se cumplen o no todos los prerrequisitos.

Qué sistemas no están afectados

Dado que CVE-2026-123158 depende de una combinación muy específica de implementación y configuración, muchas instalaciones de OpenSSH quedan fuera de la cadena documentada.

Sistemas basados en glibc

El bypass descrito depende del comportamiento concreto de musl dentro de la ruta afectada de crypt(). Sistemas Linux que utilizan glibc no deberían considerarse vulnerables únicamente porque ejecuten una versión antigua de OpenSSH.

OpenSSH utilizando PAM

Cuando la autenticación por contraseña se delega a PAM, la secuencia de verificación es diferente y no se utiliza de la misma forma la ruta OpenSSH-musl implicada en este fallo. La ausencia de PAM es, por tanto, uno de los requisitos relevantes del escenario documentado.

Servidores con PasswordAuthentication deshabilitado

Un sistema configurado con PasswordAuthentication no no expone el mecanismo de autenticación por contraseña necesario para ejecutar esta cadena. Se trata además de una de las medidas compensatorias más efectivas cuando la infraestructura ya utiliza claves SSH u otros mecanismos más fuertes.

Cuentas representadas con otros marcadores

La comparación concreta de CVE-2026-123158 depende de que la cuenta objetivo utilice exactamente el valor *. Identidades cuyo campo tenga otra representación, incluido ! en las condiciones descritas por las guías de la distribución, no cumplen automáticamente el mismo escenario.

Sistemas sin hashes secundarios compatibles

Si no existe ninguna cuenta local con un hash $5$ o $6$ adecuado, OpenSSH puede no disponer de los parámetros necesarios para alcanzar la ruta SHA-crypt vulnerable, aunque la cuenta objetivo contenga *.

Contenedores Alpine sin sshd

Es importante interpretar correctamente los inventarios de contenedores. Que una imagen utilice Alpine como base no significa que CVE-2026-123158 sea explotable remotamente dentro de ella. La mayoría de contenedores de aplicaciones no deberían ejecutar un servidor SSH. Si sshd no está presente o no escucha conexiones, no existe una superficie de autenticación SSH remota que pueda atacarse.

Cómo funciona el parche de OpenSSH

La corrección de OpenSSH resulta especialmente interesante porque no se limita a reducir el tamaño máximo de contraseña para mantenerse por debajo del límite de 256 bytes de musl. Esa solución habría bloqueado el desencadenante conocido, pero habría dejado intacto el problema conceptual: una aplicación de autenticación no debería tratar un marcador de un solo carácter como si fuera un hash válido.

OpenSSH 10.6p2 añade por ello una validación estructural previa. La lógica corregida introduce una longitud mínima para considerar que el campo almacenado puede representar un hash de contraseña:

MIN_PASSWORD_HASH_LEN 4

La propiedad de seguridad importante no es el número cuatro por sí mismo, sino el hecho de que el valor almacenado debe superar ahora una comprobación básica de plausibilidad antes de que una coincidencia pueda considerarse significativa. Un marcador especial de un solo carácter como * no puede representar razonablemente ninguno de los formatos de hash convencionales soportados.

Antes del parche, la ruta vulnerable podía llegar conceptualmente a una situación en la que la decisión final dependía únicamente de si la cadena devuelta por crypt() coincidía con el valor almacenado. Si ambas contenían *, la igualdad podía acabar interpretándose como una contraseña correcta aunque una cadena representase un estado especial de la cuenta y la otra un error.

La nueva lógica añade una barrera semántica antes de esa comparación. El valor almacenado debe parecer primero suficientemente similar a un hash real. Como resultado, aunque musl devuelva * porque una entrada larga ha provocado un fallo, el marcador almacenado se descarta antes de que la igualdad pueda transformarse en autenticación exitosa.

Es una corrección más sólida porque ataca la frontera de confianza entre la base de datos de contraseñas y la función de hashing. OpenSSH deja de asumir que cualquier cadena encontrada en el campo de contraseña puede participar directamente en una comparación criptográfica.

Versiones corregidas y backports

OpenSSH publicó la versión upstream 10.6p2 el 5 de noviembre de 2026. Los sistemas que compilan directamente desde upstream deberían utilizar esa versión o cualquier versión posterior que contenga la misma protección.

La situación resulta algo más compleja en distribuciones Linux, ya que los mantenedores suelen aplicar parches de seguridad mediante backports. Una distribución puede seguir proporcionando una versión upstream numéricamente anterior a 10.6p2 y, aun así, haber incorporado la corrección en su paquete. Esto significa que los escáneres que se limitan a comparar el banner SSH con el número de versión upstream pueden producir falsos positivos.

Alpine publicó paquetes corregidos para múltiples ramas:

Rama Alpine Versión corregida del paquete
edge10.6_p2-r0
3.2410.3_p1-r2
3.2310.2_p1-r1
3.2210.0_p1-r11
3.219.9_p2-r1
3.209.7_p1-r6
3.199.6_p1-r3
3.189.3_p2-r4
3.179.1_p1-r7
3.169.0_p1-r6

Los equipos de gestión de vulnerabilidades deberían comprobar, por tanto, el paquete concreto suministrado por la distribución y no únicamente el banner del servicio. Un servidor que anuncie una versión 9.x puede estar protegido si el proveedor ha aplicado el parche mediante backport, mientras que una compilación manual puede seguir siendo vulnerable aunque la base de datos de paquetes del sistema aparentemente se encuentre actualizada.

Durante una evaluación resulta útil distinguir tres elementos diferentes: la versión anunciada por el servicio SSH, la versión del paquete instalada por el sistema operativo y el código que está ejecutando realmente el proceso en memoria. Los tres pueden influir en la conclusión final.

Detección e investigación de incidentes

Una de las características más útiles de CVE-2026-123158 desde el punto de vista defensivo es que una explotación exitosa contradice directamente el estado esperado de la cuenta. Una identidad cuyo campo de contraseña contiene exactamente * no debería completar nunca una autenticación ordinaria mediante contraseña. Por tanto, encontrar un registro de SSH que muestre Accepted password para una cuenta que no dispone de una contraseña válida constituye una señal especialmente fuerte de actividad anómala.

En sistemas Alpine, este tipo de actividad puede aparecer en los registros habituales de autenticación. La investigación debería correlacionar los eventos de autenticación exitosa con el estado real de las cuentas en /etc/shadow. Un evento de contraseña aceptada para una identidad cuyo campo no puede representar un hash legítimo es incompatible con el modelo de autenticación previsto.

La detección no debería limitarse a buscar un único nombre de usuario conocido. Una estrategia más robusta consiste en identificar primero todas las cuentas cuyo campo de contraseña sea exactamente *, determinar cuáles pueden iniciar sesión mediante SSH y buscar posteriormente eventos de autenticación por contraseña asociados a ellas.

Si se identifica un acceso sospechoso, o si los registros disponibles no permiten descartarlo, la investigación debe ampliarse más allá del evento inicial. Una vez que un atacante obtiene una sesión interactiva, sus acciones posteriores pueden no contener ninguna característica específica de CVE-2026-123158.

Entre los elementos que conviene revisar se encuentran:

  • nuevas entradas o modificaciones en authorized_keys;
  • usuarios o grupos creados recientemente;
  • cambios inesperados en grupos administrativos;
  • uso de doas, sudo u otros mecanismos de elevación de privilegios;
  • modificaciones en la configuración de SSH o en archivos de autenticación;
  • persistencia mediante servicios, tareas programadas, scripts de inicio o perfiles de shell;
  • procesos inesperados ejecutados después del acceso sospechoso;
  • nuevos servicios escuchando conexiones;
  • conexiones salientes hacia destinos inusuales;
  • acceso a credenciales cloud, tokens, API keys, claves SSH o secretos de aplicaciones;
  • modificaciones en runtimes de contenedores o credenciales de orquestación;
  • alteración o eliminación de registros.

La decisión de respuesta debe considerar especialmente los privilegios de la cuenta comprometida. Si la identidad disponía de permisos administrativos sin contraseña o podía acceder a credenciales pertenecientes a usuarios más privilegiados, debería asumirse que el atacante pudo avanzar más allá de la cuenta inicial. En ese escenario, aplicar el parche posteriormente no es suficiente para recuperar automáticamente la confianza en el sistema.

Mitigación y remediación

Instalar el paquete de OpenSSH corregido

La medida principal consiste en instalar el paquete corregido proporcionado por el sistema operativo o utilizar OpenSSH 10.6p2 o posterior cuando corresponda. En general, conviene utilizar el paquete oficial de la distribución en lugar de sustituir manualmente OpenSSH, ya que este incluye las dependencias, configuraciones y backports de seguridad adaptados al entorno.

También debe tenerse en cuenta que actualizar los archivos en disco no implica necesariamente reemplazar el código que ya se encuentra cargado dentro de un daemon en ejecución. Después de actualizar el paquete es necesario reiniciar sshd siguiendo el procedimiento recomendado por la distribución para garantizar que el proceso activo ejecuta la versión corregida.

Deshabilitar la autenticación mediante contraseña cuando no sea necesaria

Cuando operativamente sea posible, configurar:

PasswordAuthentication no

elimina por completo la ruta de autenticación necesaria para esta vulnerabilidad. El caso resulta además un buen ejemplo de la diferencia entre “no utilizar” una funcionalidad y deshabilitarla realmente. Una organización puede afirmar que sus administradores utilizan únicamente claves SSH y, sin embargo, mantener todavía disponible la autenticación mediante contraseña porque nunca modificó la configuración por defecto.

Antes de aplicar este cambio en sistemas remotos, debe comprobarse que el acceso mediante claves funciona correctamente y que existe un procedimiento alternativo de recuperación. Una medida de hardening que bloquee accidentalmente a los administradores legítimos puede generar un problema de disponibilidad.

Restringir la exposición de SSH

El servicio SSH debería estar accesible únicamente desde las redes y sistemas que realmente necesiten administración remota. Bastion hosts, VPN, redes de gestión, reglas de firewall y listas de acceso reducen la cantidad de clientes capaces de alcanzar sshd.

Restringir la red no sustituye la actualización, pero puede reducir considerablemente la explotabilidad mientras se despliega la corrección y proporciona además defensa en profundidad frente a vulnerabilidades futuras del mismo servicio.

Revisar el estado de las cuentas locales

Los administradores deberían identificar las cuentas cuyo campo de contraseña contiene marcadores especiales, especialmente aquellas con exactamente *, y confirmar que el estado sea intencionado. También conviene revisar qué usuarios disponen de hashes $5$ o $6$, ya que su existencia puede formar parte de las condiciones que permiten alcanzar la ruta vulnerable.

Esto no significa que deban modificarse manualmente las entradas de /etc/shadow sin comprender su función. Los marcadores pueden tener semánticas específicas de cada distribución, y cambiarlos sin seguir la documentación del proveedor puede romper el acceso mediante claves u otros mecanismos legítimos. El objetivo inicial debe ser comprender el estado del sistema y aplicar la corrección soportada oficialmente.

Comprobar la configuración efectiva de sshd

Leer únicamente un fichero sshd_config no siempre permite saber qué configuración aplica realmente el servidor. OpenSSH puede utilizar includes, valores definidos por la distribución, bloques Match y condiciones específicas para determinados usuarios, grupos o direcciones de origen.

Una revisión debería comprobar al menos los valores efectivos de:

  • PasswordAuthentication;
  • UsePAM;
  • PermitRootLogin;
  • los métodos de autenticación habilitados;
  • cualquier bloque Match específico por usuario o grupo.

La cuestión relevante desde el punto de vista de seguridad no es qué cree el administrador que configuró, sino qué permitirá realmente el daemon para la identidad que está siendo evaluada.

Estado actual de explotación

A fecha de 6 de noviembre de 2026, existe información pública de prueba de concepto para CVE-2026-123158, lo que hace que el comportamiento técnico sea accesible tanto para defensores como potencialmente para atacantes. El enriquecimiento público del CVE refleja la existencia de PoC y un impacto técnico potencialmente serio cuando se cumplen todas las condiciones necesarias.

En el momento de redactar este artículo no existe evidencia pública confirmada de una explotación masiva en entornos reales, y la vulnerabilidad no figura en el catálogo Known Exploited Vulnerabilities. Esta ausencia debe interpretarse con cautela. Que una vulnerabilidad no se encuentre todavía en un catálogo de explotación confirmada no significa que sea imposible explotarla ni que pueda retrasarse su corrección; únicamente significa que la evidencia disponible no cumple todavía los criterios establecidos para considerarla explotada activamente a escala.

Desde una perspectiva ofensiva, la vulnerabilidad resulta atractiva porque el servicio SSH suele ser accesible remotamente, no requiere autenticación previa y una explotación exitosa puede producir una sesión válida. Al mismo tiempo, su principal limitación son los prerrequisitos ambientales tan específicos, lo que explica que no deba tratarse como un bypass universal aplicable a cualquier servidor OpenSSH.

La priorización debería basarse por ello en la exposición real. Un sistema Alpine accesible desde Internet, sin PAM, con autenticación por contraseña habilitada y cuentas compatibles merece una atención mucho mayor que un entorno interno basado en glibc, con PAM o con la autenticación por contraseña completamente deshabilitada.

Lecciones de seguridad de CVE-2026-123158

1. Las fronteras entre componentes también son superficies de seguridad

Una de las principales lecciones de la vulnerabilidad es que el software no funciona de forma aislada. OpenSSH, musl libc, las bases de datos de contraseñas Unix, la distribución Linux y las herramientas de gestión de cuentas realizan suposiciones sobre el significado de los valores que intercambian. Un valor seguro dentro de un componente puede volverse peligroso cuando otro componente le asigna una semántica diferente.

Las revisiones de seguridad deberían analizar no solo si cada función se comporta correctamente, sino también si los contratos entre componentes son explícitos y no admiten ambigüedades.

2. Los errores no deberían parecer valores válidos del dominio

El uso de * muestra el riesgo de representar una condición excepcional mediante un valor ordinario del mismo tipo de datos que un resultado válido. Desde el punto de vista de la aplicación, tanto un hash de contraseña como el marcador de error son cadenas. Sin una validación adicional, el tipo de dato no permite diferenciar ambos conceptos.

En interfaces sensibles, resulta más seguro representar los errores fuera del canal de datos normal mediante códigos específicos, estructuras etiquetadas u otros mecanismos que impidan comparar accidentalmente una condición de fallo con un valor aparentemente válido.

3. Las mitigaciones de seguridad pueden interactuar de formas inesperadas

Parte del comportamiento de OpenSSH implicado en la vulnerabilidad fue consecuencia de defensas introducidas años antes frente a enumeración de usuarios por temporización y ataques de consumo de recursos. Aquellas medidas solucionaban problemas legítimos, pero terminaron participando en una vulnerabilidad distinta cuando se combinaron con otras decisiones de implementación.

Esto no supone un argumento contra el hardening, sino a favor de modelos de amenazas que evolucionen junto con el software. Una corrección de seguridad debería analizarse no solo por el fallo inmediato que resuelve, sino también por los nuevos estados y rutas de ejecución que introduce.

4. El estado de vulnerabilidad puede cambiar sin actualizar software

CVE-2026-123158 demuestra que la explotabilidad de un sistema puede depender de datos mutables. Crear un usuario, establecer una contraseña, cambiar un marcador de cuenta o modificar la configuración SSH puede convertir un host previamente no explotable en vulnerable aunque el binario de OpenSSH permanezca exactamente igual.

La gestión continua de exposición necesita, por tanto, algo más que inventarios de versiones. La configuración y el estado de las identidades pueden ser tan importantes como el software instalado.

5. Los backports complican el análisis basado únicamente en versiones

Los escáneres de seguridad suelen inferir vulnerabilidades comparando banners de servicios con rangos de versiones upstream. Esta estrategia falla cuando una distribución aplica backports sin sustituir la versión principal por la release upstream donde apareció originalmente la corrección.

La cuestión realmente importante es si el parche relevante se encuentra dentro del paquete instalado, no si el banner muestra un número superior a OpenSSH 10.6p2.

6. Los mecanismos de autenticación innecesarios deberían deshabilitarse

Una organización puede utilizar operativamente únicamente claves SSH y, aun así, mantener habilitada la autenticación mediante contraseña. Mientras una funcionalidad siga disponible, continúa formando parte de la superficie de ataque. Esta vulnerabilidad recuerda que reducir superficie requiere configuración explícita y no únicamente una convención operativa.

7. Una cuenta “sin contraseña” sigue teniendo estado de seguridad relacionado con contraseñas

Que una identidad no disponga de una contraseña utilizable no significa que su campo de contraseña sea irrelevante. Los marcadores almacenados son consumidos por distintos componentes y pueden modificar el comportamiento de la autenticación. La representación concreta del estado “sin contraseña” importa especialmente cuando varias capas del sistema interpretan el mismo valor de forma diferente.

Preguntas frecuentes

¿Qué es CVE-2026-123158?

CVE-2026-123158 es un bypass de autenticación por contraseña en OpenSSH que afecta a determinados entornos Linux con musl libc, OpenSSH sin PAM, autenticación por contraseña habilitada y estados concretos en las cuentas locales. Bajo estas condiciones, una contraseña excesivamente larga puede hacer que un error del proceso de hashing coincida con el valor especial * almacenado para una cuenta que no debería poseer una contraseña válida.

¿Afecta a todos los servidores OpenSSH anteriores a 10.6p2?

No. La corrección upstream está incluida en OpenSSH 10.6p2, pero la explotabilidad depende de muchos más factores que la versión. El escenario documentado necesita musl libc, ausencia de PAM, autenticación mediante contraseña habilitada, una cuenta objetivo adecuada y condiciones adicionales en la base de datos local de contraseñas.

¿Afecta a Debian, Ubuntu, Fedora u otras distribuciones basadas en glibc?

La cadena documentada depende del comportamiento concreto de crypt() en musl y de una ruta de OpenSSH sin PAM. Las instalaciones habituales de distribuciones basadas en glibc no cumplen de forma natural estos requisitos y no deberían considerarse afectadas únicamente por utilizar OpenSSH.

¿Por qué funciona una contraseña demasiado larga?

La contraseña larga no se convierte en la contraseña correcta. Su objetivo es superar el límite de entrada de la implementación afectada de musl. Cuando eso ocurre, el hashing falla y puede devolver *. Si el campo de contraseña de la cuenta objetivo contiene también exactamente *, una comparación mal interpretada puede considerar ambos valores iguales.

¿Por qué la explotación empieza en 257 bytes?

Porque la condición relevante aparece cuando la contraseña supera los 256 bytes. Una entrada de exactamente 256 bytes sigue dentro del límite, mientras que 257 es el primer tamaño que lo supera.

¿Por qué existe un límite superior de aproximadamente 1024 caracteres?

OpenSSH ya incorporaba medidas de protección frente a contraseñas excesivamente grandes utilizadas para provocar cálculos costosos dentro de crypt(). Este límite impide que el atacante envíe entradas de tamaño indefinido y crea el extremo superior del rango explotable.

¿Por qué hace falta otra cuenta con un hash $5$ o $6$?

La cuenta objetivo con * no contiene un algoritmo o una sal convencional. Como parte de las medidas para reducir diferencias de tiempo, OpenSSH puede obtener parámetros de hashing de otra cuenta y realizar un cálculo ficticio. Un hash $5$ o $6$ permite alcanzar la ruta SHA-crypt de musl en la que aparece el límite de longitud.

¿Todos los contenedores Alpine son vulnerables?

No. El contenedor debe ejecutar realmente sshd y cumplir las condiciones de autenticación necesarias. La mayoría de contenedores de aplicaciones no ejecutan un servidor SSH, por lo que no existe una superficie de autenticación remota sobre la que explotar este fallo.

¿Puede proporcionar acceso root directamente?

No de forma automática. Aunque root pueda tener * en el campo de contraseña, OpenSSH suele impedir el acceso root mediante contraseña utilizando PermitRootLogin prohibit-password. Serían necesarias condiciones adicionales para obtener root directamente. Sin embargo, una cuenta no root puede acabar conduciendo a compromiso total si dispone de privilegios elevados o acceso a credenciales sensibles.

¿Cómo debe corregirse?

La recomendación es instalar el paquete OpenSSH corregido de la distribución o utilizar OpenSSH 10.6p2 o posterior y reiniciar posteriormente sshd para asegurarse de que el proceso activo ejecuta el código parcheado. Cuando la actualización inmediata no sea posible, deshabilitar PasswordAuthentication elimina la ruta documentada de explotación.

¿Es suficiente con instalar el paquete actualizado?

No siempre. Actualizar los archivos del paquete en disco no sustituye automáticamente el código que ya se encuentra ejecutándose dentro de un proceso existente. El servicio debe reiniciarse de acuerdo con el procedimiento soportado por el sistema operativo para garantizar que el daemon utiliza la versión corregida.

¿Existen pruebas de concepto públicas?

Sí. A fecha de 6 de noviembre de 2026 existe información pública de prueba de concepto. Esto aumenta la importancia de identificar rápidamente los entornos realmente expuestos, aunque la vulnerabilidad requiera más condiciones que un bypass genérico de OpenSSH.

¿Se está explotando activamente CVE-2026-123158?

En el momento de redactar este artículo no existe evidencia pública confirmada de explotación masiva en entornos reales y CVE-2026-123158 no figura en el catálogo Known Exploited Vulnerabilities. Dado que la vulnerabilidad acaba de publicarse y existe información técnica pública, este estado debe monitorizarse y no asumirse como permanente.

Conclusión

CVE-2026-123158 es un buen ejemplo de por qué algunas de las vulnerabilidades más interesantes no pueden atribuirse a una única línea de código obviamente incorrecta. El fallo apareció porque varios componentes realizaron suposiciones razonables de forma independiente que dejaron de ser seguras al combinarse: musl necesitaba una forma más robusta de representar errores de crypt(), las bases de datos Unix ya utilizaban * para representar cuentas sin contraseñas válidas, OpenSSH necesitaba realizar cálculos ficticios para reducir la enumeración de usuarios mediante temporización, existían límites sobre el tamaño de las contraseñas para evitar abusos de recursos y las distribuciones necesitaban representar de forma práctica cuentas destinadas exclusivamente a autenticación mediante claves.

La vulnerabilidad aparece precisamente en la frontera entre todas esas decisiones. La biblioteca de hashing puede devolver * porque la contraseña es demasiado larga, mientras que la base de datos de cuentas puede contener * porque no existe una contraseña válida. Cuando esos valores llegan a una lógica de autenticación que interpreta la igualdad como evidencia suficiente de una contraseña correcta, dos estados semánticamente opuestos terminan colapsando en la misma representación textual.

Esto convierte el fallo en algo más instructivo que un simple error de implementación. Demuestra la importancia de validar no solo los valores de los datos, sino también aquello que esos valores representan realmente. Un hash de contraseña, un marcador de estado de cuenta y un indicador de error pueden ser cadenas de texto desde el punto de vista del lenguaje de programación, pero no son conceptos de seguridad intercambiables.

También muestra por qué una evaluación de vulnerabilidades no debería limitarse a comparar números de versión. La exposición real depende de la biblioteca C, de la integración con PAM, de la configuración efectiva de SSH, de la base de datos local de usuarios, de los formatos de hashes presentes, de la accesibilidad de red y de los privilegios de las cuentas susceptibles. En algunos sistemas el fallo puede resultar irrelevante; en otros, exactamente la misma vulnerabilidad puede proporcionar un camino desde una conexión de red no autenticada hasta una shell interactiva y, potencialmente, hasta el compromiso completo del host.

Para los equipos defensivos, la respuesta inmediata es relativamente clara: identificar sistemas basados en musl, comprobar los paquetes corregidos proporcionados por la distribución, reiniciar el daemon SSH después de actualizar, deshabilitar la autenticación por contraseña cuando no sea necesaria e investigar cualquier inicio de sesión mediante contraseña asociado a cuentas que no deberían poseer una contraseña válida. La lección más amplia es igualmente importante: la seguridad no depende únicamente de que cada componente funcione correctamente por separado, sino también de que las suposiciones realizadas en las fronteras entre esos componentes sigan siendo válidas cuando el sistema evoluciona.

Referencias

← Volver a Artículos