Apaga la consola que gestiona tots els teus equips, fins a nou avís

El dilluns 9 de novembre, un fabricant de programari de gestió remota va publicar al seu panell d'estat una recomanació que gairebé mai no es llegeix. No demanava aplicar cap pedaç: demanava als clients amb servidor propi «retirar temporalment de servei els seus servidors N-central i mantenir-los apagats fins que N-able confirmi que poden tornar-se a encendre amb seguretat». Apagar la consola des de la qual s'administren totes les màquines, i deixar-la apagada.

Tant és si fas servir aquell producte. La pregunta que deixa damunt la taula no és de producte: quantes hores aguanta la teva empresa sense el sistema que pedaça, inventaria, monitora i entra a totes les teves màquines? I qui, de la teva plantilla, s'assabenta un diumenge a la nit que cal apagar-lo? Nosaltres som proveïdor de serveis gestionats, així que aquesta història ens inclou: va de la peça que tenim tots i que ningú no inclou al pla de contingència perquè és, precisament, la que es fa servir per executar el pla de contingència.

Què diu l'avís, amb l'hora posada

L'avís el publica N-able, fabricant de N-central, una plataforma de monitoratge i gestió remota que fan servir proveïdors d'IT i departaments interns per administrar parcs d'equips sencers. El vam llegir directament del seu panell públic, no de la premsa, i convé explicar com, perquè aquella part va acabar sent notícia per si sola. A les 12:34 UTC d'avui l'incident constava obert el 9 de novembre a les 15:15 UTC, amb tres actualitzacions, i parlava d'una «divulgació pública i comunicació no responsable de vulnerabilitats crítiques». A les 13:10 UTC hi vam tornar i el registre era un altre: un altre identificador intern, hora d'obertura les 14:00 UTC, una sola actualització, l'adjectiu «no responsable» retirat i un paràgraf nou. El panell no guarda historial —el mòdul que el guardaria està desactivat—, així que de la versió del matí només queda allò que un s'hagi descarregat.

El que no ha canviat entre les dues versions és l'important: severitat «Major Outage» i sis serveis afectats alhora —N-central allotjat a Amèrica, Àsia-Pacífic i Europa, i N-central en servidor propi a les mateixes tres regions—, l'apagada preventiva del núvol del mateix fabricant («com a mesura de precaució, hem retirat temporalment de servei els nostres entorns allotjats de N-central») i la recomanació als de servidor propi, que el text marca com a «recomanem encaridament». Aquí hi ha la part que separa dos contractes que molta gent signa pensant que són el mateix: als clients del servei allotjat els el van apagar ells; als de servidor propi els van recomanar apagar-lo. A mitja tarda d'un dilluns, uns se'n van assabentar i ja estava fet; els altres se'n van haver d'assabentar, decidir-ho i executar-ho.

El que sí que ha canviat és la frase que més importa operativament. Al matí deia: «En aquest moment no hem vist explotació activa d'aquestes vulnerabilitats». El text de la tarda diu: «Com era d'esperar, estem observant activitat d'escaneig associada al codi de prova de concepte publicat. En aquest moment, però, no tenim evidència que l'entorn de cap client hagi estat explotat amb èxit». Continua sense haver-hi bretxa confirmada, i aquell matís importa quan el titular que t'arriba per Slack diu una altra cosa; però ja hi ha algú provant claus a la porta, i això canvia el càlcul de quant pots esperar.

Cal dir el que han fet bé, que és poc freqüent. Reconeixen el dany sense maquillar-lo: «Som conscients de l'impacte operatiu significatiu que aquestes accions poden tenir. No fem aquest pas a la lleugera». I a l'actualització de les 09:46 UTC —l'última que vam veure abans de la reescriptura— deien una cosa que un departament de màrqueting hauria retallat: que l'hora estimada de l'arranjament «és provisional i pot moure's», perquè volen que la compilació «passi els nostres estàndards de qualitat habituals fins i tot en aquestes circumstàncies difícils». I cal dir també l'altra meitat: la promesa d'actualitzar «cada quatre hores» apareix dins de l'actualització de les 05:00 UTC, tretze hores i tres quarts després d'obrir l'incident, i la següent va arribar quaranta-sis minuts més tard del promès. Tretze hores de silenci són moltes nits de guàrdia.

Sis dies entre «actualitza» i «apaga'l»

