---
service: "Publicasta"
schema_version: "1.0"
article_id: 572
title: "AWS fixes read-only bypasses in database MCP servers: what operators need to check"
language: "en"
default_language: "en"
canonical_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en"
json_url: "https://publicasta.com/it_today_news/aws_mcp_database_servers_read_only_bypass_september_2026.json?lang=en"
api_url: "https://publicasta.com/api/public/v1/channels/it_today_news/articles/aws_mcp_database_servers_read_only_bypass_september_2026?lang=en"
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:41+00:00"
updated_at: "2026-09-10T07:01:41+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 fixes read-only bypasses in database MCP servers: what operators need to check

> Two AWS security bulletins published on September 9 expose a recurring design problem in database-connected MCP tools: a text filter is not an authorization boundary. Here is who is affected, what the disclosures actually say, and how to contain the risk.

Two AWS security bulletins published on September 9, 2026, put a sharp edge on a problem that has been easy to describe abstractly: an AI tool that can query a production database must not treat a string-matching rule as its last line of defense. The disclosures cover two open-source, self-hosted Model Context Protocol servers from AWS Labs, one for PostgreSQL and one for MySQL. Both use a read-only mode intended to stop an assistant from issuing mutating SQL. In both cases, the database account remains the control that ultimately determines what can happen.

 ![Abstract illustration of an AI network and database separated by a warning gate, representing the limits of read-only text filters.](https://publicasta.com/storage/projects/17/pages/572/2026/09/dda7b4d7-2f7d-4716-88da-cc06ee10f526.webp)

 The PostgreSQL issue is the more serious of the two. AWS assigned [CVE-2026-87911](https://aws.amazon.com/security/security-bulletins/2026-104-aws/) to a weakness that could allow operating-system command execution when a particular combination of package version, connection method, database privileges, and user interaction is present. The fix is version 1.1.7.

 The MySQL disclosure, [CVE-2026-85788](https://aws.amazon.com/security/security-bulletins/2026-103-aws/), describes a different failure in the read-only check: under certain conditions, SQL inline comments could circumvent the filter. The affected package versions are 1.0.21 and earlier, and AWS says the issue is addressed in 1.0.23.

 These are not AWS service-side vulnerabilities in Aurora, RDS, or another managed AWS control plane. They are problems in client-side packages that customers install and operate themselves. That distinction matters for incident response, but it does not make the disclosures peripheral. The packages connect an AI assistant to databases, credentials, and in some configurations the host on which the server runs. A small parser mistake can therefore become an access-control problem at the point where natural-language requests are converted into database operations.

 ## What AWS disclosed

 The two bulletins arrived together, but they describe different technical conditions and should be triaged separately. Treating them as one generic MCP vulnerability would make the response less precise.

 For `awslabs.postgres-mcp-server`, AWS says versions before 1.1.7 contain an OS command injection weakness in the SQL validation component's read-only enforcement. The bulletin names a crafted PostgreSQL `COPY ... TO PROGRAM` statement as the relevant database feature. In a vulnerable deployment, content processed when an authenticated user interacts with the MCP server could reach that path even though the server was running in its default read-only mode.

 The bulletin does not say that every installation is remotely exploitable. It identifies a narrower deployment profile: a self-managed PostgreSQL server using the `PG_WIRE_PROTOCOL` connection method, with a configured database role that has superuser privileges or the `pg_execute_server_program` role. AWS describes the possible consequence as operating-system command execution on the host of the self-managed PostgreSQL server. The word “possible” is important here. The advisory establishes a dangerous vulnerability and the conditions that make it relevant; it does not establish that customers were attacked.

 PostgreSQL's own documentation explains why the privilege condition changes the severity. A `PROGRAM` command is executed by the database server rather than by the client, and PostgreSQL restricts that capability to superusers or users granted the server-program role. In other words, the database privilege is already powerful by design. The MCP weakness matters because it can let input cross a boundary that the package's read-only mode was expected to enforce.

 For `awslabs.mysql-mcp-server`, AWS says versions through 1.0.21 can allow a statement to run when the read-only check was expected to block it, using SQL inline comments under certain conditions. The bulletin does not describe the same operating-system command path as the PostgreSQL advisory. It says the package is self-hosted and that the issue does not affect the confidentiality or integrity of an AWS service. The practical risk is that a database account with more privileges than intended may be able to perform a write that the application-layer check attempted to reject.

 The fixed versions are the first operational facts to record: PostgreSQL 1.1.7 or later, and MySQL 1.0.23 or later. Do not infer that upgrading one package fixes the other. They are separate distributions with separate release lines, and a fleet can easily contain both.

 ## Why the phrase “read-only” caused confusion

 Many database tools use “read-only” as if it were a single property. It is not. There are at least three different controls hiding behind that phrase.

 The first is a parser or filter inside the application. It examines SQL text and rejects tokens associated with writes, session changes, or other sensitive operations. This is fast and useful for user feedback. It can stop ordinary mistakes, such as an assistant producing an `UPDATE` when the user asked for a report.

 The second is the database session or transaction mode. PostgreSQL and MySQL each have mechanisms that can constrain what a session may do, although the exact behavior and exceptions depend on the engine, connection method, and account. A session-level setting can add another layer, but it is still not a substitute for account privileges and must be tested against the exact workload.

 The third is the database identity itself: the role or user that authenticates to the server. That identity has grants, ownership, role memberships, stored-procedure access, and possibly special server capabilities. It is the durable boundary because the database evaluates it after the request has passed through the client, the MCP server, the SQL parser, and any intermediate policy.

 AWS's current README for the PostgreSQL server says explicitly that read-only enforcement is a best-effort safeguard, not a security boundary. It recommends a dedicated database role and warns against using a superuser, `rds_superuser`, or cluster master user. The MySQL README makes the same point: the server's SQL-text guard is defense in depth, while the configured database role is the actual boundary.

 The disclosures make that documentation operational rather than theoretical. Text filters work on the representation they recognize. SQL has comments, quoted identifiers, conditional syntax, stored routines, version-specific features, multiple statements, and parser behavior that changes over time. An LLM adds another source of variation: it can produce unusual but syntactically valid input, and it can be influenced by content returned from a database or another tool. A regular expression cannot be expected to model all of those interactions.

 A safe design therefore asks two different questions. “Will the MCP server reject this request?” is useful for reducing accidental writes. “If the server accepts it, what can the database account do?” is the question that limits impact. The second answer must remain safe when the first control is bypassed, misconfigured, outdated, or simply incomplete.

 ## Who should treat this as an urgent review

 The PostgreSQL advisory is most relevant to organizations that installed the AWS Labs package before version 1.1.7 and connect to a self-managed PostgreSQL deployment using the wire protocol. The database role deserves immediate attention if it is a superuser or has `pg_execute_server_program`. A deployment that uses Aurora or another managed profile may not match the advisory's stated affected profile, but operators should still upgrade because package versions are part of the software supply chain and the server's security guidance applies beyond one exploit precondition.

 The MySQL advisory applies to installations on 1.0.21 or earlier. Because the package is commonly launched through a version range or a floating `latest` reference, teams should not assume that a working configuration tells them which code is running. Resolve the installed package version from the actual client environment, container image, lockfile, or deployment artifact. Record the result rather than relying on a package name in a configuration file.

 Teams should also review how credentials are selected. The AWS Labs documentation describes connections that use AWS credentials to discover database resources and Secrets Manager credentials to authenticate to the database. A database-connected MCP server can therefore have two permission planes: AWS IAM permissions and database permissions. A restrictive IAM role does not automatically make a database login read-only, and a read-only database role does not automatically prevent the MCP server from reading sensitive AWS metadata or local files if the surrounding configuration grants those capabilities.

 The risk is higher when the server runs on a developer workstation that also contains source code, cloud credentials, SSH material, build artifacts, or browser sessions. It is also higher when the MCP server is exposed over a network, shared among users, or launched with a broad administrator credential. The AWS API MCP Server documentation, although it concerns a related package, warns that its local STDIO design assumes a single user and direct host access; it also says that IAM remains the primary control and that read-only classifications do not guarantee that command output is harmless. Those are useful architectural warnings for database MCP deployments as well.

 ## The first response should be inventory, not speculation

 An operator responding to these bulletins does not need to begin by proving exploitability. The first goal is to establish whether the vulnerable code and privilege conditions exist. A short inventory can answer most of the high-value questions.

 - Identify every installation of `awslabs.postgres-mcp-server` and `awslabs.mysql-mcp-server`, including local developer configurations, containers, CI workers, shared jump hosts, and packaged IDE environments.
- Record the exact version, launch method, connection method, database engine, and database endpoint profile for each installation.
- Map the database user or role used by each server to its grants and memberships. Look specifically for PostgreSQL superuser status, `pg_execute_server_program`, MySQL administrative privileges, broad schema grants, stored-procedure execution, and ownership of production objects.
- Determine whether the server is local-only or reachable over a network, and whether multiple people or tenants can invoke the same process.
- Check whether the server can write to the database, read local files, invoke cloud APIs, or return secrets in tool output.
- Preserve relevant package manifests, container digests, configuration history, authentication logs, database audit records, and MCP client logs before changing the environment.

 The point is to build a fact pattern. “We use an AI assistant” is not enough to assess the issue. A self-managed PostgreSQL server with a low-privilege reporting role is a different case from a developer laptop using a cluster master credential against a production database. Both may run the same package name.

 ## Upgrade, then reduce privilege

 Upgrading to the vendor-fixed versions is the immediate remediation: PostgreSQL MCP server 1.1.7 or later, and MySQL MCP server 1.0.23 or later. Pin the version in the mechanism that actually launches the server. If a configuration uses `@latest`, a broad package range, or an unpinned container tag, the next update may be safer, but the current state will remain difficult to reproduce and audit. Use a lockfile, immutable image digest, or an equivalent controlled release mechanism.

 After upgrading, change the database permissions if they are broader than the task requires. For a reporting workflow, a dedicated role should generally have access only to the required database, schemas, tables, views, and narrowly selected routines. PostgreSQL's documentation and the AWS Labs README both point away from superusers and server-program privileges for this kind of integration. A role that only needs to read approved reporting views should not inherit a role that can administer the cluster or execute programs on the database host.

 The same principle applies to MySQL. The AWS Labs README recommends a dedicated account with only the required grants, such as `SELECT` on the relevant database and `EXECUTE` only for specifically approved procedures. It also explains that the server-side filter is designed to catch common mutating statements, but cannot be the guarantee against every grammar edge case or future SQL feature. The reliable failure mode is a database error caused by missing privilege, not a confident assistant message that claims a write was blocked.

 Do not “fix” the problem by turning on a more elaborate prompt rule. Prompt instructions can improve behavior, but they are not access control. Steering files, system messages, approval lists, and human confirmation prompts all have value in a layered design; none should be the only barrier protecting production data. A user or an injected document can influence the text sent to the model, and a model can produce a request the prompt author did not anticipate. The account that executes the request must still be unable to exceed the intended scope.

 ## Check the AWS permission plane separately

 Some teams will focus on the SQL filter and miss the AWS permissions used by the MCP process. The PostgreSQL README says the server may use an AWS profile to discover clusters or instances and, for the RDS Data API path, may need permission to execute statements. It also uses Secrets Manager to retrieve database credentials in the documented configurations. Those are separate decisions from the grants of the database user.

 Use a purpose-built IAM role or profile for the process. Scope resource access where the AWS service supports it, and avoid attaching administrator policies simply because the assistant might need to inspect infrastructure. AWS's IAM guidance recommends least privilege, temporary credentials for workloads where possible, regular review of unused permissions, and the use of IAM Access Analyzer to help refine policies from observed activity.

 Remember that “read-only” at the AWS API layer is not identical to “safe output.” Some read operations can return configuration, identifiers, policy documents, or other sensitive material. The AWS API MCP Server documentation calls this out directly. A database assistant that can combine cloud discovery, secret retrieval, database queries, and local file operations has a much larger effective authority than the words “SQL read-only” suggest.

 Separate the functions when possible. A tool that answers questions about approved data does not necessarily need permission to create clusters, alter network controls, retrieve arbitrary secrets, or write files. If one workflow needs those capabilities, put them behind a separately approved tool and identity rather than adding them to the general-purpose reporting process.

 ## Audit for use of the vulnerable versions

 The advisories do not establish that the flaws were exploited in the wild. Public discussion around a CVE is not proof of an incident, and the presence of a vulnerable package is not proof that an attacker reached it. It is still sensible to review logs because the vulnerable path connects user-controlled content with a database execution surface.

 For PostgreSQL, review database logs and audit records for unusual use of server-side file or program features, unexpected role changes, creation of unfamiliar functions, changes to authentication configuration, and activity by the MCP service account outside its normal query pattern. Review host telemetry on the database server for processes, files, network connections, or persistence mechanisms that cannot be explained by the database workload. Keep the review at the level of defensive detection; do not turn an article or an incident ticket into a recipe for reproducing command execution.

 For MySQL, review statements that were supposed to be blocked but appear in audit logs, unexpected changes to production tables, use of administrative or file-related privileges, and connections made by the MCP account from unusual clients or times. Compare the observed statements with the natural-language requests that generated them where those records are available. A mismatch can reveal prompt injection, an overly broad tool contract, a parser problem, or ordinary model error.

 CloudTrail can help with the AWS side of the investigation, but it will not replace database and host telemetry. Look for unexpected Secrets Manager reads, RDS or cluster discovery outside the normal workflow, changes to IAM or security groups, and access from identities associated with the MCP process. Correlate timestamps across the MCP client, database, operating system, and cloud logs.

 If evidence suggests unauthorized access, follow the organization's incident-response process: isolate the affected process, rotate or revoke credentials as appropriate, preserve evidence, and assess database and host integrity. An upgrade alone is not a complete incident response if a privileged credential may have been used.

 ## What this changes for MCP deployment design

 The immediate fixes are package updates, but the broader lesson is about where an AI integration is allowed to sit in the architecture. An MCP server that translates natural language into SQL is not merely a convenience adapter. It is an interpreter placed between a person, a model, a tool protocol, and a stateful system. Each layer can transform or add meaning to the request.

 That calls for controls that remain understandable when the model behaves unexpectedly. A useful deployment separates read-only analytics from operational database access. It uses a database role created specifically for the integration, limits the role to approved objects, and keeps production writes in a workflow that requires a distinct identity and an explicit change process. It keeps the MCP server local or otherwise isolated when the product is designed for single-user STDIO operation. It constrains the host, network egress, secrets, and filesystem access around the process.

 It also makes versions and configuration observable. The team should be able to answer which MCP package ran, with which arguments, under which identity, against which database, and what tool call produced each query. If those answers are unavailable, a vulnerability disclosure will produce a long debate about what might be installed rather than a quick remediation decision.

 Testing should cover the actual security contract, not just a happy-path query. Verify that ordinary read requests work, that unauthorized writes fail at the database, that the process cannot use privileged server features, that errors fail closed, and that a malformed or unexpected input does not silently disable a policy. Test the behavior after dependency upgrades and after database engine upgrades. The target is not to prove that a filter recognizes every possible SQL spelling; the target is to prove that an untrusted request cannot exceed the identity's permitted outcome.

 ## The practical conclusion

 AWS's September 9 bulletins are a timely reminder that “read-only” is a design claim that must be enforced in more than one place. The PostgreSQL issue requires particular attention where an old package is connected over the wire to a self-managed server with a superuser or `pg_execute_server_program` role. The MySQL issue affects older versions of the package and shows how SQL syntax that looks harmless to a text filter can still matter.

 Upgrade both packages where they are present. Inventory the real launch versions and connection methods. Replace powerful database accounts with narrowly scoped roles. Review the IAM profile, secret access, host permissions, and network exposure around the MCP process. Then use database, host, and cloud logs to decide whether the affected installations were merely vulnerable or also misused.

 The durable advice is simple, even if the implementation takes work: let the database enforce the database boundary. Treat model instructions and SQL filters as helpful layers around that boundary, not as a substitute for it.