Suport remot: el fitxer s'executa a la màquina del tècnic

Quan algú del teu proveïdor d'IT obre una sessió remota contra un ordinador teu, el que es comparteix és un canal, no una pantalla. I un canal té dos extrems. Gairebé tot el que s'escriu sobre risc de proveïdor assumeix que el perill baixa —que li entren a ell i des de la seva consola arriben a tu—. L'avís que CISA va publicar ahir descriu el camí contrari, i ho diu el mateix fabricant amb totes les lletres: «els servidors de ScreenConnect no estan afectats». Els afectats són els equips des dels quals s'atén.

Què diu exactament l'avís

El butlletí de ConnectWise porta data del 8 de setembre de 2026 i una frase curta: «una condició en el client de ScreenConnect pot permetre que es transfereixin i executin fitxers a través d'una sessió remota activa sense autorització ni confirmació del Host, en determinades circumstàncies». És CVE-2026-84869, amb 9,9 i vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Es corregeix a la versió 26.6.5. I aquí va la lletra petita que convé no saltar-se: el butlletí diu als clients de núvol que no han de fer res… i tot seguit, a tothom, que «després d'actualitzar, assegura't de reinstal·lar els teus clients Host i actualitzar els teus agents d'accés». Com que la vulnerabilitat viu al client, actualitzar el servidor no toca el portàtil del tècnic.

La part que ens va fer aixecar la vista és dues línies més avall, a la taula d'abast: els servidors no estan afectats; els clients Host, sí. En el vocabulari de ScreenConnect, el Host és qui es connecta per ajudar. És a dir, el portàtil del tècnic. La nostra lectura —i la marquem com a nostra— és que això inverteix la direcció que tothom té al cap: durant una sessió legítima, el que acaba executant un fitxer que ningú no va confirmar no és l'equip del client, sinó el de qui és a l'altre costat prestant el servei.

La mitigació delata el vector

Quan un fabricant no et pot donar el pedaç a l'instant, l'alternativa que ofereix sol explicar la vulnerabilitat millor que el text mateix de l'avís. Aquí l'alternativa és: entra a Administració > Seguretat > Rols i desmarca el permís TransferFiles als grups de sessió. No hi ha filtre de xarxa que serveixi, ni regla de tallafocs, ni reinici. El que s'apaga és una funció, i una de les que es fan servir quaranta vegades al dia. Aquella era, a més, l'única defensa disponible durant cinc dies: ConnectWise va publicar un avís sobre el comportament de la transferència de fitxers el dijous 3 de setembre, dient que l'identificador CVE i la correcció oficial arribarien dins la mateixa setmana, i el pedaç no va sortir fins al 8.

L'altre extrem: dos pedaços urgents en dos dies

Tres dies abans que ScreenConnect, el 8 de setembre, CISA havia inclòs a la mateixa llista CVE-2026-86218, a N-able N-central: injecció de codi estàtic (CWE-96), execució remota sense autenticar i un 10,0 rodó. La correcció és la build 2026.3.1.14, publicada pel fabricant el 6 de setembre a les 03:47. El dia abans, el 5, aquell mateix fabricant n'havia publicat una altra: la build 2026.3.1.13, que tancava CVE-2026-86206 (6,9) i CVE-2026-86207 (7,7), reportades per Rapid7 i Huntress. Dues actualitzacions d'emergència, en dies consecutius, a la peça des de la qual s'administra el parc sencer d'una cartera de clients.

I no és casualitat que sigui el mateix producte del qual vam escriure el 4 d'agost, quan dos salts d'autenticació consecutius —el segon, pedaç incomplet del primer— ens van fer explicar des de dins per què l'agent del teu proveïdor d'IT és superfície d'atac. Llavors la branca anava per la correcció 2026.3.1.7. Han passat cinc setmanes i va per la 2026.3.1.14. No pretenem que el número de build sigui una mètrica de qualitat, no ho és; però aquells dígits són finestres de manteniment que algú va haver d'obrir, de matinada, en producció, sense avisar amb quinze dies.