Al mateix panell continua obert un avís anterior, del 3 de novembre a les 15:00 UTC. Diu: «Els clients amb instal·lació pròpia haurien d'actualitzar a N-central 2026.4 HF1 com més aviat millor». El pedaç va sortir el 2 de novembre a les 18:30 GMT, compilació 2026.4.0.32, i el que arregla és el sistema operatiu de sota: N-central corre sobre AlmaLinux 9 i el hotfix porta les actualitzacions de seguretat de la distribució, entre elles CVE-2026-98432 —un ús després d'alliberar a la pila IPv4 del kernel de Linux, 9,8 segons l'expedient del NVD i segons les mateixes notes del fabricant— i CVE-2026-114406, que retira la confiança a uns certificats arrel. Del tercer, CVE-2026-111497, escriuen una frase que gairebé cap fabricant escriu: que N-central no fa servir el descodificador Brotli afectat i per tant no és vulnerable, però que actualitzen igualment per higiene.

Entre aquell «actualitza com més aviat millor» del dia 3 i el «mantén-lo apagat» del dia 9 hi ha sis dies. Les dues instruccions són correctes, no es contradiuen i les dues exigeixen exactament el mateix del teu costat: que algú estigui llegint. La diferència és en un altre lloc. El que va arreglar el hotfix tenia número: tres CVE, la seva puntuació, la seva entrada al NVD, la seva línia a l'informe de l'escàner. El que va obligar a apagar la plataforma sis dies després és a l'aplicació de sobre i, a l'hora en què escrivim això, no en té cap: consultant el NVD per «N-central» surten 28 expedients i el més recent es va publicar el 6 de setembre. El teu escàner de vulnerabilitats només et pot ensenyar la capa que ja té número, i la que et tomba un dilluns sol anar per davant del catàleg.

El material es va publicar el diumenge 8 sota el nom Able2Shell, i la xifra que circula per la premsa és de 33 fallades de dia zero amb proves de concepte. Aquella xifra no la podem verificar nosaltres: el fabricant no ha donat cap número en cap de les seves comunicacions, i la cerca pública de repositoris de GitHub no retorna avui cap resultat per a «Able2Shell». De l'autoria, el que hi ha és desigual: BleepingComputer identifica l'investigador com a Sean Bales i diu haver-hi parlat; altres mitjans no anomenen ningú i citen només el compte de GitHub des del qual es va publicar. Així que deixem la xifra on és, com el que és, i ens quedem amb el que sí que signa el fabricant: van ser suficients per apagar tres regions. Si vols el procediment per quan el pedaç encara no existeix, el vam escriure sencer a la teva política de pedaços no contempla que no hi hagi pedaç.

El bucle: el que pedaça és el que cal apagar

Quan apagues un servidor de fitxers, perds fitxers. Quan apagues el pla de gestió, perds la capacitat d'arreglar tota la resta: és l'única peça del parc l'apagada de la qual et deixa sense l'eina amb què anaves a respondre a l'apagada. I el que cau amb ella no és una funció, en són sis:

En aquest cas concret hi havia bot salvavides: el fabricant va mantenir dret el seu pla nou, el del núvol, i va publicar què continuava disponible des d'allà —vista d'actius, pedaçat, gestió de vulnerabilitats, scripts, polítiques i etiquetatge—, a més d'obrir aquell mateix dia un motor de pedaçat de Windows en preview i només sota demanda i el control remot des de la vista d'actius. I aquí és on se'n treu la lliçó equivocada. Aquell bot existia perquè el fabricant tenia dos plans; la majoria d'instal·lacions que veiem en tenen un. Una sola consola que concentra accés, inventari, pedaçat i automatització surt barata d'operar i és còmoda fins que deixa de ser-ho: el dia dolent és un interruptor únic. Sobre qui té de debò autoritat per accionar un interruptor així ja vam escriure arran d'una altra apagada: els teus servidors els pot apagar algú amb qui no has signat res.

Això no va començar diumenge

El catàleg de vulnerabilitats explotades de CISA —la llista de fallades de les quals hi ha constància d'ús real, no de les que podrien fer-se servir— ja portava cinc entrades d'aquest mateix producte abans de diumenge. Les hem tret avui del fitxer oficial, versió 2026.11.09 publicada ahir a les 19:54 UTC, amb 1.773 expedients en total:

