CVE-2026-61559 — el MCP de GitLab manda tu token de GitLab a donde le digan
Ojo con esto: cuando @zereight/mcp-gitlab corre con ENABLE_DYNAMIC_API_URL=true, el header X-GitLab-API-URL decide a que host se hace la llamada saliente — y el token de GitLab viaja igual. Eso es SSRF con robo de credenciales de una: el atacante apunta el header a su propio servidor y se lleva el PAT completo.
GitHub lo clasifico como critical (CVSS v3.1 9.6; el reporte original pedia 8.5). Afecta todas las versiones hasta el commit 74a8c83 y al momento del reporte no habia version parcheada. Si tenes ese MCP colgado de un agente, apaga la URL dinamica ya.
CVE-2026-61568 — una pagina web cualquiera puede hablarle a tu MCP local via DNS rebinding
El mismo paquete expone su endpoint Streamable HTTP sin allowlist efectiva de Host ni Origin. Una pagina maliciosa hace DNS rebinding, enruta el request del browser al listener MCP local del laburante y conserva un Host/Origin controlado por el atacante. El server los acepta y llega al path de inicializacion MCP en vez de rechazar en el borde HTTP.
Traduccion: el limite de confianza del MCP local — «solo yo puedo hablarle a localhost» — no existe. CVSS v3.1 9.6, critical.
Cinco defectos tumban el read-only, la allowlist y la auth del MCP de GitLab
Este es el que mas me interesa conceptualmente. @zereight/mcp-gitlab expone GitLab a un agente LLM y apoya toda su seguridad en tres controles: modo read-only, allowlist de proyectos y auth de transporte. El advisory documenta cinco defectos que los rompen: bypass del read-only y de la allowlist via execute_graphql, transportes sin autenticar y un DoS por agotamiento de sesiones.
Y aca esta la clave: el analisis se hace bajo el threat model de MCP — los argumentos y el contenido de una tool call pueden estar moldeados por input no confiable, o sea prompt injection, o por un cliente malicioso. Si tu unica defensa contra un agente comprometido es la bandera «read-only», no tenes una defensa. CVSS v3.1 8.1, high. Commit revisado: 60adcc0.
CVE-2026-54561 — MCP Memory Keeper deja que el agente lea cualquier archivo del host
mcp-memory-keeper anterior a 0.13.0 no valida rutas en su funcion context_import. Un cliente MCP — incluido un agente LLM inducido a llamar la tool — puede usar ../ o una ruta absoluta para apuntar a cualquier archivo legible por el proceso del server.
Fuga por dos caminos: el JSON que parsea bien, y los mensajes de error del JSON que parsea mal. Objetivos tipicos: credenciales, service accounts, variables de entorno y claves SSH. CVSS v3.1 6.2. Actualiza a 0.13.0.
CVE-2026-92220 — un request_id manipulado hace que vLLM se coma los recursos, sin autenticar
Recien salido del horno: el MoRIIO Acknowledgement Handler de vLLM (moriio_connector.py) consume recursos sin control si manipulas los argumentos request_id o kv_transfer_params. Afecta 0.26.0 y 0.27.0.
Lo que lo hace molesto no es el impacto — solo disponibilidad — sino el perfil de acceso: remoto, sin autenticacion y sin interaccion del usuario. CWE-400 mas CWE-404. CVSS v4.0 6.9 / v3.1 5.3, medium. Es la ruta de KV transfer distribuido, asi que pega donde menos querias: en el plano de datos entre nodos de inferencia.
CVE-2026-90555 — un header FLAC falso en el endpoint de transcripcion tumba el server para todos
vLLM anterior a 0.28.0 no valida bien el sample rate declarado en el header del audio que entra al endpoint de transcripcion. Un cliente autenticado manda un header FLAC forjado con un sample rate infladisimo, vLLM reserva memoria en base a ese numero y el API server se cae — arrastrando a todos los tenants, no solo al atacante.
CWE-409 (datos muy comprimidos) mas CWE-770 (asignacion sin limite). CVSS v4.0 7.1 high / v3.1 6.5. Requiere credenciales validas, pero en un deployment multi-tenant «autenticado» significa «cualquier cliente pago».
CVE-2026-90713 — el handler de vocabulario tiktoken de vLLM se cuelga con un archivo mal formado
Tercero de la semana en vLLM: TiktokenTokenizer::new maneja mal el archivo de vocabulario de tiktoken y termina en agotamiento de recursos o error no manejado — la app crashea o queda sin responder. Afecta todas las versiones hasta 0.29.0.
Requiere acceso local, lo que baja bastante el riesgo real (CVSS v4.0 4.8, medium). Pero hay PoC publico, y el EPSS sigue abajo del 1%. Lo anoto sobre todo por el patron: tres DoS distintos en vLLM en cinco dias, todos por validacion floja de input antes de reservar memoria.
CVE-2026-90534 — Flowise 3.1.4 tapa un confused deputy que cruza credenciales entre workspaces
En Flowise anterior a 3.1.4, el endpoint POST /api/v1/node-load-method/:name esta montado sin ningun chequeo de permisos a nivel de ruta y encima no verifica que la credencial pertenezca al workspace de quien llama.
Resultado: un usuario autenticado de bajo privilegio en un workspace usa las credenciales de otro workspace — integraciones tipo Google Drive o AWS DynamoDB incluidas. Confused deputy clasico, y en una plataforma de agentes multi-tenant el impacto es exactamente el que te imaginas. CVSS v4.0 6.1 / v3.1 6.5, medium. Ya hay fix: 3.1.4.
Tendencias Destacadas
El servidor MCP dejo de ser plumbing y paso a ser superficie de ataque de primera clase: tres advisories el mismo dia sobre un solo paquete, mas un path traversal en otro. Y el threat model que usan los reporters ya asume prompt injection como entrada normal.
Tres DoS nuevos en vLLM en cinco dias y todos comparten la misma raiz: confiar en un numero que viene del request — sample rate, request_id, archivo de vocabulario — antes de reservar memoria. No es un bug, es un patron de diseno que hay que auditar entero.
Los controles de seguridad declarativos de las plataformas de agentes — modo read-only, allowlists, flags de permisos a nivel ruta — estan fallando en Flowise y en mcp-gitlab por la misma razon: se confia en la bandera y nadie verifica el limite real en el codigo.
CVE-2026-61559 — the GitLab MCP server sends your GitLab token wherever it is told
When @zereight/mcp-gitlab runs with ENABLE_DYNAMIC_API_URL=true, the X-GitLab-API-URL header decides which host the outbound call hits — and the GitLab token rides along. That is SSRF with credential theft in one step: point the header at your own server and collect the full PAT.
GitHub rates it critical (CVSS v3.1 9.6; the original report argued for 8.5). All versions through commit 74a8c83 are affected, and no patched version existed at report time. If this MCP server is wired to an agent, turn dynamic API URLs off now.
CVE-2026-61568 — any web page can talk to your local MCP via DNS rebinding
The same package exposes its Streamable HTTP MCP endpoint without an effective Host or Origin allowlist. A malicious page uses DNS rebinding to route browser requests to the victim's local MCP listener while preserving an attacker-controlled Host and Origin. The server accepts them and reaches the MCP initialization path instead of rejecting at the HTTP boundary.
Translation: the local-MCP trust boundary — only I can talk to localhost — does not exist here. CVSS v3.1 9.6, critical.
Five defects defeat read-only mode, the allow-list and transport auth in the GitLab MCP server
This is the conceptually interesting one. @zereight/mcp-gitlab exposes GitLab to an LLM agent and rests its entire security story on three controls: read-only mode, a project allow-list, and transport auth. The advisory documents five defects that defeat them: a read-only plus allow-list bypass through execute_graphql, unauthenticated transports, and a session-exhaustion DoS.
The key point: the analysis is explicitly done under the MCP threat model — tool-call arguments and content can be shaped by untrusted input, meaning prompt injection, or by a malicious client. If your only defense against a compromised agent is a read-only flag, you do not have a defense. CVSS v3.1 8.1, high. Reviewed commit: 60adcc0.
CVE-2026-54561 — MCP Memory Keeper lets the agent read any file on the host
mcp-memory-keeper before 0.13.0 does not validate paths in its context_import function. An MCP client — including an LLM agent induced to call the tool — can use ../ traversal or an absolute path to target any file readable by the server process.
Data leaks through two channels: JSON that parses successfully, and error messages from JSON that fails to parse. Typical targets are credentials, service accounts, environment variables and SSH keys. CVSS v3.1 6.2. Upgrade to 0.13.0.
CVE-2026-92220 — a doctored request_id burns vLLM resources, no auth required
Fresh today: vLLM's MoRIIO Acknowledgement Handler (moriio_connector.py) consumes resources without bound when the request_id or kv_transfer_params arguments are manipulated. Affects 0.26.0 and 0.27.0.
What makes it annoying is not the impact — availability only — but the access profile: remote, unauthenticated, no user interaction. CWE-400 plus CWE-404. CVSS v4.0 6.9 / v3.1 5.3, medium. This is the distributed KV-transfer path, so it lands exactly where you would rather it did not: the data plane between inference nodes.
CVE-2026-90555 — a forged FLAC header on the transcription endpoint crashes the server for every tenant
vLLM before 0.28.0 fails to properly validate the sample rate declared in the audio header reaching the transcription endpoint. An authenticated client submits a forged FLAC header with a wildly inflated sample rate, vLLM allocates memory based on that number, and the API server crashes — taking down every tenant, not just the attacker.
CWE-409 (highly compressed data) plus CWE-770 (allocation without limits). CVSS v4.0 7.1 high / v3.1 6.5. It needs valid credentials, but in a multi-tenant deployment authenticated just means any paying client.
CVE-2026-90713 — vLLM's tiktoken vocabulary handler hangs on a malformed file
Third vLLM issue of the week: TiktokenTokenizer::new mishandles the tiktoken vocabulary file and ends in resource exhaustion or an unhandled error — the app crashes or stops responding. Affects all versions up to 0.29.0.
It requires local access, which takes real-world risk down a long way (CVSS v4.0 4.8, medium). But a public PoC exists, with EPSS still under 1%. Worth logging mostly for the pattern: three distinct vLLM DoS bugs in five days, all of them weak input validation before a memory allocation.
CVE-2026-90534 — Flowise 3.1.4 closes a confused deputy that crosses workspace credentials
In Flowise before 3.1.4, the POST /api/v1/node-load-method/:name endpoint is mounted without any route-level permission check, and on top of that it never verifies that the credential belongs to the caller's workspace.
Result: an authenticated low-privilege user in one workspace exercises another workspace's credentials — third-party integrations such as Google Drive and AWS DynamoDB included. A textbook confused deputy, and on a multi-tenant agent platform the impact is exactly what you would expect. CVSS v4.0 6.1 / v3.1 6.5, medium. Fixed in 3.1.4.
Notable Trends
The MCP server has stopped being plumbing and become first-class attack surface: three advisories on a single package in one day, plus a path traversal in another. And the threat model the reporters use now assumes prompt injection as ordinary input.
Three new vLLM denial-of-service bugs in five days, all sharing one root cause: trusting a number that came from the request — sample rate, request_id, vocabulary file — before allocating memory. That is not a bug, it is a design pattern that needs auditing wholesale.
Declarative safety controls on agent platforms — read-only mode, allow-lists, route-level permission flags — are failing in both Flowise and mcp-gitlab for the same reason: the flag is trusted and nobody enforces the actual boundary in code.
CVE-2026-61559 — le serveur MCP GitLab envoie votre jeton GitLab ou on le lui demande
Quand @zereight/mcp-gitlab tourne avec ENABLE_DYNAMIC_API_URL=true, l en-tete X-GitLab-API-URL choisit l hote de l appel sortant — et le jeton GitLab part avec. C est un SSRF doublé d un vol d identifiants: l attaquant pointe l en-tete vers son serveur et recupere le PAT complet.
GitHub le classe critique (CVSS v3.1 9.6). Toutes les versions jusqu au commit 74a8c83 sont touchees, et aucune version corrigee n existait au moment du rapport.
CVE-2026-61568 — n importe quelle page web peut parler a votre MCP local via DNS rebinding
Le meme paquet expose son endpoint Streamable HTTP sans allowlist efficace de Host ou Origin. Une page malveillante utilise le DNS rebinding pour router les requetes du navigateur vers le listener MCP local de la victime en conservant un Host et un Origin controles par l attaquant. Le serveur les accepte et atteint le chemin d initialisation MCP. CVSS v3.1 9.6, critique.
Cinq defauts mettent a terre le mode lecture seule, l allow-list et l auth du MCP GitLab
Le plus interessant sur le plan conceptuel. @zereight/mcp-gitlab expose GitLab a un agent LLM et fait reposer toute sa securite sur trois controles: mode lecture seule, allow-list de projets et auth de transport. L advisory documente cinq defauts qui les contournent, dont un bypass lecture seule et allow-list via execute_graphql, des transports non authentifies et un DoS par epuisement de sessions.
L analyse est menee sous le modele de menace MCP: les arguments d appel d outil peuvent etre facconnes par une entree non fiable, donc par prompt injection. CVSS v3.1 8.1, eleve.
CVE-2026-54561 — MCP Memory Keeper laisse l agent lire n importe quel fichier de l hote
mcp-memory-keeper avant 0.13.0 ne valide pas les chemins dans sa fonction context_import. Un client MCP — y compris un agent LLM incite a appeler l outil — peut utiliser ../ ou un chemin absolu pour viser tout fichier lisible par le processus serveur.
La fuite passe par deux canaux: le JSON qui parse correctement, et les messages d erreur du JSON invalide. Cibles typiques: identifiants, comptes de service, variables d environnement et cles SSH. CVSS v3.1 6.2.
CVE-2026-92220 — un request_id manipule consume les ressources de vLLM, sans authentification
Tout frais: le MoRIIO Acknowledgement Handler de vLLM (moriio_connector.py) consomme des ressources sans limite quand les arguments request_id ou kv_transfer_params sont manipules. Touche 0.26.0 et 0.27.0.
Le probleme n est pas l impact — disponibilite seulement — mais le profil d acces: distant, non authentifie, sans interaction. CWE-400 et CWE-404. CVSS v4.0 6.9 / v3.1 5.3, moyen.
CVE-2026-90555 — un en-tete FLAC falsifie sur l endpoint de transcription fait tomber le serveur pour tous
vLLM avant 0.28.0 ne valide pas correctement le sample rate declare dans l en-tete audio de l endpoint de transcription. Un client authentifie envoie un en-tete FLAC falsifie avec un sample rate demesure, vLLM alloue la memoire sur cette base et le serveur API tombe — entrainant tous les tenants.
CWE-409 et CWE-770. CVSS v4.0 7.1 eleve / v3.1 6.5.
CVE-2026-90713 — le handler de vocabulaire tiktoken de vLLM se bloque sur un fichier malforme
Troisieme cas vLLM de la semaine: TiktokenTokenizer::new gere mal le fichier de vocabulaire tiktoken et finit en epuisement de ressources ou erreur non geree. Touche toutes les versions jusqu a 0.29.0.
Necessite un acces local, ce qui reduit fortement le risque reel (CVSS v4.0 4.8, moyen). Mais un PoC public existe. A noter surtout pour le motif recurrent: trois DoS vLLM distincts en cinq jours.
CVE-2026-90534 — Flowise 3.1.4 corrige un confused deputy entre espaces de travail
Dans Flowise avant 3.1.4, l endpoint POST /api/v1/node-load-method/:name est monte sans aucun controle de permission au niveau de la route et ne verifie pas que l identifiant appartient a l espace de travail de l appelant.
Resultat: un utilisateur authentifie peu privilegie d un espace utilise les identifiants d un autre espace, integrations Google Drive et AWS DynamoDB comprises. CVSS v4.0 6.1 / v3.1 6.5, moyen. Corrige en 3.1.4.
Tendances Notables
Le serveur MCP n est plus de la plomberie mais une surface d attaque de premier plan: trois advisories sur un seul paquet en un jour, plus un path traversal dans un autre. Le modele de menace employe suppose desormais la prompt injection comme entree ordinaire.
Trois nouveaux DoS vLLM en cinq jours, tous avec la meme racine: faire confiance a un nombre issu de la requete — sample rate, request_id, fichier de vocabulaire — avant d allouer la memoire. Ce n est pas un bug, c est un motif de conception a auditer en bloc.
Les controles de securite declaratifs des plateformes d agents — mode lecture seule, allow-lists, flags de permission au niveau des routes — echouent dans Flowise comme dans mcp-gitlab pour la meme raison: on fait confiance au flag et personne n applique la vraie frontiere dans le code.