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.