What happened
Attacker accesses internet-facing Mage AI UI, executes arbitrary shell commands, and dumps privileged service account tokens with cluster-admin capabilities.
2026-05-14
CriticalVendor postMage AI default Kubernetes deployment exposed unauthenticated RCE with cluster-admin privileges
Microsoft Defender for Cloud found Mage AI's default Helm chart deployment exposed an internet-facing UI with no auth — enabling unauthenticated RCE and cluster-admin access. Actively exploited in the wild.
Mage AI / KubernetesTool execution / MCPUnauthenticated remote code execution via default deploymentKubernetes cluster / AI pipeline workloads / service account tokens
Why it matters
Full Kubernetes cluster compromise: arbitrary code execution, credential exfiltration from other workloads, lateral movement across cloud infrastructure. Confirmed actively exploited prior to patch.
Missing authorization check
Authentication gate on the web UI and shell execution endpoint; least-privilege service account binding instead of cluster-admin default.
Would PP block it?
PP's enforcement primitive sits between the agent and its tool calls. If deployed, a PP-gated shell execution tool would require an explicit signed receipt before executing commands. However, PP does not govern Helm chart deployment defaults or Kubernetes ingress auth — those are infrastructure concerns. PP blocks the RCE-as-agent-action path but not a direct unauthenticated UI attack vector.
Incident analysis
Timeline and technical read
Timeline
2026-01-01
Mage AI Helm chart deployed with default insecure configuration in production environments across the ecosystem.
2026-04-01
Microsoft Defender for Cloud signals begin detecting publicly exposed Mage AI instances without authentication.
2026-05-01
Active exploitation observed in the wild — attackers dumping service account tokens with cluster-admin capabilities.
2026-05-14
Microsoft publishes Defender for Cloud research blog documenting exploitation and responsible disclosure to Mage AI.
2026-05-14
Mage AI patches default Helm chart to enable authentication by default following responsible disclosure.
Technical breakdown
- Default Helm chart exposed a LoadBalancer on port 6789 with no authentication — an internet-reachable shell execution endpoint out of the box.
- Web UI shell feature ran in the application's Kubernetes service account context, not the user's context, collapsing the privilege boundary.
- Default service account binding granted effective cluster-admin — full Kubernetes API access from a single unauthenticated HTTP request.
- 15% of remote MCP servers observed by Defender for Cloud similarly allow unauthenticated access to sensitive internal tools (HR, ticketing, code repositories).
- Exploitable misconfigurations now account for >50% of cloud-native workload compromises detected by Microsoft Defender for Cloud.
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
- Agent-to-tool dispatch layer (Tool-Call Gate)
- Still needs
- Infrastructure deployment defaults, Kubernetes ingress authentication, service account privilege scoping at deploy time.
- Receipt required for
- Shell command execution, service account token access, Kubernetes API calls initiated by the agent.
PP enforces authorization at tool dispatch but cannot fix missing authentication at the infrastructure deployment layer.
Related incidents and controls
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.