Security
AWS Patches MCP Flaws That Could Alter PostgreSQL Data and Inject Code
AWS has patched vulnerabilities in open-source PostgreSQL and DynamoDB MCP servers, showing why agent tools need database-enforced permissions and careful review of generated infrastructure code.
By Leo W ·
Amazon Web Services has patched two important vulnerabilities in open-source Model Context Protocol servers that connect AI assistants to PostgreSQL and DynamoDB. One flaw could allow crafted SQL to move beyond an intended read-only boundary. The other could place executable code into infrastructure generated from a malicious data-model file. Neither bulletin describes a breach of an AWS-managed cloud service, but both expose a basic weakness in agent architecture: a friendly tool description is not a security boundary.
The PostgreSQL issue, CVE-2026-85787, affects versions of the awslabs postgres-mcp-server before 1.1.7. AWS says an incomplete list of disallowed SQL inputs could let an unauthenticated actor craft content that modifies data when an authenticated user interacts with the server. The distinction is subtle. The attacker does not need the database credential; the agent session supplies the trusted path.
A Read-Only Promise Meets Database Reality
Blocklists are brittle because SQL is a language with aliases, comments, functions and many ways to express side effects. Filtering known dangerous strings can stop obvious cases but tends to fail when a new syntax reaches the parser. AWS fixed the validation issue, yet its most important recommendation is architectural: run the MCP server under a dedicated PostgreSQL role with only the permissions it needs.
That advice turns ‘read only’ from an application claim into a database-enforced rule. A role limited to CONNECT, USAGE and SELECT cannot update a table even if malicious SQL passes the model, client and MCP validation layer. AWS also recommends forcing read-only transactions and warns against superuser, rds_superuser and cluster-master credentials. Those accounts can bypass controls far beyond the data an assistant needs.
Teams should assume instructions can be hostile even when they arrive inside ordinary documents. An agent might summarize a ticket, inspect a schema or answer a user question while hidden text attempts to redirect its tool calls. Prompt injection becomes materially more dangerous when the model holds a credential with write access. Least privilege contains the effect without depending on the model to recognize every attack.
Patching remains necessary because defense in depth is not a reason to leave a known bypass open. Organizations using the PyPI package should move to version 1.1.7 or later and make sure internal forks include the fix. They should also review database logs for unexpected write attempts and confirm that credentials used by development assistants are separate from production administration.
Generated Infrastructure Is Executable Input
The DynamoDB flaw, CVE-2026-85654, affects versions 2.0.10 through 2.1.5 of awslabs.dynamodb-mcp-server. AWS says specially crafted table, index or attribute names in a data-model file could be interpreted by the template engine and execute arbitrary code on the host that deploys the generated application. Version 2.1.6 addresses the problem.
This attack path crosses several trust transitions. A data file appears declarative, the MCP server turns it into CDK code, and a developer or pipeline executes the generated project with local or cloud credentials. Each step can make the artifact feel more legitimate. By deployment time, reviewers may treat it as machine-produced boilerplate and focus on the visible infrastructure rather than the source strings embedded in templates.
AWS advises users who cannot upgrade immediately to inspect dynamodb_data_model.json for unexpected names and avoid models from untrusted sources. Manual review is a temporary control, not a scalable answer. Build systems should isolate code generation, scan the resulting source, require changes to be visible in version control and run deployment with narrowly scoped credentials.
The vulnerabilities are a reminder that agent supply chains include prompts, retrieved documents, tool servers, templates, generated code, packages and deployment identities. Traditional software security already struggles with that chain. Agents make it more dynamic because a probabilistic system decides which components to invoke and how to combine their outputs.
What Security Teams Should Do Now
Incident responders should preserve the content that preceded suspicious calls. Traditional logs may show a query or process launch without the retrieved document and model decision that caused it. Capturing that context helps distinguish exploitation from an ordinary developer mistake. Retention must be balanced against privacy because prompts and tool results can themselves contain credentials, customer data and source code.
Developers also need a safe way to experiment. If approved MCP servers are difficult to obtain, teams will run unofficial copies on laptops with broad credentials. A useful security program offers maintained templates, minimal roles and local test environments that make the safer path easier. Governance that consists only of prohibition tends to move risk out of sight.
The immediate work is straightforward: inventory MCP servers, identify package versions, upgrade affected components and inspect forks. The harder work is discovering unofficial servers launched by individual developers. Organizations need a registry that records owners, versions, credentials, reachable systems and approved clients. Network logs can help locate servers that were never entered into the catalog.
Credentials should be short-lived and bound to the task. A coding assistant troubleshooting a Lambda function does not need permanent access to every database. AWS’s own MCP security guidance places identity and permission design at the center of deployment. OAuth and cloud identity can improve the user experience, but authentication answers who connected, not what every tool should be allowed to do. Authorization still belongs at the resource layer.
Security testing should include adversarial content inside files and records that agents are expected to trust. OWASP’s guidance for large-language-model applications identifies prompt injection and insecure output handling as recurring risks. MCP deployments should test both together, because an injected instruction becomes more damaging when downstream systems execute model output without validation.
MCP is valuable precisely because it makes tools easier to connect. That convenience can also hide the distance between a conversation and a consequential system call. AWS’s patches close two specific flaws. The durable lesson is broader: agents should operate inside permissions that remain safe even when the model, prompt, parser or template is wrong. Anything less turns every input-validation bug into a potential breach of trust.
Topics: AWS, MCP security, PostgreSQL, DynamoDB, vulnerabilities