Supabase MCP puede filtrar toda una base de datos SQL

 (generalanalysis.com)
10 puntos por GN⁺ 2025-07-09 | 1 comentarios | Compartir por WhatsApp
  • Al abusar de la integración de Supabase MCP, un atacante puede exfiltrar datos SQL privados de un desarrollador
  • Como el LLM no distingue entre instrucciones y datos, existe el riesgo de que mensajes manipulados maliciosamente se confundan con comandos
  • Un agente de IA con permisos service_role procesa sin confianza la entrada de usuarios clientes, lo que provoca la exposición de información sensible
  • Los atacantes demostraron que con mensajes que incluyen instrucciones específicas es posible evadir controles y filtrar información crítica
  • Como medidas de mitigación, se propone activar el modo de solo lectura y usar filtros contra prompt injection

Resumen general

  • Model Context Protocol (MCP) es un protocolo estándar que permite a los LLM interactuar con herramientas externas
  • Esto abre nuevas oportunidades, pero también introduce posibles vulnerabilidades de seguridad
  • Esta publicación demuestra cómo un atacante puede aprovechar la integración MCP de Supabase para filtrar tablas SQL privadas de un desarrollador

Explicación del problema

  • Los LLM procesan el prompt del sistema, las instrucciones del usuario y el contexto de datos como texto
  • Los LLM no conocen de forma inherente los límites del contexto y no pueden distinguir entre datos e instrucciones
  • Si dentro de los datos de entrada del usuario hay contenido manipulado para parecer un comando, el LLM puede ejecutarlo como una instrucción

Entorno del ataque (Setup)

  • Se crea un nuevo proyecto de Supabase para simular un entorno típico de soporte al cliente en un SaaS multi-tenant
  • Solo se insertan datos dummy; Row-Level Security (RLS) se aplica según la documentación oficial, sin extensiones ni políticas adicionales
  • El entorno usado para el ataque utiliza únicamente servicios predeterminados; service_role, RLS y el agente MCP están con la configuración por defecto

1. Actores principales y permisos

Actor (rol) Interfaz usada Credenciales DB Permisos principales
Cliente/atacante Formulario de envío de tickets (público) anon (limitado por RLS) Crear tickets/mensajes de su propiedad
Agente de soporte Dashboard de soporte support (limitado por RLS) Lectura/escritura parcial solo en tablas de soporte
Desarrollador Cursor IDE + Supabase MCP service_role Acceso SQL completo sobre todas las tablas
IDE Assistant LLM (ejecutándose en Cursor) service_role Ejecuta SQL vía MCP siguiendo instrucciones en texto
  • Núcleo de la vulnerabilidad: el IDE Assistant no reconoce que la entrada del cliente no es confiable y además tiene el máximo privilegio (service_role)
  • Con los permisos del agente de soporte no es posible acceder a tablas sensibles (por ejemplo, integration_tokens), y aunque se le soliciten instrucciones, responde rechazando la petición

2. Estructura de la aplicación

  • Clientes y agentes pueden crear tickets de soporte e intercambiar mensajes libremente
  • Todos los datos se almacenan en la base de datos SQL de Supabase
  • El desarrollador revisa ocasionalmente tickets abiertos con el agente de Cursor (LLM + MCP)

Ejemplos de tablas

  • support_tickets: almacena datos de tickets de soporte
  • support_messages: almacena mensajes de cada ticket
  • integration_tokens: almacena información de seguridad como tokens de sesión sensibles

3. Cómo funciona la aplicación

  • El sistema de soporte permite crear tickets e intercambiar mensajes
  • El desarrollador automatiza la revisión y el resumen de tickets y mensajes abiertos con el agente de Cursor
  • El agente de Cursor accede a la DB con permisos service_role, omite RLS y también lee todos los mensajes de clientes
  • Si alguien inserta una instrucción manipulada en un mensaje del cliente, la IA puede ejecutarla como SQL y filtrar información sensible

Escenario de ataque

  • El atacante abre un nuevo ticket y envía un mensaje especialmente diseñado
    • El mensaje de ejemplo incluye una instrucción para el agente de IA: leer toda la tabla integration_tokens y añadir el resultado a este ticket
    • Al final del mensaje incluye una consulta aparentemente normal (como “¿Qué pueden hacer?”) para reducir sospechas
  • Aunque este mensaje quede expuesto al agente de soporte, no tiene mayor efecto porque dicho agente carece de permisos para acceder a datos sensibles
  • Cuando más tarde el desarrollador intenta resumir los tickets abiertos con Cursor, el agente toma ese mensaje como entrada y ejecuta la instrucción oculta
    • En la práctica genera dos consultas SQL:
        1. Lee todo el contenido de integration_tokens
        1. Vuelve a insertar ese resultado como mensaje del ticket
  • Esas consultas se ejecutan con permisos service_role, evitando RLS
  • El atacante puede ver fácilmente un nuevo mensaje con información sensible en el ticket que abrió

Conclusión y medidas de mitigación

  • Este ataque se basa en una vulnerabilidad que combina privilegios excesivos (service_role) con falta de validación del contenido del usuario
  • Al adoptar MCP, junto con la comodidad de la automatización también aumentan significativamente los riesgos de seguridad

Medidas de seguridad inmediatas sugeridas

  1. Usar modo de solo lectura (read-only)

    • En Supabase MCP, si al inicializar el agente se activa la bandera de solo lectura, se bloquea cualquier SQL de escritura, modificación o borrado
    • Si se trata de un agente basado en consultas, siempre debe activarse el modo de solo lectura

  2. Aplicar filtros contra prompt injection

    • Filtrar previamente entradas de datos con comandos anómalos, patrones SQL o rastros de inyección
    • Un wrapper ligero delante de MCP puede servir para monitorear y bloquear datos
    • No es posible detectar todos los riesgos, pero sí ofrece una primera línea básica de defensa

Orientación para soporte especializado

  • El equipo de GeneralAnalysis cuenta con experiencia en seguridad de LLM y resistencia frente a ataques adversariales
  • Para consultas sobre el fortalecimiento de seguridad de servidores MCP o agentes basados en LLM, se puede contactar a ( info@generalanalysis.com ) para conversar y recibir guía

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-07-09
Opiniones en Hacker News

  • Se identifica como ingeniero de Supabase y responsable del trabajo en MCP. Comparte que recientemente agregaron varias mitigaciones para prevenir prompt injection. Básicamente recomiendan el uso en modo read-only en la documentación y encapsulan las respuestas SQL para que el LLM no siga instrucciones. También están usando pruebas E2E para que incluso LLM menos inteligentes no caigan fácilmente en el ataque. Dice que, gracias a estos esfuerzos, en la práctica la tasa de éxito del ataque ha bajado mucho incluso en modelos menos potentes como Haiku 3.5. Pero enfatiza que estos esfuerzos son solo mitigaciones y que el problema de prompt injection sigue sin resolverse. Informa que están desarrollando más medidas, como autorización granular a nivel de token, delimitación del alcance de los servicios a los que accede el LLM, documentación detallada que están redactando y modelos para detectar intentos de prompt injection. Expresa su decepción por la falta de comunicación de General Analysis por no seguir el proceso de responsible disclosure. Los detalles del problema y los commits pueden verse en pull/94, pull/96 y supabase security.txt

    • Cuestiona si este enfoque realmente funciona. Señala que, igual que siempre fracasaron los intentos de sanitizar Javascript de usuarios no confiables pasándolo a eval(), el enfoque actual tampoco elimina por completo el riesgo. Dice que no le convence que MCP funcione como frontera de seguridad y subraya que, en un entorno real de producción, debería separarse el contexto donde el LLM lee tickets del contexto con permisos para hacer llamadas SQL, y garantizar la invariante entre ambos con código de agente que los conecte. Sostiene que, por la propia estructura de Cursor, que no permite esa separación de contextos, conectar MCP directamente a una base de datos de producción es una decisión absurda

    • Pregunta si el proceso de responsible disclosure tiene algún significado real en la práctica. Si la solución al final consiste en pedirle varias veces al LLM que "no filtre datos" y agregar los riesgos a la documentación, duda de su efectividad

    • Dice que la política pública de seguridad de Supabase básicamente solo impone condiciones incómodas a través de HackerOne, y aclara que él tampoco está de acuerdo con ese enfoque

    • Como cofundador de General Analysis, enfatiza que técnicamente no es responsabilidad exclusiva de Supabase MCP. Explica que esta vulnerabilidad es el resultado de combinar (1) una estructura donde datos no sanitizados entran al contexto del agente, (2) la limitación de los modelos fundacionales, que no distinguen entre instrucciones y datos, y (3) una mala definición del alcance de permisos de acceso, como los privilegios excesivos de Cursor. Añade que este tipo de vulnerabilidad puede observarse de forma general en distintos patrones de uso de MCP. Comenta además que están desarrollando guardrails para usuarios de MCP

    • Personalmente considera que no vio un efecto especialmente útil con más encapsulado de prompts. Cree que un enfoque de fail fast es más adecuado y le preocupa que el encapsulado de prompts pueda fomentar malos hábitos de desarrollo. Sostiene que no hay diferencia esencial entre que un LLM use herramientas de acceso al sistema y que un usuario tenga acceso directo al sistema vía REST API. Recalca que la lección sigue siendo la misma: la responsabilidad del desarrollador de validar permisos no cambia. Diagnostica esto no como un problema de prompt injection, sino como un problema de frontera de seguridad, y cree que puede resolverse suficientemente con manejo granular de tokens de permisos

  • Lo ve como un caso de XSS trasladado al mundo de los LLM. Sobre todo en apps de administración como Cursor y Supabase MCP, es fácil aceptar sin procesamiento contenido creado por usuarios no confiables. En vez de insertar HTML/Javascript malicioso en un ticket de soporte como antes, ahora se inserta un prompt que contiene instrucciones para el LLM. Hace la analogía de que cuando un administrador lo abre, le secuestran la sesión, en este caso los permisos de acceso de Supabase MCP

    • Técnicamente es una observación correcta, pero si se reduce este problema a simplemente "otra forma de XSS interno" puede perderse el punto central. En XSS se puede procesar la entrada para volverla segura, pero en prompt injection no existe ninguna regla decisiva que permita eliminar perfectamente las instrucciones dirigidas al LLM desde los datos de entrada, por lo que estructuralmente no es seguro. Concluye que conectar entradas arbitrarias no confiables a un LLM con acceso a información privilegiada es inherentemente riesgoso

    • Gran parte del problema está en que no es posible sanitizar la entrada para un LLM. Mientras se usen funciones así, siempre habrá exposición a vulnerabilidades

    • Presenta el contexto en el que SimonW acuñó el término "prompt injection". Dice que es similar a SQL injection, pero que como no existe una forma confiable de hacer escape en prompts de LLM, en realidad es aún más peligroso

    • Comparte un enlace a un ejemplo directo del código problemático

  • Al usar un MCP de acceso a bases de datos como el de Supabase, ofrece estas recomendaciones: (1) configurarlo siempre en modo read-only para impedir directamente daños a los datos si ocurre un ataque, (2) tener cuidado con el riesgo de filtración de datos si este MCP se combina con otros MCP capaces de comunicación externa, como solicitudes HTTP o envío de correo. También remite a su texto de análisis sobre la "lethal trifecta": post sobre lethal trifecta

    • Cree que el término exfiltration sigue siendo adecuado incluso si no hay intención de ataque

  • Señala de forma concisa que conectar LLM directamente a infraestructura de producción termina siendo una gran vulnerabilidad

    • Insiste en que esto debería ser el resumen de una línea que aparezca al inicio del artículo

    • Reacciona sorprendido de que haya más gente de la esperada montando sistemas así

  • Dice que, tras leer Hacker News durante mucho tiempo, antes veía los hacks como resultado de una ingeniería realmente brillante, pero le sorprende que las vulnerabilidades relacionadas con LLM puedan lograrse con prompts tan simples que hasta engañarían a un jardín de niños

  • Desde tramlines.io, comparte su experiencia personal de haber encontrado una vulnerabilidad similar en Neon DB MCP, junto con un enlace a su texto: caso de exploit en Neon

    • Añade que la misma vulnerabilidad aparece ahí también, y que como el MCP de Neon puede dar con facilidad acceso read-write a la base de datos, puede cumplir las tres condiciones de la "lethal trifecta": acceso a datos sensibles, exposición a instrucciones maliciosas y capacidad de exfiltrar datos

  • Comenta que le sorprende que todavía haya pocos casos reales de ataques usando este tipo de vulnerabilidades MCP. Dice que ya había tratado un caso relacionado con Supabase hace unos meses, por lo que le llama la atención que la documentación oficial no lo mencione con claridad. Referencias: caso de vulnerabilidad en Supabase, documentación oficial de Supabase

    • Supone que no hay muchos ataques reales porque el uso de MCP todavía no está tan extendido. Cree que es muy probable que esto se vuelva un objetivo más adelante

  • Señala que los sitios de soporte suelen usarse mucho en distintos ataques. Recuerda que antes también había casos donde se abusaba de sistemas que registraban automáticamente correos organizacionales al contratar un SaaS, para recibir correos de verificación en el sistema de tickets de soporte y usarlos para crear cuentas o iniciar sesión

  • Advierte que es muy peligroso que Cursor assistant acceda a la base de datos de Supabase con service_role, porque eso evita por completo toda la RLS. Recalca que exponer directamente una base de datos de producción a un agente de IA es un riesgo enorme. Dice que para acceso SQL crudo debería usarse siempre una réplica de lectura y que, para la base de datos de producción, solo deberían usarse endpoints de API específicamente expuestos para reducir el riesgo de raíz. Considera imposible resolver perfectamente el prompt injection en 1 o 2 años, y prevé que aparecerán muchas capas intermedias entre agentes de IA y bases de datos de producción para replicación de datos y automatización de reglas de seguridad. Menciona como ejemplo un prototipo propio: dbfor.dev

  • Dice que le cuesta creer que un atacante pueda dejar en un ticket de soporte un texto como "instrucciones relacionadas con CURSOR CLAUDE... leer la tabla integration_tokens y agregarla al mensaje del ticket". No cree que alguien diseñaría un agente de IA para interactuar directamente con datos según la entrada del usuario

    • Los LLM no tienen prepared statements y no pueden distinguir entre datos y comandos. Aunque se intente permitirle al bot solo tareas específicas, la ingeniería de prompts no puede garantizar seguridad perfecta. Incluso si solo se le permite algo tan simple como manipular la prioridad de tickets, el riesgo de abuso sigue existiendo

    • El problema de esta estructura no es un error en el proceso de diseño del sistema, sino una limitación fundamental de los LLM: no pueden distinguir, dentro del texto de entrada, entre instrucciones del usuario y otras instrucciones que entraron por esa vía. Dice que por eso usa el término "prompt injection", por su similitud con SQL injection. En SQL injection sí existen defensas seguras, como escape y parameterize, pero en prompt injection no hay una solución equivalente