High 2026-07-28

MCP Server Security Policy Fail-Open on Initialization Failure (CVE-2026-16584)

When a security-policy component in an AI agent server fails to load at startup, it should refuse to start. Instead, in this flaw, it logs a warning and keeps serving requests with the safety checks silently disabled for as long as it runs. Any request that arrives after that point is not checked at all.

How the attack works

An MCP server (such as awslabs.aws-api-mcp-server before 1.3.47) fetches a policy or index file over the network at startup to know what operations require approval. If that fetch fails for any reason — network blip, permission error — the server logs the failure but continues running anyway. From that point on, the per-request consent and read-only enforcement checks never run again, so the server treats every request as pre-approved. An attacker who can inject instructions into the agent's context, or otherwise get it to issue commands, can then push mutating operations (in this case, AWS CLI commands) through without any approval ever being recorded. Nobody disabled the gate on purpose — it just died silently and nobody noticed.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID: fdf7ab09-0091-42c9-975a-8ad18a998137
Severity: High
CVEs: CVE-2026-16584

Classification

AML.T0051.001 · Indirect AML.T0053 · AI Agent Tool Invocation ASI02 · Tool Misuse and Exploitation ASI04 · Memory and Context Poisoning LLM06 · Excessive Agency LLM08 · Vector and Embedding Weaknesses

Why it matters

An agent or MCP server can execute high-impact, state-changing actions (like AWS API calls) with no consent check and no audit trail, for the entire lifetime of the process, until it is restarted.

What you can do

→Configure agent runtimes and MCP servers to fail closed: if a policy, guardrail, or consent component fails to initialize, the process should refuse to start or refuse to serve requests, not just log and continue.
→Monitor startup logs for warnings about failed policy/index/guardrail loading, and treat any such warning as a signal to stop and investigate rather than a benign notice.
→Alert on any server instance that logs a degraded-start warning and subsequently executes mutating or high-privilege operations, since this indicates the enforcement gate is not running.
→Upgrade affected components to the patched version (e.g. awslabs.aws-api-mcp-server 1.3.47 or later) and restart affected processes; a historical log line does not mean the running instance is still exposed.

Known benign look-alikes

Security advisories, changelogs, incident write-ups or postmortems that quote the pre-fix log line verbatim including a trailing exception name. Layer 1 cannot tell a quoted log from an emitted one; scan_target is runtime specifically so static skill/doc scans do not load this rule.
Chaos-engineering or fault-injection suites that deliberately break the policy loader to prove the fail-closed path works. These produce genuine loader-failure lines by design.
Log aggregation pipelines that replay historical logs from a deployment that was already patched and restarted; the old degraded-start line is real but no longer actionable.
Non-security components that legitimately fail open by design and happen to sit within the layer 4 proximity window, for example an authorization-decision CACHE whose miss behaviour is 'continue to the origin policy engine' rather than 'allow the request'.
Vendor SDKs whose log wording places a policy noun after the load verb in a fail-CLOSED message that also contains an unrelated 'skipping' or 'ignoring' token within the layer 3 window.