OpenSSH arrastraba desde hace unos quince años un fallo en cómo trata los nombres de principal dentro de los certificados SSH. Lo descubrió la firma Cyera y se publicó el 22 de abril de 2026 bajo el nombre SplitSSHell, con identificador CVE-2026-35414 y una puntuación CVSS de 8.1. La corrección llegó en OpenSSH 10.3.
Qué es exactamente el fallo
El problema nace de dos partes del código que leen lo mismo de forma distinta. Cuando OpenSSH negocia la sesión, una función parte el campo de principals del certificado por comas, tratándolo como una lista. Pero la función que comprueba la autorización en authorized_keys lo lee como una sola cadena, sin separar nada.
Esa discrepancia es la grieta. Si una autoridad certificadora (CA) de confianza emite un certificado cuyo principal contiene una coma, por ejemplo deploy,root, las dos rutas del código discrepan. Una ve un único principal llamado literalmente deploy,root; la otra ve dos: deploy y root. El resultado es que alguien a quien solo se pretendía dar acceso como deploy acaba colándose como root en servidores vulnerables.
A quién afecta
A cualquier despliegue que use autenticación por certificados SSH con la opción principals= en authorized_keys o en los ficheros de principals autorizados. Es un patrón habitual en infraestructuras grandes que firman certificados de corta duración con una CA central en lugar de repartir claves públicas a mano.
Hace falta un certificado válido firmado por una CA en la que el servidor confíe. No es un ataque que cualquiera lance desde internet sin más: el atacante necesita que la CA le emita un certificado con el principal manipulado, o controlar de algún modo ese proceso de emisión. Aun así, en organizaciones donde varias personas o sistemas piden certificados a la misma CA, el margen para abusar es real.
Hay un detalle que lo vuelve peor. El bypass no deja un fallo de autenticación en los logs, así que la detección basada en registros pasa por alto el intento. Tendrías un acceso root no autorizado sin rastro evidente de que algo fue mal.
Gravedad y mitigación
Con CVSS 8.1 y un impacto que llega hasta root, conviene tratarlo como prioritario en cualquier servidor que dependa de certificados SSH. La vía recomendada es directa: actualizar a OpenSSH 10.3 o posterior, donde ambas partes del código ya interpretan los principals de la misma manera.
Si no puedes actualizar de inmediato, repasa las políticas de tu CA y asegúrate de que ningún principal contiene comas ni caracteres que puedan interpretarse como separadores de lista. Restringe qué principals admite cada CA de confianza y audita los certificados ya emitidos. También ayuda revisar quién puede pedir certificados y con qué nombres, porque ahí está el origen del abuso.
Que un fallo así sobreviviera tres lustros en una pieza tan revisada como OpenSSH recuerda que la coherencia entre cómo se valida y cómo se autoriza un dato importa tanto como la criptografía que hay debajo.