D'aquella taula ens quedem amb dues coses. Una, l'ordre: CVE-2026-18577 va entrar al catàleg un dia abans que CVE-2026-18556, i el 18577 és, segons el seu propi expedient, «el resultat d'un pedaç incomplet de CVE-2026-18556». El pedaç del salt d'autenticació va arribar al catàleg d'explotats abans que la fallada que venia a tapar. Dues, el termini: les tres entrades del 2026 porten tres dies per a les agències federals nord-americanes. No és un termini excepcional reservat al greu —des que CISA va canviar de directiva, tres dies és la banda més curta de les que fa servir i la que més reparteix: 155 dels 289 expedients donats d'alta el 2026—, així que el termòmetre no és el termini. El termòmetre és que aquest producte hi hagi entrat cinc vegades. Del que significa confiar en un agent que corre amb permisos totals a cada màquina en vam parlar a l'agent del teu proveïdor d'IT és superfície d'atac. El d'ara és el capítol següent: el servidor que mana sobre tots aquells agents.

Per quin canal t'arriba la mala notícia?

Aquesta part la vam mesurar nosaltres avui i és reproduïble en dos minuts. El fabricant té dos llocs públics. Un és el blog de notes de versió, que és un WordPress i per tant té RSS: el canal al qual se subscriu la gent. L'altre és el panell d'estat, una aplicació web les dades de la qual només surten si consultes la seva API, que no publica RSS i que, com hem vist més amunt, no conserva allò que esborra. Vam preguntar al primer per entrades de novembre sobre l'incident del dia 9: zero. Hi ha dues entrades de novembre que toquen seguretat —l'avís de Risk Intelligence del dia 6 i les mateixes notes del hotfix del dia 2, que citem més amunt—, però cap no esmenta l'apagada. L'últim publicat allà el dia 9 són dues entrades de producte, a les 14:18 i a les 21:39 UTC. La recomanació d'apagar els servidors viu, sencera, a l'altre lloc.

Siguem justos amb ells: l'entrada de les 21:39 és el motor de pedaçat en preview, i el mateix avís de l'incident l'enllaça com a alternativa per a qui s'ha quedat sense consola, o sigui que forma part de la resposta. El panell d'estat, a més, permet subscriure-s'hi. Però la conseqüència pràctica no canvia i és incòmoda: si la teva vigilància de proveïdors consisteix en un lector d'RSS, el 9 de novembre hauries vist una novetat de producte i no la recomanació d'apagar. Això no va de comunicació corporativa. Va d'una columna que hauria d'existir al teu inventari de proveïdors, al costat del nom: on publica cadascun les males notícies, qui dels teus hi està subscrit, i què passa quan això cau en diumenge.

Runbook: 48 hores sense pla de gestió

Això és el que nosaltres executaríem, en aquest ordre, el dia que a qualsevol de les nostres eines de gestió li toqui el rebre. Està escrit perquè el copiïs i l'adaptis, no perquè l'admiris.

Primera hora. Confirmar la recomanació al canal del fabricant, no al titular: hora exacta, versions afectades, què diu d'explotació activa. I desar una còpia del que diu avui, perquè aquella pàgina pot canviar sota teu. Abans d'apagar, endur-se els registres a un altre lloc: si l'aparell s'apaga i després cal mirar enrere, el volàtil ja no hi és. Si apagar-lo de cop no és viable, el pas intermedi és treure'l d'internet i deixar-lo accessible només des de la xarxa de gestió, que és on hauria d'haver estat sempre.

Primeres quatre hores. Comprovar —executant, no recordant— que entres a les màquines sense aquella eina: un compte local o de domini que funcioni, la targeta de gestió del servidor, la VPN amb el seu segon factor. Si l'únic camí de tornada passava per l'agent que acabes d'apagar, aquella és la teva troballa del dia. Treure l'inventari d'on no depengui de l'eina i avisar qui en patirà les conseqüències: usuaris que avui no tindran suport remot, i direcció, que prefereix assabentar-se'n per tu.

Les 48 hores. Pedaçar a mà per prioritat —el que sigui al catàleg d'explotats i el que doni a internet, en aquest ordre— i anotar en una llista el que es fa a pèl, perquè quan la consola torni caldrà reconciliar. Mantenir un monitoratge que no depengui del pla caigut, encara que sigui mínim. I posar una data de revisió: si a les 48 hores continues sense consola, ja no és un incident del proveïdor, és el teu pla de continuïtat.

Tornar a encendre. No es torna en bloc. Primer un servidor, validat contra el que digui el fabricant que arregla la versió nova; després la resta. I l'últim pas del runbook és el que gairebé ningú fa: escriure què va faltar. Aquesta apagada no te la cobra ningú com a simulacre, però ho és, i és l'únic que tindràs aquest trimestre.

