Hi ha una frase que es diu molt i que és falsa: «he fixat la versió del servidor MCP, així que executo sempre el mateix codi». El 10 de novembre Corelight va publicar el laboratori que la desmunta, i la troballa és més incòmoda que un simple «us heu ancorat malament». Van mesurar tots els servidors MCP que es llançaven igual en un mateix lloc de treball i la conclusió és escrita sense anestèsia: «It wasn't one server. Every MCP server which was launched in the same way on that workstation showed the same pattern, whether it was pinned to a release tag, an exact PyPI version, or an exact Git commit». Un servidor comunitari ancorat a la seva etiqueta de release: 19 construccions en cinc setmanes, 15 entorns diferents i 23 de 69 paquets canviats de versió. Un altre d'aquell mateix lloc, ancorat a un commit: 19 construccions, 17 entorns.
Escrivim això amb el matís al davant: nosaltres fem servir agents i servidors MCP, i els continuarem fent servir. Això no és un article de «la IA és perillosa, no la toquis». És un article sobre una cosa molt més avorrida i molt més seriosa: que un servidor MCP és un procés que s'arrenca al lloc d'algú, amb les credencials d'aquest algú, i que el seu codi pot canviar sense que ningú hagi tocat ni una línia de configuració. Això en qualsevol altre context tindria un nom i un procediment. Aquí encara no.
El mite: «hi he posat una versió»
La mecànica és simple d'explicar i per això fa mal. Els servidors MCP s'arrenquen gairebé sempre amb un llançador d'un pas: npx al món Node, uvx al món Python. Tu escrius a la configuració del client una cosa de l'estil uvx --from git+https://github.com/<owner>/<server>@<tag> <server> i et quedes tranquil perquè allà hi ha una etiqueta. El que fixa aquesta etiqueta és el paquet de dalt. Les dependències d'aquest paquet —i les dependències de les seves dependències— es tornen a resoldre contra el registre públic en el moment de l'arrencada. Corelight ho diu en una línia que convé llegir dues vegades: «pinning a package's version doesn't necessarily pin the packages it depends on».
I convé dir que no va ser per descuit del mantenidor, perquè és la part que més desarma. L'autor del servidor comunitari havia fet just el que cal fer: va fixar exactament les seves set dependències directes i va publicar un fitxer de bloqueig amb hashes. El que va passar és que el llançador instal·lava des de les dependències declarades del paquet i no des del fitxer de bloqueig, així que els aproximadament 60 paquets de sota es resolien frescos contra PyPI a cada arrencada. A l'altre servidor, l'ancorat a commit, la deriva va arribar al punt que el marc de treball MCP sobre el qual estava construït corria dues versions majors per davant de la que figurava al fitxer de bloqueig del mateix projecte. Vas ancorar la part que es veu. La part que s'executa anava per lliure.
Els números, en una taula
| Mesura de Corelight (10-11-2026) | Resultat |
|---|---|
| Servidor comunitari ancorat a la seva etiqueta de release, 19 construccions en cinc setmanes | 15 entorns diferents |
| Un altre servidor del mateix lloc, ancorat a un commit, 19 construccions | 17 entorns diferents |
| Paquets que van canviar de versió sota el servidor comunitari que semblava ancorat | 23 / 69 |
| Servidors MCP revisats (dos catàlegs de fabricant + el seu laboratori) la instal·lació recomanada dels quals resol des d'un registre públic | 23 / 35 |
| Arrencades del servidor al lloc d'un administrador, en una setmana | 162 |
| Arrencades de servidors amb instal·lació congelada, en dues setmanes | 457, llista de paquets idèntica |
L'última fila és la bona notícia i cal dir-la: congelar funciona. 457 arrencades, mateixa llista de paquets, zero sorpreses. Això no és un problema sense solució; és un problema amb una solució que gairebé ningú aplica perquè la documentació d'on copies i enganxes no l'ensenya.
No és un laboratori: és el que hi ha publicat
Un laboratori és un laboratori. El que ho converteix en un problema de sector és un cens del 13 d'octubre del 2026 sobre 2.999 repositoris públics de GitHub que publiquen habilitats d'agent, manifestos de plugin o configuració de servidor MCP. D'aquests, 346 configuren un servidor MCP local. I d'aquests 346, 159 (el 46,0 %) n'arrenquen com a mínim un sense versió fixada: 100 (28,9 %) llancen un paquet npm via npx sense versió exacta, 63 (18,2 %) demanen directament latest, i 38 (11,0 %) executen un paquet Python sense versió. De propina, 2.459 dels 2.999 (82,0 %) no tenen SECURITY.md: no hi ha on avisar si trobes alguna cosa.
I aquí ve la part que ens sembla més reveladora, perquè no és culpa de ningú en concret i per això ningú la resol. Des del 13 d'octubre del 2026 hi ha una incidència oberta al repositori de la mateixa especificació MCP assenyalant que la guia ràpida oficial es contradiu amb la guia de seguretat oficial: els exemples d'arrencada fan servir npx -y sense versió, mentre que la guia Local Server Security diu textualment «Install a specific version rather than latest». A dia d'avui la incidència continua oberta, amb acord entre els participants sobre què cal canviar i sense cap canvi fusionat. El 18,2 % de repositoris que demanen latest no es van inventar aquest patró: el van copiar d'on tocava copiar-lo.
La deriva no és el problema. El permís sí.
Que un entorn canviï d'un dia per l'altre, per si sol, és una molèstia de reproductibilitat. El que ho converteix en un assumpte de seguretat és on viu aquest procés. Quan un servidor MCP arrenca, carrega les seves dependències dins del mateix procés, i aquest procés porta a sobre el que porti a sobre l'usuari que el va llançar: tokens d'API, fitxers de l'usuari, rutes de xarxa. La frase de Corelight és seca i és exacta: «An MCP server acts for a user, so it's often set up with that user's credentials and, as this workstation showed, an administrator's credentials reach a lot». I l'abast no és hipotètic: un dels servidors que van mesurar era l'MCP oficial d'un fabricant de seguretat, afegit després, amb permís ampli de lectura i escriptura sobre la plataforma d'aquell fabricant, i declarava les seves dependències directes sense límit superior de versió.
Suma-hi la finestra. El mateix article recorda que, en una de les onades de la campanya Shai-Hulud que va arribar a PyPI el juny del 2026 —«including MCP-themed packages», precisa l'article—, es van publicar sis versions malicioses en menys d'un minut i es van posar en quarantena en trenta minuts. Mitja hora. Si el teu lloc resol dependències fresques 162 vegades per setmana, la teva exposició no es mesura en dies de pedaç: es mesura en si justament et va tocar arrencar dins d'aquella mitja hora. Això ja ho hem explicat des d'un altre angle quan un 10.0 portava el nom d'un producte i la fallada era del seu intèrpret: el que et trenca gairebé mai és el paquet que vas triar, sinó el que va venir darrere.
I quan un d'aquests servidors té un forat
Hi ha un cas amb data i amb número, i val la pena explicar-lo sencer perquè ensenya una altra cosa. El 5 de novembre del 2026 es va publicar CVE-2026-123022 contra AgentScope: injecció d'ordres del sistema a la crida subprocess.Popen del fitxer src/agentscope/mcp/_config.py, al component MCP Workspace API. El registre del CVE diu «fins a la 2.0.11» i el puntua en 7,3 (CVSS 3.1) i 6,9 (CVSS 4.0). L'avís original de qui el va reportar, publicat el 14 d'octubre del 2026, parla de versions ≤ 2.0.4 i el puntua en 9,8. Dues lectures de la mateixa fallada amb gairebé tres punts de diferència.
La diferència de puntuació no ens interessa. El que ens interessa és per què l'avís l'anomena «no autenticat», i és escrit al mateix codi: l'extrem /workspace/mcp només comprovava que la capçalera X-User-ID no estigués buida, amb un comentari que ho confessa —«Temporary header-based identity; will be replaced by JWT auth»—. És a dir, envies una petició amb una capçalera que t'inventes, poses /bin/sh al camp command d'una configuració MCP, i el servidor llança el procés. I aquí cal ser precisos, perquè és fàcil donar això per tancat i no ho està: la proposta de canvi 3448, oberta el 23 d'octubre del 2026, afegeix una llista blanca opcional d'ordres stdio que rebutja amb un 403 el que no encaixi abans de llançar el procés. Continua oberta, és opt-in, i el seu propi autor la marca com a parcial —referencia la incidència en lloc de tancar-la— perquè no toca l'autenticació per capçalera, que es tracta en un altre lloc. L'avís de l'investigador, per la seva banda, continua registrant «Patched versions: None». La lliçó no és «AgentScope és dolent»: la lliçó és que la peça que aixeca processos era darrere d'una autenticació que el seu propi autor havia etiquetat com a provisional, i que això vivia dins de la superfície que tu estàs afegint a la teva xarxa.
El que fem nosaltres, en ordre
Res d'això és exòtic. És la mateixa feina que fem amb qualsevol altra cosa que s'executa en una xarxa que gestionem, aplicada a una peça nova que encara no és als procediments de gairebé ningú.
- Inventari primer, sempre. Quins servidors MCP s'executen, en quins llocs, llançats per qui i amb quines credencials a sobre. Si la resposta és «no ho sé», aquesta és la feina d'aquesta setmana i no la de la que ve.
- Instal·lació congelada per defecte. Fitxer de bloqueig amb hashes i el llançador obligat a fer-lo servir;
npm cien lloc denpx -y; en contenidor, imatge fixada per digest i no per etiqueta. És la fila de 457 arrencades amb llista idèntica. - Identitat pròpia per a l'agent. Compte separat, permisos acotats al que necessita i caducitat. L'agent no treballa amb les credencials de l'administrador perquè li va bé; treballa amb les seves, que arriben a menys.
- Només lectura on es pugui. La majoria de servidors MCP que la gent fa servir cada dia consulten més que no pas escriuen. Si el servidor admet mode de només lectura, s'activa.
- Mirar-ho a la xarxa, que és on es veu. El mateix article dona la pista de detecció i és bona: ràfegues de connexions a GitHub, PyPI i npm des de llocs de treball, sessions TLS curtíssimes (de 0,1 a 1,5 segons) i originades per l'assistent, no per un servei programat. Això surt als registres de DNS i TLS que ja tens.
I el punt que més costa vendre, perquè és el que obliga a canviar un costum: assumeix que el que hi ha dins del procés ja s'ha llegit. És exactament el mateix raonament que apliquem quan escrivim que cal donar per desxifrades totes les variables d'entorn d'una plataforma que executa el teu codi. Un servidor MCP és una plataforma que executa codi de tercers al lloc de la teva gent. Les regles no canvien perquè la peça sigui nova i tingui bona premsa.
Quan NO cal res d'això
Perquè si no ho diem, això es llegeix com una venda de por. Si el servidor MCP corre en un portàtil personal, contra un repositori de joguina, sense credencials de l'empresa i sense ruta cap a cap xarxa corporativa, congelar la instal·lació és cerimònia. Que corri amb latest i que s'actualitzi sol; és més còmode i no arrisques res que importi. La línia que separa un cas de l'altre no és la mida de l'empresa ni l'entusiasme per la IA: és si aquest procés té credencials i abast. Quan els té —un compte d'administrador, un token del núvol, accés a un repositori de producció—, passa a jugar a la lliga de la resta de programari privilegiat i se li aplica el mateix.
La pregunta incòmoda
Si algú del teu equip et demanés instal·lar al seu lloc un programa que (a) s'actualitza sol des d'internet sense avisar, (b) corre amb les seves credencials d'administrador i (c) pot llançar processos, tindries una conversa. Potser acabaries dient que sí, però hi hauria conversa, i quedaria escrita. Això és exactament el que ja hi ha instal·lat, i a la majoria de llocs va entrar sense conversa perquè venia amb la paraula «agent» al davant. Que la resposta continuï sent sí ens sembla raonable. Que no hi hagi hagut conversa, no.
Nosaltres portem aquesta conversa per escrit quan muntem automatització i IA en una empresa: quin agent, quin servidor, quina credencial, quin abast i qui ho revisa. I el principi de sota és el de sempre a Zero Trust: l'agent no és una eina de l'administrador, és una identitat més, i com a tal té el seu compte, el seu permís mínim i el seu registre. No venem cap servidor MCP ni cap model; muntem el perímetre al voltant.
Fonts (consultades l'11-11-2026): les xifres de deriva d'entorns (19 construccions / 15 i 17 entorns, 23 de 69 paquets, 23 de 35 servidors, 162 i 457 arrencades), les cites en anglès, l'onada de Shai-Hulud i la guia de detecció a la xarxa són de «The Supply-Chain Risk Hiding in Your MCP Servers», de James Lagermann (Corelight), publicat el 10-11-2026. El cens de 2.999 repositoris públics —346 amb servidor MCP local, 159 sense versió fixada (46,0 %), 63 amb latest (18,2 %), 2.459 sense SECURITY.md— és de l'estudi independent agent-skills-state-2026, instantània del 13-10-2026, amb mètode i dades publicats sota CC BY 4.0. La contradicció entre la guia ràpida i la guia Local Server Security és a la incidència 3431 del repositori de l'especificació MCP, oberta el 13-10-2026 i sense cap canvi fusionat a dia d'avui. Avís de procedència: el cens i la incidència 3431 són de la mateixa persona, així que compten com una font i no com dues que es corroboren. Les dades d'AgentScope provenen del registre de CVE-2026-123022 (publicat el 05-11-2026, «fins a la 2.0.11», 7,3 en CVSS 3.1 i 6,9 en CVSS 4.0) i de l'avís original de l'investigador del 14-10-2026 (≤ 2.0.4, 9,8, capçalera X-User-ID, «Patched versions: None»); la proposta de canvi 3448 (23-10-2026) continua oberta i és parcial. On dues fonts no coincideixen ho diem, en comptes de triar la xifra que queda millor. Foto de portada de Shixart1985, CC BY 2.0, via Wikimedia Commons.
Saps quins agents corren als teus llocs i amb quins permisos?
Fem l'inventari, congelem les instal·lacions, donem a l'agent la seva pròpia identitat amb permís mínim i deixem la vigilància posada a DNS i TLS. Surt en una taula amb noms i credencials, no en una diapositiva. És la feina d'automatització i IA i de Zero Trust.
Parlar amb everyWAN