FastGPT Stored MCP Tool URL SSRF: The Admission-vs-Runtime Validation Gap (CVE-2026-44284)
FastGPT's MCP tool URL validation ran at request time but not at persistence time, creating a two-phase bypass. An authenticated user with tool-management permissions could store an internal network URL as a configured MCP server endpoint. The runtime workflow executor later loaded that stored URL and connected to the internal destination without re-checking. The check existed; it just ran in the wrong place.
What happened
FastGPT is an AI agent-building platform that lets users define MCP toolsets, including the URL of the MCP server the workflow runner will connect to. The platform already applied SSRF protection on its direct MCP preview and run endpoints, rejecting private and internal network addresses there.
The gap was in the create and update paths for MCP toolset configuration. Those endpoints accepted and persisted internal URLs without applying the same validation. An authenticated user could store a value like http://localhost:3000/mcp or an AWS metadata endpoint (http://169.254.169.254/latest/meta-data/) as the MCP server URL for a toolset.
When a workflow later executed, the runner loaded the stored MCP URL and constructed an MCPClient pointed at it without re-validating the destination address. The backend made a direct connection to the internal network, returning the response through the workflow output edges. Proof-of-concept steps are documented in the GitHub security advisory GHSA-cxxj-99f7-f5wq.
The fix in version 4.14.17 applied consistent URL validation at admission time, enforcing the isInternalAddress check before any MCP tool URL is persisted, and re-validating stored URLs at runtime before the MCP client is constructed.
The PolicyLayer angle
This vulnerability is a textbook confused-deputy pattern applied to MCP URL configuration. The workflow runner acted as a trusted deputy on behalf of the user, connecting to whatever MCP server URL was in the configuration database. The user had manipulated that database record without triggering the checks the platform applied elsewhere.
The policy-level control that independently blocks this class of attack: treat every MCP server URL as an untrusted network destination and enforce an allowlist of permitted MCP server hosts at the agent orchestration layer, not just at user-facing input validation. A workflow runner that consults a per-task allowlist of valid MCP endpoints before constructing a client cannot be steered toward internal network resources through stored configuration, regardless of what the admission-time checks missed.
The broader issue this exposes: validation that runs in one place but not another is not a consistent security boundary. Any platform where users can configure MCP tool endpoints needs to treat the configuration store as an adversarial input surface, not just the live request path.
Mitigations
Upgrade FastGPT to version 4.14.17 or later. If immediate upgrade is not possible, restrict MCP toolset creation and update permissions to trusted administrators only, and audit existing MCP toolset configurations for internal or private network URLs before re-enabling user access.
FAQs
No. Any authenticated FastGPT user with permission to create or manage MCP toolsets can exploit CVE-2026-44284. In many deployments that means any registered user. The exploitation steps require only network access and an account with tool-management rights.
Any host reachable from the FastGPT backend server, including cloud metadata endpoints (AWS IMDSv1 at 169.254.169.254), internal APIs, databases with HTTP interfaces, and other services on the internal network. The workflow response edges return the server's HTTP response to the attacker.