Si en llegir això has pensat que tu no tens «res d'això», busca-ho millor. Es diu Intune, o el servidor de còpies, o la consola de l'EDR, o Ansible, o l'hipervisor, o aquell script de desplegament que corre com a administrador de domini des de fa sis anys. Qualsevol peça capaç d'executar el que li manis a totes les màquines alhora és un pla de gestió, encara que a la factura hi posi una altra cosa. I té les mateixes tres preguntes: qui l'actualitza, qui se n'assabenta quan el seu fabricant publica alguna cosa lletja, i com treballes el dia que calgui apagar-la.

El que fem nosaltres, i el que no et prometrem

Seria fàcil tancar això amb un «per això, confia en nosaltres». No va d'això. Nosaltres també tenim eines amb abast sobre parcs sencers, i l'única diferència honesta que podem reclamar és com les tractem: l'inventari i la documentació de xarxa viuen a NetBox, que és font de veritat i no un annex de l'RMM; el monitoratge és nostre, amb Zabbix i SmokePing, i per tant no cau amb la consola de ningú; i les automatitzacions internes —n8n autoallotjat, per exemple— estan inventariades com a servei de producció, amb amo i finestra d'actualització, no com «una andròmina que va muntar algú».

El que no et prometrem és que a nosaltres no ens passi. El fabricant de dilluns és una empresa seriosa amb pàgina d'incidents, actualitzacions cada quatre hores i la decència d'apagar el seu propi núvol abans no els ho demanessin. Si algú et jura que el seu pla de gestió és immune, t'està venent alguna cosa. La fallada és inevitable; el que es decideix a la taula de disseny és si aquella fallada es converteix en avaria. La diferència entre totes dues coses, el dia de l'apagada, és un document de dues pàgines escrit abans i provat almenys un cop.

Fonts (el 10-11-2026, amb dues captures del mateix lloc: 12:34 UTC i 13:10 UTC): tot l'incident surt del panell d'estat públic de N-able, les dades del qual se serveixen des de la seva pròpia API i el mòdul d'històric del qual està desactivat. De la captura de les 12:34, que conservem: obertura el 09-11-2026 a les 15:15 UTC, tres actualitzacions, l'expressió «divulgació pública i comunicació no responsable», la frase «En aquest moment no hem vist explotació activa d'aquestes vulnerabilitats» i les actualitzacions de les 05:00 UTC (on apareix la promesa d'actualitzar cada quatre hores) i de les 09:46 UTC (d'on surten «és provisional i pot moure's» i «passi els nostres estàndards de qualitat habituals fins i tot en aquestes circumstàncies difícils»). De la captura de les 13:10, que és la que veurà qui cliqui l'enllaç: un altre identificador d'incident, obertura a les 14:00 UTC, una sola actualització, sense l'adjectiu «no responsable», i el paràgraf nou sobre l'activitat d'escaneig. Severitat «Major Outage», els sis serveis i «recomanem encaridament» hi són a totes dues. L'avís anterior del 03-11-2026 a les 15:00 UTC continua obert al mateix panell. El hotfix (compilació 2026.4.0.32, AlmaLinux 9, els tres CVE i la nota que el descodificador Brotli no es fa servir) és a les notes de versió del 02-11-2026, 18:30 GMT. El 9,8 de CVE-2026-98432 i la seva naturalesa (ús després d'alliberar a la pila IPv4 del kernel) són del NVD i coincideixen amb el que publica el fabricant. Per a CVE-2026-86218 donem les dues puntuacions perquè no són el mateix: 9,8 és la mètrica CVSS 3.1 primària del NVD i 10,0 és la CVSS 4.0 secundària aportada pel fabricant. El recompte de 28 expedients per a «N-central» i la data del més recent (06-09-2026) surten de l'API del NVD avui. La taula de cinc entrades, les seves dates d'alta i els seus terminis són del catàleg de vulnerabilitats explotades de CISA, fitxer JSON versió 2026.11.09 publicat el 09-11-2026 a les 19:54 UTC amb 1.773 expedients; el repartiment de terminis del 2026 (155 de 289 altes amb tres dies) el vam comptar nosaltres sobre aquell mateix fitxer. El recompte del blog de notes de versió és mesura nostra contra la seva API pública i és reproduïble. La xifra de 33 fallades, el nom Able2Shell, la data del diumenge 08-11 i la identificació de l'investigador per part de BleepingComputer procedeixen de la premsa, no del fabricant, i van marcades com a tals. Fotografia: «Power Lockout», de darkday (Brisbane, Austràlia), CC BY 2.0 via Wikimedia Commons, original de 6.016 × 4.000, retallada per nosaltres; la descripció de l'autor assenyala que els cadenats tenen la clau posada, detall que no hem retocat.