Trend Micro 披露 mcp/postgres 镜像 RTT 攻击：AI 智能体经授权工具外泄生产令牌

Back to incident tracker

2026-05-26

HighVendor post

Trend Micro: Poisoned mcp/postgres Docker Image Pulled 100K+ Times: Return-to-Tool Attack Causes AI Agent to Exfiltrate Production Tokens via Approved Tools

Trend Micro: a vulnerable mcp/postgres Docker image with 100K+ pulls enables Return-to-Tool attacks where AI agents post production database tokens to public threads.

mcp/postgres Docker imageTool execution / MCPAI agent supply chain compromise / return-to-tool (RTT) prompt injection exploitDocker Hub mcp/postgres image / MCP server / AI agent toolchain / production PostgreSQL databases

What happened

RTT exploit via crafted prompt in support ticket caused database-connected AI agent to read authentication tokens from production PostgreSQL tables and post them to a public customer comment thread, using only the agent's scoped authorized tools — no alerts fired, no policy violated.

Why it matters

Authentication tokens from production database exfiltrated to a public customer comment thread. The attack was conducted entirely within the agent's authorized tool scope and RBAC permissions, rendering conventional monitoring and access controls ineffective. Attack is reproducible against any deployment of the unpatched mcp/postgres image connected to a database-reading AI agent.

Missing authorization check

A PP-style Tool-Call Gate requiring the agent to present a signed authorization receipt before reading from production credential tables or posting content to external channels — gating on the action and purpose, not just the authenticated identity.

Would PP block it?

RTT attacks succeed because the agent's authorized tools become the attack chain — each step is 'legitimate' from an access-control perspective. PP's Tool-Call Gate enforces that specific tool invocations (particularly those touching sensitive tables or posting to external surfaces) require signed receipts naming the authorized purpose. In this attack, the exfiltration step — the agent posting authentication tokens to a public thread — would require a receipt authorizing 'posting external content' in the current session context. The attacker's injected prompt cannot produce a PP-signed receipt from the victim's PP deployment, severing the final exfiltration step.

Incident analysis

Timeline and technical read

Timeline

1. 2025-01

   SQL read-only bypass in mcp/postgres Docker image publicly disclosed

2. 2026-01

   TrendAI Research reports flaw to Docker; image continues shipping unpatched code

3. 2026-05-26

   Trend Micro publishes 'Pwning Agentic AI Part I' documenting RTT exploit class and vulnerable image (100K+ pulls confirmed)

4. 2026-05-26

   RTT scenario published: crafted support ticket causes AI agent to exfiltrate production authentication tokens to public comment thread via authorized tools

Technical breakdown

• Return-to-tool (RTT) is a subclass of indirect prompt injection where the injected instruction causes the agent to call its authorized tools against its principal — analogous to return-oriented programming (ROP) where approved 'gadgets' are chained by an attacker payload.
• The mcp/postgres Docker image shipped an unpatched SQL read-only bypass for over a year after disclosure; 100,000+ pulls mean this attack surface is embedded in a significant fraction of production AI agent deployments.
• The attack evades perimeter controls (WAF, reverse proxy) because the payload is benign-looking text — no shell metacharacters, no exploit strings. Detection requires behavioral analysis of agent tool call sequences, not signature matching.
• RBAC and container isolation are both ineffective: RBAC controls which tables the agent can access, not which rows or what it can do with them; container isolation is irrelevant because the attack occurs inside the trust boundary between the agent and its own tools.
• Audit logs show the agent performing routine operations; without receipts gating specific tool invocations, defenders cannot distinguish legitimate agent behavior from RTT exploitation in standard monitoring output.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at

Tool-Call Gate: agent reads from production authentication or credential tables, and any tool invocations that post content to external channels, require PP-signed receipts.

Still needs

The vulnerable mcp/postgres Docker image and its SQL read-only bypass — PP does not address software supply chain vulnerabilities in MCP server images. Initial delivery of the injected prompt via support ticket or document.

Receipt required for

Agent reading from production authentication or credential tables; agent posting content to any external channel or public-facing surface; any MCP tool invocation touching sensitive data classes.

PP's Tool-Call Gate gates on authorized agent actions, requiring signed receipts for sensitive tool invocations. The RTT exploit weaponizes the agent's existing tool authorizations — PP would require a receipt before the final exfiltration step (posting to external channel), breaking the attack chain at that boundary. The vulnerable Docker image and SQL bypass are outside PP scope.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.