Dos fabricants, la mateixa frase, i CISA dient una altra cosa

N-able escriu, sobre CVE-2026-86218: «no tenim confirmacions que aquesta vulnerabilitat s'hagi explotat en entorns de producció, però els sistemes sense pedaç continuen en risc». El butlletí de ConnectWise, en la versió del 8 de setembre, no esmenta explotació. I tanmateix els dos avisos són al catàleg KEV de CISA, que per definició recull vulnerabilitats explotades conegudes: el de N-central hi va entrar el 8 amb data límit l'11, i el de ScreenConnect el 11 amb data límit el 14, que és dilluns.

No ho expliquem per assenyalar ningú. Un fabricant afirma allò que pot sostenir amb la seva pròpia telemetria, i és honest que no afirmi de més. Ho expliquem perquè el senyal útil va arribar per un altre costat i força abans. Sobre la vulnerabilitat de N-central, Arctic Wolf escriu que «es va observar explotació abans de la divulgació pública, i investigadors independents han reproduït la vulnerabilitat». Si esperes que el fabricant confirmi, mous fitxa tard. I l'entrada al catàleg tampoc és el principi de la història: des de la directiva BOD 26-04 l'acció requerida ja no es limita a «pedaça», demana triatge forense, que traduït vol dir assumir que potser no hi vas arribar primer.

Els hem comptat: quinze en el que va de 2026

Dos avisos de la mateixa família en tres dies semblaven molts, així que en lloc d'opinar ens vam baixar el fitxer. El catàleg KEV es publica en JSON obert; la versió que hem fet servir és la 2026.09.11, amb 1.709 entrades. De l'1 de gener a l'11 de setembre de 2026 hi ha 225 altes. D'aquestes, quinze són de programes la feina dels quals consisteix a governar ordinadors que no són seus:

