# SplitSSHell: una coma en los certificados SSH abría root en OpenSSH (CVE-2026-35414)

- **Publicado el:** 2026-04-22
- **Categoría:** Seguridad
- **Página original:** https://linuxgratis.com/articulos/cve-2026-35414-splitsshell-openssh-principals-coma-auth-bypass

Un fallo de 15 años en OpenSSH dejaba que un certificado con un principal tipo 'deploy,root' saltara el control de acceso y autenticara como root. Se corrige en OpenSSH 10.3.

---

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.

## Fuente

- [SecurityWeek — OpenSSH Flaw Allowing Full Root Shell Access Lurked for 15 Years](https://www.securityweek.com/openssh-flaw-allowing-full-root-shell-access-lurked-for-15-years/)
- [NVD — CVE-2026-35414](https://nvd.nist.gov/vuln/detail/CVE-2026-35414)