El butlletí TS-2026-014 de Tailscale, del 26 d'octubre, cap en una frase: el servidor SSH «validated Unix socket paths lexically but would perform the operations as root». Comprovava un nom i després obria el fitxer amb els permisos del dimoni, que és root. Entre comprovar i obrir hi cap una cursa. A l'altre costat, diu el mateix butlletí, hi ha «root-only sockets such as the Docker socket or the tailscaled local API». El pedaç va arribar ahir a la nit: l'etiqueta v1.104.4 es va crear el 27 d'octubre a les 23:01 UTC. Però la fallada concreta no és el que ens interessa. El que ens interessa és la pregunta que deixa damunt la taula: als teus servidors, qui decideix qui és root?
Els quatre butlletins, en una taula
Tailscale en va publicar quatre el mateix dia. Tots quatre es corregeixen a la mateixa versió. Val la pena llegir-los junts perquè dos no són d'SSH, i molta gent tancarà la pestanya en arribar a «és una fallada de Tailscale SSH, jo això no ho faig servir».
Tots quatre diuen el mateix al peu: «fixed in Tailscale version 1.104.4 or newer». Al repositori públic no hi ha etiqueta 1.104.3: se salta directament de la 1.104.2 a la 1.104.4, i entre totes dues hi ha 42 confirmacions. Hi tornarem, perquè expliquen més que les notes.
La frase que explica els quatre
El dimoni tailscaled s'executa com a root en una instal·lació normal sobre Linux —hi ha un mode de xarxa en espai d'usuari, però no és el que tens al servidor—, i per al que fa el necessita: crea una interfície de xarxa, escriu rutes i toca el tallafocs del sistema. Això no és un defecte de disseny, és el preu que es paga perquè una VPN «simplement funcioni» sense demanar-te res. Però converteix el dimoni en el subjecte de totes les operacions que fa en nom teu. Quan aquest procés rep d'un parell una petició del tipus «obre'm aquest socket» i decideix si val mirant el text de la ruta, el que queda al mig és la distància entre comprovar i actuar.
Aquesta distància té nom des de fa dècades i es guanya canviant el que hi ha darrere del nom en el moment just: un enllaç simbòlic que apunta a un lloc innocu quan es comprova i a un altre quan s'obre. El butlletí TS-2026-016 ho descriu sense embuts a l'altra funció afectada: el guàrdia contra enllaços simbòlics «only ran during configuration reload rather than per dial». Es comprovava un cop, al principi, i després es confiava.
Per què «el socket de Docker» és la part seriosa
El butlletí posa dos exemples de «socket de només root» i no són equivalents.
- El socket de Docker. Qui pot escriure a
/var/run/docker.sockpot demanar al dimoni de Docker que arrenqui un contenidor amb el sistema de fitxers de l'amfitrió muntat a dins. Això no és «accés a Docker»: és root a la màquina, per disseny i documentat de sempre. En un servidor d'aplicacions aquest fitxer hi és. - L'API local de tailscaled. És la que fa servir la mateixa ordre
tailscaleper parlar amb el dimoni. Qui hi arriba mana sobre la pertinença del node a la xarxa. Per aquesta via, el butlletí TS-2026-016 —el deserve, no el d'SSH— ho diu pel seu nom: «full node takeover».
El reenviament de sockets Unix per SSH és vell i avorrit: existeix des d'OpenSSH 6.7, de l'octubre del 2014, i es fa servir cada dia per arribar a una base de dades sense publicar-la. La diferència, aquí, és qui obria l'altre extrem. A l'SSH de sempre l'obre un procés que ja porta la teva identitat. En aquest cas l'obria el dimoni.
La pregunta de debò: qui decideix qui és root a la teva màquina?
L'SSH de sempre reparteix aquesta decisió entre coses que viuen a la teva màquina: la configuració de sshd, les claus d'authorized_keys, PAM, els grups i sudoers. Són fitxers. Es llegeixen, es versionen i s'auditen sense demanar permís a ningú.
Tailscale SSH treu tot això del camí. No hi ha claus per repartir ni authorized_keys per mantenir: aquest és l'argument de venda, i és bo de debò —qui hagi heretat un parc amb claus d'un becari del 2019 sap de què parlem—. A canvi, qui entra i com a quin usuari ho decideix una regla a la política del tailnet, que viu al pla de control. I com que la connexió no l'acaba sshd sinó tailscaled, el procés que t'obre la sessió és el mateix que porta la VPN.
És una decisió d'arquitectura legítima. El que cal és saber que s'ha pres, perquè canvia tres coses alhora: on s'escriu la regla, qui pot canviar-la i què passa quan aquesta capa té una fallada. La tercera es va respondre sola el cap de setmana passat. Les altres dues les continues responent tu.
Hi ha un detall a la documentació que ho deixa més clar que qualsevol butlletí, i gairebé ningú l'ha llegit. El «mode de comprovació» de Tailscale SSH exigeix tornar a autenticar-se —amb MFA, si la tens configurada— abans d'obrir sessió. Sona exactament al que vols. La lletra petita és aquesta, literal: «Once re-authenticated to a destination, the user can access the device and any other device in the tailnet without re-verification for the next 12 hours». I el període per defecte són dotze hores. La comprovació, tret que escriguis un checkPeriod propi per a aquella connexió, és per persona i per xarxa, no per màquina. És la mateixa conversa que vam tenir quan vam escriure que un túnel entre seus no té a qui demanar-li un segon factor: el segon factor protegeix el moment d'entrar, no el que hi ha darrere.
D'aquí surt la frase que ens enduem nosaltres: una malla no és segmentació. El que decideix què arriba a què dins d'una malla és una llista de regles. Si aquesta llista diu «els portàtils de l'equip arriben als servidors», la malla fa exactament el que li vas demanar, i el portàtil compromès també.
El que explica el pedaç
Les correccions de seguretat es llegeixen millor al codi que a la nota. Entre la 1.104.2 i la 1.104.4 hi ha 42 confirmacions i trenta toquen el mateix directori, ssh/tailssh. No són pedaços puntuals: és un canvi de forma. Els títols ho expliquen sols —«route SSH forwarding through the privileged monitor», «dial TCP forwards as the bound user», «relay Unix forward payloads as the bound user», «launch sessions via the monitor», «enforce SSH policy at the connection level»—. Dit clar: ja no es comprova un nom i s'actua com a root; s'actua com qui ho va demanar, i el poc que necessita privilegi passa per un sol lloc que el concedeix. És la manera correcta de fer-ho, i ha calgut un cap de setmana de feina per arribar-hi.
Dins d'aquest mateix diff hi ha tres coses que no han sortit a cap titular i que a nosaltres ens semblen més interessants que el root:
- La gravació de la sessió podia no coincidir amb el que es va executar. Una confirmació explica que la capçalera de la gravació desava «una reconstrucció de l'ordre analitzada per l'intèrpret», quan l'ordre es passa al shell de l'usuari tal qual, i que l'analitzador «descarta en silenci les cometes desaparellades». La correcció és desar l'ordre en brut. Si arxives aquestes gravacions per a una auditoria o per a un informe d'incident, això no és un detall: és la diferència entre una prova i un document que et pensaves que era prova.
- La mateixa correcció ja es va escriure a OpenSSH, fa deu anys. Les notes de la versió 7.4 d'OpenSSH, del 19 de desembre del 2016, diuen això: «When privilege separation is disabled, forwarded Unix-domain sockets would be created by sshd(8) with the privileges of 'root' instead of the authenticated user». Ho va reportar Jann Horn, de Project Zero. La mateixa fallada, al mateix lloc. I el que OpenSSH hi va posar al mig va ser el seu monitor de separació de privilegis, que és exactament on ha arribat Tailscale: el commit que vertebra la 1.104.4 es titula «route SSH forwarding through the privileged monitor». Al mateix diff hi va l'altra reincidència, la de les variables d'entorn: la llista de prohibides es va ampliar amb
GCONV_PATH,LOCPATH,NLSPATH,HOSTALIASES,RES_OPTIONSi, en una altra confirmació,GLIBC_TUNABLES, els clàssics perquè un procés privilegiat carregui un fitxer que tries tu. - I les coses petites, que són les que delaten la pressa. Les claus privades d'amfitrió s'escrivien sense permisos 0600. Van caldre tres confirmacions diferents perquè la funció que respon «això és root?» entengués el mateix a tots els llocs on se la crida; una es titula «treat numerically-zero uids as root in isRootUser».
El que això no és
Tres acotacions, perquè el titular es presta a anar més lluny del que aguanten els fets.
No és un atacant anònim des d'internet. Cal controlar ja un dispositiu al qual la teva política permet connectar-se al destí. Ho diu el VP d'enginyeria de Tailscale, Mike Shaver: la majoria dels problemes «concern what happens after someone has been authorized to connect, particularly how Unix privileges and SSH forwarding are handled», i «it isn't the same as an unauthenticated attacker being able to connect to arbitrary machines, but the potential impact depends on how SSH access is configured». Ens sembla una descripció honesta i la subscrivim. També és, exactament, l'escenari per al qual es compra una malla zero trust. El que sí que és, i convé dir-ho al mateix paràgraf: encadenable. A les proves de laboratori el salt de màquina a màquina va ser automàtic, per sota del segon per salt i sense intervenció de ningú, fins on la política concedís SSH, i d'allà van sortir tant accés de root als destins com claus amb què donar d'alta dispositius nous a la xarxa. El radi d'acció el fixa la teva taula de regles, no la gravetat del butlletí.
Tailscale SSH no ve activat. Cal fer dues coses: executar tailscale set --ssh al destí i escriure una regla ssh a la política. Si no has fet les dues, el 014 i el 015 no et toquen. El 016 i el 017 són de tailscale serve, que és una altra funció i també s'activa a part. I Tailscale no recomana que tothom ho apagui: «based on our current assessment, we're not recommending that everyone disable Tailscale SSH». Nosaltres tampoc.
I una opinió, etiquetada com a tal. L'informe que va destapar això es diu Tailworm, el signa Erica Windisch (Cyberdione Labs) i recull onze troballes sobre Tailscale 1.104.2 i headscale 0.29.5, sis de severitat alta i quatre d'aquestes sis a Tailscale SSH. Es va publicar el diumenge 25, sense versió corregida disponible. La investigadora va enviar l'informe i la prova de concepte al contacte de seguretat del fabricant abans de publicar; el que no va fer va ser esperar que hi hagués pedaç. El pedaç es va etiquetar dimarts a la nit. Al mig van quedar dos dies amb el mapa publicat i sense versió per aplicar. Entenem l'argument de qui publica, perquè el rellotge d'un proveïdor no corre sol; en una peça que s'executa com a root a servidors d'empreses que no tenen ningú mirant el feed un diumenge, nosaltres hauríem esperat. Dit això: la finestra ja ha passat i la versió ja hi és.
Sis comprovacions per a aquesta setmana
Cap costa diners i cinc de les sis es poden fer abans d'actualitzar res.
- 1. Saber en quins nodes està activat de debò, no en quins et penses. Un
tailscale status --jsona cada node ho diu, i la consola del tailnet també. En un parc que fa dos anys que creix, «ho vam activar per a aquella migració» és una frase que se sent molt. - 2. Llegir la secció ssh de la política sencera, de dalt a baix. Qui, cap a què, i com a quin usuari. Si una regla acaba concedint l'usuari root a un grup ampli, aquí tens el teu radi d'acció, i no l'ha creat el butlletí d'aquesta setmana. Deu minuts.
- 3. Decidir si el reenviament cal. Si la resposta és no —i a la majoria de servidors ho és—, el mateix TS-2026-014 publica la mitigació:
TS_SSH_DISABLE_FORWARDING=1. Es pot posar avui, sense esperar la versió nova. - 4. Mirar tailscale serve a part. TS-2026-016 no és SSH.
tailscale serve statuset diu què hi ha publicat; si algun apunta a un socket Unix, aquesta és una altra porta, amb la seva pròpia llista de qui hi arriba. - 5. Actualitzar a 1.104.4 i comprovar la versió node a node. Els portàtils s'actualitzen sols; els servidors Linux van al ritme del repositori de la distribució i de la finestra de qui aplica els pedaços. Un
tailscale versionnode a node: la que importa és la del que té els sockets interessants, no la del portàtil des d'on mires. - 6. Posar-li número al checkPeriod. Si la regla no ho diu, són dotze hores i valen per a tota la xarxa. Decidir dotze hores està bé; heretar-les sense saber-ho, no.
En curt
No hi ha res exòtic en la fallada: un procés privilegiat va comprovar un nom i després va actuar amb els seus propis permisos. Si has muntat una malla per deixar de publicar ports —i és una raó excel·lent per muntar-la—, has mogut la decisió de qui entra a les teves màquines a una capa nova. Aquesta capa també té versions, també té fallades i també té una política que algú va escriure amb pressa un dimarts. La malla no t'ha tret la decisió de sobre; te l'ha canviat de lloc, i ara cal anar a mirar-la on és.
On encaixa això en el que fem
Quan muntem un accés zero trust no comencem per l'eina, sinó per la taula: qui ha d'arribar a què, amb quina identitat, i què passa el dia que un portàtil d'aquesta taula estigui en mans d'un altre. Aquesta taula és la que decideix si una setmana com aquesta és un pedaç o és un incident, i és independent del producte que la implementi. L'altra meitat és la de xarxes i comunicacions: què està publicat, per on entra el trànsit d'administració i què caldria tocar si demà canvies de malla —perquè les malles es canvien, i la taula no se n'hauria d'anar amb elles. Si t'interessa la capa de sota, ja vam escriure sobre quan preferim WireGuard i quan IPsec, que és el transport sobre el qual estan construïdes gairebé totes.
Fonts (verificades el 28 d'octubre del 2026): butlletins TS-2026-014, TS-2026-015, TS-2026-016 i TS-2026-017, tots quatre datats el 26 d'octubre del 2026 i corregits a 1.104.4 — tailscale.com/security-bulletins. Etiqueta v1.104.4 creada el 27-10-2026 a les 23:01 UTC, absència d'etiqueta 1.104.3 i les 42 confirmacions entre 1.104.2 i 1.104.4 (ssh/tailssh, monitor privilegiat, reenviaments com l'usuari de la sessió, ordre en brut a les gravacions, denylist de variables d'entorn, claus d'amfitrió 0600, isRootUser) — repositori públic de Tailscale. Activació opcional de Tailscale SSH, mode de comprovació i període per defecte de 12 hores per a tota la xarxa — documentació de Tailscale SSH. Nota de seguretat d'OpenSSH 7.4 (19-12-2016), reportada per Jann Horn (Project Zero), i arribada del reenviament de sockets Unix a OpenSSH 6.7 (06-10-2014) — notes de versió d'OpenSSH. Declaracions de Mike Shaver (VP d'enginyeria de Tailscale), recompte dels onze descobriments de l'informe Tailworm d'Erica Windisch (Cyberdione Labs) sobre Tailscale 1.104.2 i headscale 0.29.5, caràcter encadenable de les fallades (salt automàtic per sota del segon, sense interacció, amb robatori de claus d'alta de dispositius) i cronologia de la divulgació — SecurityWeek.
Sabries dir avui qui pot ser root a cadascun dels teus servidors?
Si la resposta està repartida entre una política d'accés, un fitxer de sudoers i la memòria d'algú, aquesta és la conversa. La posem per escrit amb tu, amb l'eina que ja tinguis: qui arriba a què, amb quina identitat i què es tanca. I si la teva taula ja està bé, t'ho direm i no et vendrem res.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN