# SplitSSHell: una coma als certificats SSH obria root a OpenSSH (CVE-2026-35414)

- **Publicat el:** 2026-04-22
- **Categoria:** Seguretat
- **Pàgina original:** https://linuxgratis.com/ca/articles/cve-2026-35414-splitsshell-openssh-principals-coma-auth-bypass

Un error de 15 anys a OpenSSH deixava que un certificat amb un principal tipus 'deploy,root' saltés el control d'accés i autentiqués com a root. Es corregeix a OpenSSH 10.3.

---

OpenSSH arrossegava des de fa uns quinze anys un error en com tracta els noms de principal dins dels certificats SSH. El va descobrir la firma Cyera i es va publicar el 22 d'abril de 2026 amb el nom **SplitSSHell**, identificador **CVE-2026-35414** i una puntuació CVSS de 8.1. La correcció va arribar a **OpenSSH 10.3**.

## Què és exactament l'error

El problema neix de dues parts del codi que llegeixen el mateix de manera diferent. Quan OpenSSH negocia la sessió, una funció parteix el camp de principals del certificat per comes i el tracta com una llista. En canvi, la funció que comprova l'autorització a `authorized_keys` el llegeix com una sola cadena, sense separar res.

Aquesta discrepància és l'esquerda. Si una autoritat certificadora (CA) de confiança emet un certificat amb un principal que conté una coma, per exemple `deploy,root`, les dues rutes del codi no coincideixen. Una hi veu un únic principal anomenat literalment `deploy,root`; l'altra n'hi veu dos: `deploy` i `root`. El resultat és que algú a qui només es volia donar accés com a `deploy` acaba entrant com a `root` en servidors vulnerables.

## A qui afecta

A qualsevol desplegament que faci servir autenticació per certificats SSH amb l'opció `principals=` a `authorized_keys` o als fitxers de principals autoritzats. És un patró habitual en infraestructures grans que signen certificats de curta durada amb una CA central en lloc de repartir claus públiques a mà.

Cal un certificat vàlid signat per una CA en què el servidor confiï. No és un atac que qualsevol llanci des d'internet sense més: l'atacant necessita que la CA li emeti un certificat amb el principal manipulat, o controlar d'alguna manera aquest procés d'emissió. Tot i així, en organitzacions on diverses persones o sistemes demanen certificats a la mateixa CA, el marge per abusar-ne és real.

Hi ha un detall que ho empitjora. El bypass no deixa cap error d'autenticació als logs, així que la detecció basada en registres ignora l'intent. Tindries un accés root no autoritzat sense cap rastre evident que res hagi anat malament.

## Gravetat i mitigació

Amb CVSS 8.1 i un impacte que arriba fins a root, val la pena tractar-lo com a prioritari en qualsevol servidor que depengui de certificats SSH. La via recomanada és directa: actualitzar a **OpenSSH 10.3** o posterior, on totes dues parts del codi ja interpreten els principals de la mateixa manera.

Si no pots actualitzar de seguida, repassa les polítiques de la teva CA i assegura't que cap principal conté comes ni caràcters que es puguin interpretar com a separadors de llista. Restringeix quins principals admet cada CA de confiança i audita els certificats ja emesos. També ajuda revisar qui pot demanar certificats i amb quins noms, perquè aquí és on comença l'abús.

Que un error així sobrevisqui tres lustres en una peça tan revisada com OpenSSH recorda que la coherència entre com es valida i com s'autoritza una dada compta tant com la criptografia que hi ha a sota.

## Font

- [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)