• N-able N-central — 3 (3 i 4 d'agost, 8 de setembre)
• SimpleHelp — 3 (dues el 24 d'abril, una el 29 de juny)
• Ivanti Endpoint Manager Mobile — 3 (29 de gener, 8 d'abril, 7 de maig)
• ConnectWise ScreenConnect — 2 (28 d'abril, 11 de setembre)
• Ivanti Endpoint Manager — 1 (9 de març) i BeyondTrust Remote Support / PRA — 1 (13 de febrer)
• Microsoft Configuration Manager — 1 (12 de febrer) i Quest KACE Systems Management Appliance — 1 (20 d'abril)

Quinze. Microsoft Windows, en aquell mateix període, en suma tretze. No cal cap estadística de quota de mercat per saber quin dels dos conjunts està instal·lat en més llocs. Per comparar amb l'any passat: en tot el 2025 aquella família —comptant-hi a més LANSCOPE Endpoint Manager, de Motex— va sumar onze entrades. Anem per quinze i queden tres mesos i mig.

Dos matisos, perquè sense ells el número enganya. El primer: el KEV no mesura quantes vulnerabilitats té un producte, mesura de quines consta a CISA que s'estan explotant; un producte molt vigilat hi apareix més. El segon, i és l'important: la frontera de la família l'hem posada nosaltres, així que la publiquem sencera perquè la puguis discutir. A dins hi va el que administra o pren el control d'ordinadors. A fora hi hem deixat tres coses que voregen la categoria —SolarWinds Web Help Desk (tres altes; és ticketing), SolarWinds Serv-U (una; transferència de fitxers) i Ivanti Sentry (una; passarel·la)— i, sobretot, els plans de gestió d'equips de xarxa, que són una altra família amb el mateix problema: Cisco Catalyst SD-WAN Manager (quatre), Cisco Secure Firewall Management Center (tres) i Check Point SmartConsole (una). Posa-hi aquelles vuit i el número se'n va a vint-i-tres. El mètode de recompte és el mateix que fem servir quan comptem quina edat tenen de debò les vulnerabilitats del catàleg: descarregar el JSON i comptar amb jq, perquè qualsevol ho refaci.

No és que el codi sigui pitjor. És que el premi és millor

La temptació és concloure que aquests productes estan mal fets. No ho creiem, i en tot cas no ho podríem demostrar. El que sí que tenen els sis en comú són tres propietats que, juntes, descriuen l'objectiu ideal: concentren privilegi (una consola mana sobre milers d'equips de desenes d'empreses diferents), són abastables per xarxa perquè si no, no serveixen, i guarden credencials d'accés permanent a llocs on ningú més entra sense trucar. Un atacant que tria on invertir el seu temps compara el radi de l'explosió.

I per això la vulnerabilitat de ScreenConnect ens sembla la més interessant de les dues, encara que la seva nota sigui una dècima menor. La de N-central és la història coneguda: trenquen el concentrador, baixen a tothom. L'altra diu que la sessió de suport, aquella que obrim amb la consciència tranquil·la perquè «hi entrem nosaltres», pot funcionar en sentit contrari. I la màquina del tècnic és, gairebé sempre, la màquina des de la qual s'entra a totes les altres. El mateix que ens vam preguntar en el seu dia sobre qui pot apagar els teus servidors, però mirant cap a dins de casa.

Tres preguntes per al teu proveïdor d'IT. També per a nosaltres

Som proveïdor de serveis gestionats, així que això va de nosaltres tant com de qualsevol. No et recomanarem una eina concreta —canviar de marca no canvia la categoria—, però sí les preguntes que ens semblen justes. Si qui t'atén no sap respondre-les en una trucada, ja has après alguna cosa:

1. Quant vas trigar a aplicar l'últim pedaç d'emergència de la teva consola? No «pedaceu?». La data concreta de l'últim, i qui el va fer a les tres de la matinada. Si la resposta comença per «bé, nosaltres anem amb la versió al núvol», és una bona resposta: el fabricant t'ho actualitza i te n'assabentes després. Però llavors la pregunta següent és què va passar mentrestant.
2. Els equips dels vostres tècnics estan gestionats com els meus? Després del cas de ScreenConnect, aquesta ja no és retòrica. Portàtil amb disc xifrat, EDR gestionat amb algú mirant la consola, sense comptes d'administrador local compartits i sense instal·lar el que calgui «per a aquesta incidència».
3. Quins permisos té el rol amb què es connecten a la meva empresa? La mitigació de l'avís d'aquesta setmana és desmarcar una casella d'un rol. Això vol dir que els rols existeixen i que algú va decidir com estan. Tots els tècnics tenen transferència de fitxers i sessió desatesa sobre tot el parc, o es demana per tiquet?
4. Com sabeu que TOTS els clients Host dels vostres tècnics estan actualitzats i reinstal·lats? Aquesta és específica de la vulnerabilitat d'aquesta setmana i és la que més gent fallarà. El servidor s'actualitza en un lloc; els clients Host són repartits pels portàtils de la gent, i el butlletí demana reinstal·lar-los un a un. «És al núvol» no respon aquesta pregunta.

I ara la part incòmoda, que és contestar-les nosaltres. No publiquem quina consola de control remot fem servir, i la raó no és la seguretat per obscuritat, que no funciona: és que dir-ho converteix aquesta conversa en una comparativa de marques, i la marca és justament el que no importa. El que sí que podem posar per escrit és el de sempre. La nostra monitorització és Zabbix amb SmokePing, la font de veritat de la xarxa és NetBox i l'automatització interna corre sobre n8n autoallotjat. Cap de les quatre és glamurosa i cap no és una consola de suport remot, però totes comparteixen l'única cosa que aquí importa: estan inventariades, tenen amo amb nom i cognoms i tenen finestra d'actualització, igual que si fossin d'un client. El dia que una eina interna queda fora de l'inventari, el que tens és una màquina amb permisos sobre les altres i sense ningú mirant-la.

El que aquest post no arregla

Cal separar els dos casos, perquè «ho tenim al núvol» serveix per a un i no per a l'altre. Amb N-central és cert: el fabricant va pedaçar els entorns allotjats i qui hi és no va haver de fer res. Amb ScreenConnect no, i aquesta és la trampa de l'avís: la vulnerabilitat és al client, així que el servidor gestionat queda al dia mentre el portàtil del tècnic continua amb la versió vella fins que algú el reinstal·la a mà. L'altra cara, per als dos: la finestra en què el sistema va ser vulnerable va existir, la va gestionar un altre i no la vas veure. I el pedaç no desfà el que hagués passat abans, que és el que vam escriure fa dos dies sobre el pedaç de Cisco que tanca la porta però no et torna el plànol. Una precisió honesta sobre això de dalt: no afirmem que s'estigui explotant el CVE de ScreenConnect. El que sí que està documentat és el mecanisme, i per una altra via. A l'agost, Huntress va publicar tres incidents en organitzacions sense relació entre elles —el 20 i el 24— en què uns clients ScreenConnect manipulats, instal·lats amb enginyeria social i no explotant cap vulnerabilitat, ficaven una cadena de quatre VBScript en un missatge de transferència de fitxers; connectar-se a un d'aquells clients feia que el sistema Host rebés i executés la mateixa cadena. Allò va necessitar un client manipulat. El que el fabricant ha descrit al setembre és una condició del client normal. I no, tampoc no et diem que canviïs d'eina: et diem que la categoria té una propietat incòmoda i que convé mirar-la abans que la miri un altre.

Nota de fonts

Tot s'ha contrastat el 12 de setembre de 2026. ScreenConnect: butlletí de seguretat de ConnectWise del 8 de setembre de 2026 i la seva divulgació pública per a CVE-2026-84869 (descripció literal, 9,9 amb vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, versions anteriors a 26.6.5, «ScreenConnect servers are not impacted», sistemes Host afectats, i la mitigació de desmarcar TransferFiles a Administració > Seguretat > Rols). N-central: avís de N-able del 6 de setembre de 2026 a les 03:47 (hotfix 4, build 2026.3.1.14, CVE-2026-86218, la frase sobre absència de confirmacions d'explotació i la indicació que els entorns al núvol ja estan pedaçats) i el del 5 de setembre (hotfix 3, build 2026.3.1.13, CVE-2026-86206 i CVE-2026-86207, amb crèdit a Rapid7 i Huntress). Recompte propi: fitxer JSON públic del catàleg KEV de CISA, versió 2026.09.11 publicada l'11-set-2026 a les 19:32 UTC, 1.709 entrades, descarregat amb curl i comptat amb jq; d'allà surten les 225 altes de 2026, les tretze de la família de gestió i accés remot amb el desglossament per producte i data, les tretze de Microsoft Windows en el mateix període, les onze de 2025 i les dates i terminis de les dues entrades d'aquesta setmana (CVE-2026-86218 alta el 8 amb termini l'11; CVE-2026-84869 alta l'11 amb termini el 14), a més de la referència a la directiva BOD 26-04 i als seus requisits de triatge forense que figuren al mateix camp d'acció requerida. Els CVSS de CVE-2026-86206 i CVE-2026-86207 procedeixen de l'anàlisi publicada per Rapid7. És lectura NOSTRA i no de les fonts: que l'abast declarat per ConnectWise inverteixi la direcció habitual del risc de proveïdor; que la mitigació per permís de rol reveli que el vector és una funció del producte; la definició de la família de productes comptada i la seva frontera, declarada més amunt amb el que en deixem fora; la comparació amb Windows; i les sis preguntes. La fotografia de portada és «Disassembled iMac at a computer repair service», d'Ivan Radic, publicada sota llicència Creative Commons CC BY 2.0 i retallada per nosaltres.