Aquest matí hem fet dues crides a dues APIs públiques. La primera pregunta al repositori de l'SDK de Python del Model Context Protocol —la peça que connecta els agents d'IA amb els sistemes on treballen— quants avisos de seguretat té publicats: en torna dotze. La segona pregunta el mateix a OSV, la base de dades pública que alimenta mitja indústria d'escàners de dependències: en torna sis. Els sis que falten són els sis últims.
Es van publicar entre el 28 de setembre i el 5 d'octubre del 2026: vuit dies, sis avisos. Tres puntuen 7,5 sobre 10. Avui, 12 d'octubre, cap dels sis existeix a OSV, cap existeix a la base global d'avisos de GitHub, cap surt per l'API de PyPI i l'únic que duu CVE assignat —CVE-2026-59951— tampoc no és al NVD. Existeixen en un sol lloc: la pestanya de seguretat del repositori.
La frase «l'escàner no ha saltat» duu a dins una suposició que gairebé mai no es mira de cara: que el que se sap d'un error i el que arriba al teu inventari són la mateixa cosa. Aquí no ho són, i la diferència es pot mesurar. El projecte, per cert, ha fet la seva part; hi tornarem al final.
La comprovació, perquè la repeteixis
Dues crides sense autenticar, sense compte i sense eines. La primera pregunta al repositori; la segona, a OSV:
# Avisos publicats al repositori
curl -s "https://api.github.com/repos/modelcontextprotocol/python-sdk/security-advisories" \
| jq -r '.[] | "\(.published_at[0:10]) \(.ghsa_id) CVE:\(.cve_id // "-")"' | sort
# Avisos que OSV coneix per al paquet mcp
curl -s -X POST "https://api.osv.dev/v1/query" \
-d '{"package":{"name":"mcp","ecosystem":"PyPI"}}' | jq -r '.vulns[].id' | grep GHSA | sort
Dotze contra sis. El grep de la segona crida no és un truc perquè surti el número: OSV retorna dotze entrades, però són aquests mateixos sis avisos llistats dues vegades, una amb el seu identificador GHSA i una altra amb el seu àlies PYSEC —PYSEC-2026-1616 i companyia, cadascun amb el GHSA antic al seu camp aliases—. Sis vulnerabilitats diferents, totes anteriors al setembre. I el control que converteix això en una dada i no en una anècdota: pregunta a PyPI per una versió antiga i per una de recent. L'API de PyPI és, a més, la font que pip-audit consulta per defecte —la seva documentació llista --vulnerability-service amb (choices: osv, pypi, esms) (default: pypi)—.
$ curl -s https://pypi.org/pypi/mcp/1.12.0/json | jq '.vulnerabilities | length'
6
$ curl -s https://pypi.org/pypi/mcp/1.29.1/json | jq '.vulnerabilities | length'
0
La versió del 2025 retorna sis vulnerabilitats. La 1.29.1, que és l'última de la branca 1.x anterior a l'arranjament, reretorna zero. I cinc dels sis avisos nous l'anomenen com a afectada en els seus rangs de versions. El mateix passa amb la 2.1.1 a la branca 2.x: zero vulnerabilitats segons PyPI, cinc dels sis avisos la inclouen. El paquet és als feeds; aquests sis avisos no.
L'explicació és avorrida i per això es passa per alt: GitHub distingeix entre l'avís que un projecte publica al seu repositori i el que a més es publica a la base de dades global. Només el segon es replica a OSV i dispara alertes: la documentació de Dependabot ho diu en una línia —«Only advisories reviewed by GitHub trigger alerts»—. Els sis són al primer estat. Cap de les dues bandes no ha fet res estrany. El resultat, tot i així, és que un escàner correcte, ben configurat i actualitzat et torna zero.
Què hi ha als sis
Val la pena llegir-los perquè no són errors de laboratori, i perquè es reparteixen a parts iguals: tres dels sis només t'afecten si el teu codi actua com a client MCP —si tens un agent que es connecta a servidors que no controles del tot— i els altres tres, només si ets tu qui aixeca el servidor. Cada fitxa ho delimita al seu apartat Am I affected?, i els de servidor diuen expressament «Not affected: MCP clients».
- 28-09 · 7,5 ·
GHSA-qx49-fqc8-xw99. El servidor MCP al qual et connectes decidia a quin servidor d'autorització enviava el teu client les credencials. S'emporta elclient_secret, el codi d'autorització i elcode_verifierde PKCE. - 28-09 · 6,5 ·
GHSA-rwrf-2pqf-9j8j. En validar el resultat d'una eina, el client resolia les referències$refde l'esquema obrint la URL. Un servidor podia fer-li demanar una adreça interna o llegir un fitxer local, i deixar-lo penjat: «the fetch ran synchronously on the event loop with no timeout». - 30-09 · 7,5 ·
GHSA-84m7-p3x7-pcfv(CVE-2026-59951). Les sessions de Streamable HTTP no es reclamaven mai: no caducaven, unDELETEdeixava l'entrada registrada i cada sessió desava els seus paràmetres d'initialize. Només un reinici alliberava la memòria. El mateix avís és honest amb el seu arranjament: «This bounds retention rather than eliminating it». - 30-09 · 7,5 ·
GHSA-fmmv-w9g8-j3gc. El servidor llegia el cos sencer de cada petició en memòria abans de mirar-ne la mida, també als endpoints d'OAuth i sense necessitat de credencials. Aquest és l'únic dels sis l'arranjament del qual és anterior: va arribar a la1.29.1del 24 d'agost. - 02-10 · 5,9 ·
GHSA-5h93-6whr-6q8j. Els transports HTTP seguien redireccions a qualsevol host enduent-se les capçaleres pròpies —l'avís posa d'exemple unX-API-Key— i, en un 307 o un 308, també el cos. N'hi ha prou amb un domini caducat al final d'una redirecció vella. - 05-10 · 6,8 ·
GHSA-w4fh-qvv9-3v23. L'autenticació per token del servidor no comprovava per a qui s'havia emès el token. Si el teu servidor d'autorització emet tokens per a diversos serveis, el d'un altre servei també entrava.
Dos dels sis no s'arreglen actualitzant
Aquí hi ha la part que de debò canvia la feina d'algú, i és la que pitjor viatja per qualsevol feed automàtic, perquè cap feed no té un camp per a «a més cal editar codi». Dos dels sis ho diuen amb totes les lletres.
El del token aliè, GHSA-w4fh-qvv9-3v23, obre el seu apartat d'arranjament així: «Upgrading alone changes nothing. The patched versions add a validate_token_resource setting that is off unless you set it.». I avisa del parany de fer-ho a mitges: cal activar l'opció i tornar l'audiència del token des de verify_token(); amb només la primera cosa, «every request gets 401». És a dir: o ho fas sencer, o no fas res, o et quedes sense servei.
El de les credencials OAuth, GHSA-qx49-fqc8-xw99, el de 7,5, diu el mateix per a dos dels seus proveïdors: «upgrading changes nothing until you also pass issuer=». Sense aquest paràmetre «they still follow whichever authorization server the MCP server advertises». I com t'assabentes que te'n falta? Amb un avís que el mateix text desactiva en la mateixa frase: «On 1.30.0 it is a DeprecationWarning, which Python hides by default». El senyal existeix, ve apagat de fàbrica i la fitxa ho reconeix per escrit.
Aquest mateix avís afegeix dues tasques que no fa cap gestor de paquets: esborrar el registre OAuth desat, perquè «a registration stored without an issuer stays unbound», i rotar el secret i revocar els tokens si aquell client s'ha pogut connectar a un servidor que no controles. Un escàner que et digués «actualitza a 1.30.0» i es callés la resta et deixaria amb la sensació d'haver acabat.
L'arranjament és del 7 de setembre; l'avís, del 28
Les versions que tanquen cinc dels sis —1.30.0 i 2.2.0— es van pujar a PyPI el 7 de setembre del 2026. Els avisos que expliquen què tancaven van arribar vint-i-un dies després el primer i vint-i-vuit l'últim. Durant aquelles tres o quatre setmanes la informació existia, però amb un altre nom: les notes de les dues versions descriuen els canvis sota l'epígraf «Behaviour changes», no sota «seguretat». A la 1.30.0 s'hi llegeix, literal, «HTTP client redirects are only followed within the endpoint's origin», «Idle Streamable HTTP sessions now expire» i «The OAuth client checks the authorization server's issuer»; a la 2.2.0 els dos últims duen a més una coda sobre la ruta heretada. Són els mateixos tres errors, explicats com a ajustos de comportament.
No és un retret: un projecte pot arreglar primer i redactar la fitxa després, i és millor això que a l'inrevés. El que deixa veure és l'ordre real en què se n'assabenta la gent. Qui actualitza per costum va quedar cobert el 7 de setembre sense saber de què. Qui llegeix els canvis abans d'actualitzar va llegir «canvi de comportament» i ho va ficar a la cua del que no corre pressa. I qui espera que salti una alerta continua esperant avui.
La nota puja si no hi ha ningú al davant
Hi ha un detall en dues de les fitxes que no havíem vist abans: el mateix error duu dues notes. Dos dels tres avisos de client es puntuen dues vegades, segons hi hagi o no una persona al davant aprovant. El dels $ref ho escriu així: «The rating assumes a person added the server and approves tool calls. For unattended agents, scored without user interaction, it is 7.5». El de les credencials va a l'inrevés: puntua 7,5 per als proveïdors desatesos i aclareix que «with the interactive OAuthClientProvider a person has to start the sign-in; scored that way it is 6.5».
Traduït al teu inventari: el mateix error, al mateix paquet, val una cosa al portàtil d'un desenvolupador que aprova cada crida i una altra de ben diferent al procés que corre sol a les tres de la matinada. I el que corre sol a les tres de la matinada és, justament, el que muntes quan l'automatització comença a funcionar bé. La supervisió humana no és un detall d'implantació: és una variable de la puntuació, escrita per qui coneix el codi. D'això anava també L'agent d'IA no sortirà al teu registre: sortirà qui li va deixar el token: l'agent hereta els permisos de qui li va deixar els permisos, i el registre assenyala la persona equivocada.
El que canvia a la pràctica
Un escàner de dependències respon a una pregunta molt concreta: «hi ha als feeds públics un avís que anomeni aquesta versió?». La pregunta que a tu t'importa és una altra, «se sap alguna cosa d'aquesta peça?», i ningú no la respon per tu. Tres coses que sí es poden fer aquesta setmana:
- 1Fes la llista de les peces que automatitzen la teva empresa, amb la seva versió. L'orquestrador, els SDK, els servidors MCP que has aixecat, el connector que va escriure algú al març. Si no és en una llista amb nom i versió, no és en cap inventari, i el que no és en un inventari no s'apedaça: es descobreix.
- 2Per a cadascuna, apunta on es publiquen els seus avisos. No «al meu escàner»: l'adreça concreta. A GitHub és
/security/advisoriesdel repositori, i es consulta amb la mateixa crida de dalt des d'un cron setmanal. Compte, que ni tan sols hi ha drecera: GitHub serveix un Atom per a les releases d'un repositori, però demanar-li el dels avisos retorna un 406. L'inventari s'aixeca un cop; la consulta, després, va sola. - 3Després d'actualitzar, llegeix si l'arranjament demana a més tocar codi. És la casella que no existeix en cap tauler. Aquí són dos de sis, amb la frase «upgrading alone changes nothing» escrita pels mateixos autors. Si el teu procés d'apedaçament acaba quan canvia el número de versió, en aquests dos casos acaba abans d'arreglar res.
Nosaltres ho apliquem al que és nostre, que és petit i per això serveix d'exemple: l'automatització interna corre sobre n8n autoallotjat, i el tractem com el que és, un servei de producció —inventariat, amb propietari i amb finestra d'actualització—, no com un script que algú va aixecar un divendres. Aquesta és tota la diferència entre una peça que s'apedaça i una peça que es descobreix el dia que falla. És el mateix forat que explicàvem a La teva política de pedaços no contempla que no hi hagi pedaç, vist des de l'altra banda: allà hi havia avís i no hi havia pedaç; aquí hi ha pedaç i no hi ha avís.
El que no et direm
- ✗Que el projecte ho hagi fet malament. Les sis fitxes són de les millors que hem llegit enguany: rangs de versions exactes, un apartat d'«Am I affected?» que descarta casos, mitigacions per a qui no pot actualitzar i l'advertiment explícit que actualitzar no n'hi ha prou. Molta gent amb més pressupost publica bastant menys.
- ✗Que el teu escàner estigui trencat o que calgui canviar-lo. Està fent bé la seva feina amb les dades que rep. El forat no és a l'eina, és entre la publicació i el feed, i cap eina no el tapa tota sola.
- ✗Quants projectes més són en aquesta situació. No ho sabem: n'hem mirat un, amb cura, i expliquem el que hem mesurat. Si vols saber si les teves dependències crítiques estan igual, la comprovació de dalt triga un minut per paquet i la resposta és teva, no nostra.
El mes passat es va descarregar aquest paquet dos-cents trenta-cinc milions de vegades, segons les estadístiques públiques de PyPI —una xifra que inclou integració contínua, rèpliques i reinstal·lacions, així que no són dos-cents trenta-cinc milions d'instal·lacions vives—. Encara que la divideixis per on vulguis, queda una quantitat enorme de llocs on algú va contestar «l'escàner no ha dit res» i tenia raó.
Fonts (comprovades el 12-10-2026): els recomptes de dotze avisos al repositori i sis a OSV, els codis 404 dels sis recents tant a api.osv.dev com a la base global de GitHub, els zero resultats de CVE-2026-59951 al NVD i les xifres de l'API de PyPI són nostres, obtinguts amb les crides públiques reproduïdes a l'article. Les cites entre cometes són literals dels avisos del repositori: modelcontextprotocol/python-sdk · Security Advisories. Notes de versió d'1.30.0 i 2.2.0 (7-09-2026): releases del projecte. Font per defecte de pip-audit: README de pypa/pip-audit. Condició d'alerta de Dependabot: About Dependabot alerts. Descàrregues de l'últim mes: pypistats.org/packages/mcp. Si repeteixes les crides setmanes després d'aquesta data, els números poden haver canviat: això seria una bona notícia, i el mètode per verificar-ho és el mateix.
Saps quina versió de quina peça mou la teva automatització ara mateix?
Si la resposta triga més d'un minut, l'inventari és la feina, no el pedaç. És el que fem a automatització i IA —posar propietari, versió i finestra a cada peça que treballa sola—, el que ho manté viu després és el manteniment informàtic, i el que acota el dany quan una credencial acaba on no toca és Zero Trust: que el token de l'agent no obri més portes de les que necessita.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN