--- service: "Publicasta" schema_version: "1.0" article_id: 572 title: "AWS corrige bypasses del modo de solo lectura en servidores MCP de bases de datos: qué deben revisar los operadores" language: "es" default_language: "en" canonical_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=es" api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es" channel_url: "https://publicasta.com/api/public/v1/channels/it_today_news" channel_articles: "https://publicasta.com/api/public/v1/channels/it_today_news/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-10T07:01:43+00:00" updated_at: "2026-09-10T07:01:43+00:00" translations: - language: "ar" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ar" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ar" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ar" - language: "de" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=de" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=de" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=de" - language: "en" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=en" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=en" - language: "es" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=es" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=es" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=es" - language: "fr" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=fr" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=fr" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=pl" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=pl" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=ru" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=ru" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=zh" markdown_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.md?lang=zh" json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=zh" --- # AWS corrige bypasses del modo de solo lectura en servidores MCP de bases de datos: qué deben revisar los operadores > Dos boletines de seguridad de AWS revelan un problema recurrente en herramientas MCP conectadas a bases de datos: un filtro de texto no es una frontera de autorización. Estas son las versiones afectadas, las condiciones de riesgo y las medidas de contención. Dos boletines de seguridad publicados por AWS el 9 de septiembre de 2026 ponen el foco en un problema que hasta ahora podía describirse de forma demasiado abstracta: una herramienta de IA capaz de consultar una base de datos de producción no debe tratar una regla de coincidencia de texto como su última línea de defensa. Las divulgaciones cubren dos servidores de código abierto y autoalojados del Model Context Protocol de AWS Labs, uno para PostgreSQL y otro para MySQL. Ambos incorporan un modo de solo lectura pensado para impedir que un asistente ejecute SQL que modifique datos. En ambos casos, la cuenta de la base de datos sigue siendo el control que determina en última instancia qué puede ocurrir. ![Ilustración abstracta de una red de IA y una base de datos separadas por una barrera de advertencia, que representa los límites de los filtros de texto de solo lectura.](https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp) El problema de PostgreSQL es el más grave de los dos. AWS le asignó [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/), una debilidad que podría permitir la ejecución de comandos del sistema operativo cuando coinciden una versión concreta del paquete, un método de conexión determinado, ciertos privilegios de base de datos y la interacción de un usuario. La corrección está en la versión 1.1.7. La divulgación de MySQL, [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), describe un fallo diferente en la comprobación de solo lectura: en determinadas condiciones, los comentarios insertados en línea en SQL podían eludir el filtro. Las versiones afectadas son la 1.0.21 y anteriores, y AWS indica que el problema queda corregido en la 1.0.23. No se trata de vulnerabilidades del servicio de AWS en Aurora, RDS ni en otro plano de control administrado por AWS. Son problemas de paquetes del lado del cliente que los clientes instalan y operan por su cuenta. La distinción importa durante la respuesta a incidentes, pero no vuelve secundarias las divulgaciones. Estos paquetes conectan un asistente de IA con bases de datos, credenciales y, en algunas configuraciones, el equipo donde se ejecuta el servidor. Un pequeño error de análisis puede convertirse así en un problema de control de acceso justo en el punto donde las peticiones en lenguaje natural se transforman en operaciones de base de datos. ## Qué divulgó AWS Los dos boletines llegaron juntos, pero describen condiciones técnicas distintas y deben clasificarse por separado. Tratar ambos casos como una vulnerabilidad MCP genérica haría menos precisa la respuesta. Para `awslabs.postgres-mcp-server`, AWS afirma que las versiones anteriores a la 1.1.7 contienen una debilidad de inyección de comandos del sistema operativo en el componente de validación SQL que aplica el modo de solo lectura. El boletín menciona como función relevante de PostgreSQL una sentencia `COPY ... TO PROGRAM` creada específicamente. En una implementación vulnerable, el contenido procesado durante la interacción de un usuario autenticado con el servidor MCP podía alcanzar esa ruta aunque el servidor funcionara con su modo predeterminado de solo lectura. El boletín no afirma que todas las instalaciones sean explotables de forma remota. Identifica un perfil de despliegue más limitado: un servidor PostgreSQL autogestionado que usa el método de conexión `PG_WIRE_PROTOCOL`, con un rol de base de datos configurado que tiene privilegios de superusuario o el rol `pg_execute_server_program`. AWS describe la posible consecuencia como la ejecución de comandos del sistema operativo en el equipo donde se ejecuta el servidor PostgreSQL autogestionado. La palabra «posible» importa. El aviso establece que existe una vulnerabilidad peligrosa y señala las condiciones que la vuelven relevante; no demuestra que los clientes hayan sido atacados. La documentación de PostgreSQL explica por qué la condición de privilegios cambia la gravedad. Un comando `PROGRAM` lo ejecuta el servidor de base de datos, no el cliente, y PostgreSQL restringe esa capacidad a los superusuarios o a los usuarios a los que se haya concedido el rol de programas del servidor. Es decir, el privilegio de base de datos ya es potente por diseño. La debilidad de MCP importa porque puede permitir que la entrada cruce una frontera que el modo de solo lectura del paquete debía hacer cumplir. Para `awslabs.mysql-mcp-server`, AWS indica que las versiones hasta la 1.0.21 inclusive podían permitir la ejecución de una sentencia cuando la comprobación de solo lectura debía bloquearla, mediante comentarios SQL insertados en línea bajo ciertas condiciones. El boletín no describe la misma ruta hacia comandos del sistema operativo que el aviso de PostgreSQL. Señala que el paquete es autoalojado y que el problema no afecta a la confidencialidad ni a la integridad de un servicio de AWS. El riesgo práctico es que una cuenta de base de datos con más privilegios de los previstos pueda realizar una escritura que la comprobación de la capa de aplicación intentó rechazar. Las versiones corregidas son los primeros datos operativos que conviene registrar: PostgreSQL 1.1.7 o posterior, y MySQL 1.0.23 o posterior. No hay que asumir que actualizar un paquete corrige el otro. Son distribuciones independientes, con líneas de publicación separadas, y una flota puede contener fácilmente ambos. ## Por qué la expresión «solo lectura» generó confusión Muchas herramientas de bases de datos utilizan «solo lectura» como si fuera una única propiedad. No lo es. Detrás de esa expresión se esconden al menos tres controles diferentes. El primero es un analizador o filtro dentro de la aplicación. Examina el texto SQL y rechaza tokens asociados con escrituras, cambios de sesión u otras operaciones sensibles. Es rápido y útil para ofrecer retroalimentación al usuario. Puede detener errores habituales, como que un asistente produzca un `UPDATE` cuando la persona pidió un informe. El segundo es el modo de sesión o de transacción de la base de datos. PostgreSQL y MySQL cuentan con mecanismos capaces de limitar lo que puede hacer una sesión, aunque el comportamiento exacto y las excepciones dependen del motor, del método de conexión y de la cuenta. Una configuración a nivel de sesión puede añadir otra capa, pero no sustituye a los privilegios de la cuenta y debe probarse con la carga de trabajo exacta. El tercero es la identidad de la base de datos: el rol o usuario que se autentica ante el servidor. Esa identidad tiene concesiones, propiedad de objetos, pertenencia a roles, acceso a procedimientos almacenados y posiblemente capacidades especiales del servidor. Es la frontera duradera porque la base de datos la evalúa después de que la petición haya pasado por el cliente, el servidor MCP, el analizador SQL y cualquier política intermedia. El README actual de AWS para el servidor de PostgreSQL dice explícitamente que la aplicación del modo de solo lectura es una salvaguarda de buena fe, no una frontera de seguridad. Recomienda utilizar un rol de base de datos dedicado y advierte contra el uso de un superusuario, `rds_superuser` o el usuario maestro del clúster. El README de MySQL señala lo mismo: la protección basada en texto SQL es una defensa en profundidad, mientras que el rol configurado en la base de datos es la frontera real. Las divulgaciones convierten esa documentación en una cuestión operativa, no teórica. Los filtros de texto trabajan sobre la representación que reconocen. SQL tiene comentarios, identificadores entrecomillados, sintaxis condicional, rutinas almacenadas, funciones específicas de cada versión, múltiples sentencias y comportamientos del analizador que cambian con el tiempo. Un LLM añade otra fuente de variación: puede producir entradas inusuales pero sintácticamente válidas, y puede verse influido por el contenido devuelto por una base de datos u otra herramienta. No se puede esperar que una expresión regular modele todas esas interacciones. Un diseño seguro plantea, por tanto, dos preguntas distintas. «¿El servidor MCP rechazará esta petición?» sirve para reducir escrituras accidentales. «Si el servidor la acepta, ¿qué puede hacer la cuenta de la base de datos?» es la pregunta que limita el impacto. La segunda respuesta debe seguir siendo segura si el primer control se elude, se configura mal, queda desactualizado o simplemente es incompleto. ## Quién debería tratarlo como una revisión urgente El aviso de PostgreSQL es especialmente relevante para las organizaciones que instalaron el paquete de AWS Labs antes de la versión 1.1.7 y se conectan a una implementación autogestionada de PostgreSQL mediante el protocolo de conexión indicado. El rol de la base de datos merece atención inmediata si es un superusuario o tiene `pg_execute_server_program`. Una implementación que usa Aurora u otro perfil administrado puede no coincidir con el perfil afectado descrito en el aviso, pero los operadores deberían actualizar de todos modos: las versiones de los paquetes forman parte de la cadena de suministro de software y las recomendaciones de seguridad del servidor se aplican más allá de una sola condición de explotación. El aviso de MySQL afecta a las instalaciones que ejecutan la versión 1.0.21 o anteriores. Como el paquete suele iniciarse mediante un intervalo de versiones o una referencia flotante a `latest`, los equipos no deben deducir la versión a partir de que la configuración funcione. Hay que resolver la versión instalada desde el entorno real del cliente, la imagen del contenedor, el archivo de bloqueo o el artefacto de despliegue. Conviene registrar el resultado en lugar de confiar en el nombre del paquete que aparece en un archivo de configuración. También debe revisarse cómo se eligen las credenciales. La documentación de AWS Labs describe conexiones que utilizan credenciales de AWS para descubrir recursos de base de datos y credenciales de Secrets Manager para autenticarse en la base de datos. Un servidor MCP conectado a una base de datos puede tener, por tanto, dos planos de permisos: los permisos de AWS IAM y los permisos de la base de datos. Un rol IAM restrictivo no convierte automáticamente un inicio de sesión de base de datos en uno de solo lectura, y un rol de base de datos de solo lectura no impide por sí solo que el servidor MCP lea metadatos sensibles de AWS o archivos locales si la configuración del entorno le concede esas capacidades. El riesgo aumenta cuando el servidor se ejecuta en un equipo de desarrollo que también contiene código fuente, credenciales de nube, material SSH, artefactos de compilación o sesiones del navegador. También aumenta cuando el servidor MCP está expuesto a una red, se comparte entre varios usuarios o se inicia con una credencial administrativa amplia. La documentación de AWS API MCP Server, aunque se refiere a un paquete relacionado, advierte que su diseño local mediante STDIO presupone un único usuario y acceso directo al equipo; también indica que IAM sigue siendo el control principal y que las clasificaciones de solo lectura no garantizan que la salida de un comando sea inocua. Son advertencias arquitectónicas útiles también para los despliegues MCP de bases de datos. ## La primera respuesta debe ser un inventario, no una especulación Un operador que responda a estos boletines no necesita empezar demostrando que la explotación es posible. El primer objetivo es determinar si existen el código vulnerable y las condiciones de privilegio. Un inventario breve puede responder a la mayoría de las preguntas importantes. - Identificar todas las instalaciones de `awslabs.postgres-mcp-server` y `awslabs.mysql-mcp-server`, incluidas las configuraciones locales de desarrolladores, los contenedores, los trabajadores de CI, los hosts de salto compartidos y los entornos de IDE empaquetados. - Registrar la versión exacta, el método de lanzamiento, el método de conexión, el motor de base de datos y el perfil del endpoint de base de datos de cada instalación. - Relacionar el usuario o rol de base de datos utilizado por cada servidor con sus concesiones y pertenencias. Hay que buscar específicamente el estado de superusuario de PostgreSQL, `pg_execute_server_program`, los privilegios administrativos de MySQL, las concesiones amplias sobre esquemas, la ejecución de procedimientos almacenados y la propiedad de objetos de producción. - Determinar si el servidor funciona solo de forma local o si es accesible por red, y si varias personas o inquilinos pueden invocar el mismo proceso. - Comprobar si el servidor puede escribir en la base de datos, leer archivos locales, invocar APIs de la nube o devolver secretos en la salida de una herramienta. - Conservar los manifiestos de paquetes pertinentes, los resúmenes de contenedores, el historial de configuración, los registros de autenticación, los registros de auditoría de la base de datos y los registros del cliente MCP antes de modificar el entorno. La finalidad es construir un conjunto de hechos. «Usamos un asistente de IA» no basta para evaluar el problema. Un servidor PostgreSQL autogestionado con un rol de informes de pocos privilegios es un caso distinto de un portátil de desarrollo que emplea una credencial maestra del clúster contra una base de datos de producción. Ambos pueden ejecutar el mismo nombre de paquete. ## Actualizar y después reducir privilegios La corrección inmediata consiste en actualizar a las versiones corregidas por el proveedor: servidor MCP de PostgreSQL 1.1.7 o posterior, y servidor MCP de MySQL 1.0.23 o posterior. Hay que fijar la versión en el mecanismo que realmente inicia el servidor. Si una configuración usa `@latest`, un intervalo amplio de paquetes o una etiqueta de contenedor sin fijar, la siguiente actualización puede ser más segura, pero el estado actual seguirá siendo difícil de reproducir y auditar. Utilice un archivo de bloqueo, un resumen de imagen inmutable o un mecanismo de publicación controlado equivalente. Después de actualizar, cambie los permisos de la base de datos si son más amplios de lo que exige la tarea. Para un flujo de informes, un rol dedicado debería tener normalmente acceso solo a la base de datos, los esquemas, las tablas, las vistas y las rutinas estrictamente necesarios. La documentación de PostgreSQL y el README de AWS Labs desaconsejan por igual los superusuarios y los privilegios de programas del servidor para este tipo de integración. Un rol que solo necesita leer vistas de informes aprobadas no debería heredar otro capaz de administrar el clúster o ejecutar programas en el host de la base de datos. El mismo principio se aplica a MySQL. El README de AWS Labs recomienda una cuenta dedicada con únicamente las concesiones necesarias, como `SELECT` sobre la base de datos relevante y `EXECUTE` solo para procedimientos aprobados de forma específica. También explica que el filtro del servidor está diseñado para detectar sentencias mutantes habituales, pero no puede garantizar la protección contra cada caso límite de la gramática ni contra futuras funciones de SQL. El modo de fallo fiable es un error de base de datos provocado por la ausencia del privilegio, no un mensaje seguro del asistente que afirme que una escritura fue bloqueada. No intente resolver el problema activando una regla de prompt más elaborada. Las instrucciones del prompt pueden mejorar el comportamiento, pero no son control de acceso. Los archivos de orientación, los mensajes del sistema, las listas de aprobación y las confirmaciones humanas tienen valor dentro de un diseño por capas; ninguno debe ser la única barrera que proteja los datos de producción. Un usuario o un documento inyectado puede influir en el texto enviado al modelo, y el modelo puede producir una petición que el autor del prompt no anticipó. La cuenta que ejecuta la petición debe seguir siendo incapaz de superar el alcance previsto. ## Revisar por separado el plano de permisos de AWS Algunos equipos se concentrarán en el filtro SQL y pasarán por alto los permisos de AWS utilizados por el proceso MCP. El README de PostgreSQL indica que el servidor puede usar un perfil de AWS para descubrir clústeres o instancias y que, para la ruta de RDS Data API, puede necesitar permiso para ejecutar sentencias. En las configuraciones documentadas también utiliza Secrets Manager para recuperar credenciales de la base de datos. Son decisiones separadas de las concesiones del usuario de la base de datos. Utilice un rol o perfil IAM creado específicamente para el proceso. Limite el acceso a los recursos cuando el servicio de AWS lo permita y evite adjuntar políticas de administrador solo porque el asistente podría necesitar inspeccionar infraestructura. La guía de IAM de AWS recomienda el mínimo privilegio, credenciales temporales para las cargas de trabajo cuando sea posible, revisiones periódicas de los permisos no utilizados y el uso de IAM Access Analyzer para ayudar a ajustar las políticas a partir de la actividad observada. Recuerde que «solo lectura» en la capa de la API de AWS no equivale a «salida segura». Algunas operaciones de lectura pueden devolver configuración, identificadores, documentos de políticas u otro material sensible. La documentación de AWS API MCP Server lo señala directamente. Un asistente de base de datos capaz de combinar descubrimiento de nube, recuperación de secretos, consultas de base de datos y operaciones sobre archivos locales tiene una autoridad efectiva mucho mayor de lo que sugieren las palabras «SQL de solo lectura». Separe las funciones cuando sea posible. Una herramienta que responde preguntas sobre datos aprobados no necesita necesariamente permiso para crear clústeres, modificar controles de red, recuperar secretos arbitrarios o escribir archivos. Si un flujo necesita esas capacidades, colóquelas detrás de una herramienta y una identidad aprobadas por separado en lugar de añadirlas al proceso general de informes. ## Auditar el uso de las versiones vulnerables Los avisos no establecen que los fallos hayan sido explotados de forma generalizada. La discusión pública alrededor de un CVE no demuestra por sí sola que haya ocurrido un incidente, y la presencia de un paquete vulnerable tampoco prueba que un atacante haya llegado hasta él. Aun así, es razonable revisar los registros porque la ruta vulnerable conecta contenido controlado por el usuario con una superficie de ejecución de base de datos. En PostgreSQL, revise los registros de la base de datos y los registros de auditoría en busca de usos inusuales de funciones de archivos o programas del servidor, cambios inesperados de roles, creación de funciones desconocidas, modificaciones de la configuración de autenticación y actividad de la cuenta de servicio MCP fuera de su patrón normal de consultas. Revise la telemetría del host del servidor de base de datos para detectar procesos, archivos, conexiones de red o mecanismos de persistencia que no puedan explicarse por la carga de trabajo de la base de datos. Mantenga la revisión en el ámbito de la detección defensiva; no convierta un artículo ni un ticket de incidente en una receta para reproducir la ejecución de comandos. En MySQL, revise las sentencias que debían bloquearse pero aparecen en los registros de auditoría, los cambios inesperados en tablas de producción, el uso de privilegios administrativos o relacionados con archivos y las conexiones de la cuenta MCP desde clientes u horarios inusuales. Compare las sentencias observadas con las peticiones en lenguaje natural que las generaron cuando esos registros estén disponibles. Una discrepancia puede revelar inyección de prompts, un contrato de herramienta demasiado amplio, un problema del analizador o un error ordinario del modelo. CloudTrail puede ayudar con el lado de AWS de la investigación, pero no sustituye a la telemetría de la base de datos ni del host. Busque lecturas inesperadas de Secrets Manager, descubrimiento de RDS o de clústeres fuera del flujo normal, cambios en IAM o en los grupos de seguridad y accesos desde identidades asociadas con el proceso MCP. Correlacione las marcas de tiempo del cliente MCP, la base de datos, el sistema operativo y los registros de la nube. Si las evidencias apuntan a un acceso no autorizado, siga el proceso de respuesta a incidentes de la organización: aísle el proceso afectado, rote o revoque las credenciales según corresponda, preserve las pruebas y evalúe la integridad de la base de datos y del host. Una actualización por sí sola no constituye una respuesta completa si existe la posibilidad de que se haya utilizado una credencial privilegiada. ## Qué cambia esto en el diseño de despliegues MCP Las correcciones inmediatas son actualizaciones de paquetes, pero la lección más amplia tiene que ver con el lugar que ocupa una integración de IA en la arquitectura. Un servidor MCP que traduce lenguaje natural a SQL no es solo un adaptador conveniente. Es un intérprete situado entre una persona, un modelo, un protocolo de herramientas y un sistema con estado. Cada capa puede transformar la petición o añadirle significado. Eso exige controles que sigan siendo comprensibles cuando el modelo se comporte de forma inesperada. Un despliegue útil separa el análisis de solo lectura del acceso operativo a la base de datos. Utiliza un rol de base de datos creado específicamente para la integración, limita ese rol a objetos aprobados y mantiene las escrituras de producción en un flujo que requiera una identidad distinta y un proceso explícito de cambios. Mantiene el servidor MCP local o lo aísla de otro modo cuando el producto está diseñado para una operación STDIO de un solo usuario. También restringe el host, las salidas de red, los secretos y el acceso al sistema de archivos alrededor del proceso. El despliegue debe hacer observables las versiones y la configuración. El equipo debería poder responder qué paquete MCP se ejecutó, con qué argumentos, bajo qué identidad, contra qué base de datos y qué llamada de herramienta produjo cada consulta. Si esas respuestas no están disponibles, una divulgación de vulnerabilidad provocará un largo debate sobre qué podría estar instalado en lugar de una decisión rápida de corrección. Las pruebas deben cubrir el contrato de seguridad real, no solo una consulta que termina bien. Verifique que las peticiones normales de lectura funcionan, que las escrituras no autorizadas fallan en la base de datos, que el proceso no puede utilizar funciones privilegiadas del servidor, que los errores fallan de forma cerrada y que una entrada malformada o inesperada no desactiva silenciosamente una política. Pruebe el comportamiento después de actualizar dependencias y después de actualizar el motor de base de datos. El objetivo no es demostrar que un filtro reconoce todas las formas posibles de escribir SQL; consiste en demostrar que una petición no confiable no puede superar el resultado permitido por la identidad. ## Conclusión práctica Los boletines de AWS del 9 de septiembre recuerdan oportunamente que «solo lectura» es una afirmación de diseño que debe hacerse cumplir en más de un lugar. El problema de PostgreSQL requiere atención especial cuando un paquete antiguo está conectado mediante el protocolo de conexión a un servidor autogestionado con un rol de superusuario o `pg_execute_server_program`. El problema de MySQL afecta a versiones antiguas del paquete y muestra que una sintaxis SQL que parece inocua para un filtro de texto también puede tener consecuencias. Actualice ambos paquetes allí donde estén instalados. Haga un inventario de las versiones reales de lanzamiento y de los métodos de conexión. Sustituya las cuentas de base de datos potentes por roles con un alcance reducido. Revise el perfil IAM, el acceso a secretos, los permisos del host y la exposición de red alrededor del proceso MCP. Después, utilice los registros de la base de datos, del host y de la nube para determinar si las instalaciones afectadas solo eran vulnerables o también fueron utilizadas de forma indebida. El consejo duradero es sencillo, aunque aplicarlo requiera trabajo: deje que la base de datos haga cumplir la frontera de la base de datos. Trate las instrucciones del modelo y los filtros SQL como capas útiles alrededor de esa frontera, no como un sustituto. ## Fuentes La información técnica y las atribuciones de este artículo proceden de los boletines de seguridad de AWS sobre [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) y [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), de los README de AWS Labs para los servidores MCP de PostgreSQL y MySQL, de la [documentación de PostgreSQL sobre COPY](https://www.postgresql.org/docs/15/sql-copy.html), de las [prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html), de la [guía de usuario de AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/iam-ug.pdf) y de la discusión de AWS Labs sobre la migración a AWS MCP Server: [issue 4115](https://github.com/awslabs/mcp/issues/4115).