Microsoft Defender 发现 Mage AI 与 MCP 服务器未鉴权部署，可获 cluster-admin 权限执行 RCE

Back to incident tracker

2026-05-14

HighPrimary

Microsoft Defender: Mage AI and MCP servers deployed without auth in the wild, enabling RCE with cluster-admin access

Microsoft Defender for Cloud found Mage AI and MCP servers deployed without authentication in production, enabling RCE with cluster-admin access and credential theft across Kubernetes workloads.

Mage AI / MCP ServersTool execution / MCPUnauthenticated AI workload exposure leading to RCEKubernetes-hosted AI applications (Mage AI, MCP servers) deployed via official Helm charts without authentication

What happened

Internet-facing AI services executed shell commands and accessed internal tools without requiring any credentials.

Why it matters

Confirmed RCE with cluster-admin access; credential theft from co-located workloads; unauthenticated access to HR systems, private code repositories, and ticketing systems.

Missing authorization check

Authentication at the service endpoint and per-action authorization before tool or command execution—neither enforced by default in official deployment configs.

Would PP block it?

PP's enforcement primitive requires an authenticated caller to present a permission receipt before executing an agent action. If the MCP server or Mage AI workload exposes its API without any authentication, there is no caller identity to enforce against. PP would block unauthorized tool invocations from authenticated principals—it would not prevent an anonymous attacker from bypassing a missing auth layer entirely. PP is a prerequisite multiplier: effective only when the caller is authenticated.

Incident analysis

Timeline and technical read

Timeline

1. 2026-05-14

   Microsoft publishes Defender for Cloud analysis of exploitable misconfigurations in AI applications.

2. 2026-05-14

   Report confirms Mage AI was actively exploited via internet-facing shell with cluster-admin service account binding.

3. 2026-05-14

   15% of remote MCP servers found severely insecure with unauthenticated access to sensitive internal systems.

4. 2026-05-14

   Mage AI patches official Helm chart to enable authentication by default following responsible disclosure.

Technical breakdown

• Mage AI's official Helm chart deployed a LoadBalancer on port 6789 with no authentication, exposing a web UI with direct shell execution capability.
• Default Kubernetes service account was bound to cluster-admin roles—shell access equated to full cluster compromise.
• MCP protocol does not enforce authentication by spec; 15% of production deployments were accessible without credentials.
• Unauthenticated MCP access executed tool actions in the server's security context rather than the requesting user's context.
• Defender for Cloud signals show >50% of cloud-native AI workload exploitations stem from misconfigurations, not zero-days.

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 invocation layer (per-action authority check); not at the network authentication layer

Still needs

Network-layer authentication enforcement; Kubernetes ingress policy; MCP server authentication configuration

Receipt required for

Any tool invocation (shell commands, data access, cluster operations) must name the authorized principal, the specific tool, and the permitted scope

PP enforces authorization at the action level but cannot compensate for a missing authentication layer at the network edge.

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.

Replay this incident with a signer in the loop