The Caller Chose the MCP Server. OGX Treated That Choice as Network Authority.

Read OGX's own affected source and the fact that matters is not that a validation function is missing from the codebase. It is present, it is written correctly by the standard this record could verify, and it is already wired into two other places a caller supplied URL reaches an outbound request. The MCP tool path is the one place it was never connected.

What the primary issue and the source together establish

GitHub issue 6287, filed against ogx-ai/ogx by a reporter identified as geo-chen, states its own title plainly: unauthenticated server side request forgery via MCP tool server_url in POST /v1/responses. The issue was opened 13 July 2026, against a private report the reporter states was made 9 June 2026, a chronology this record carries as reported rather than independently timestamped, since only the public issue's own creation date is directly verifiable. The issue names the affected commit, fbe8e0fb0fe99640327bf49b8156b65cd7fc8c19, and this record read the source at that exact commit rather than relying on the issue's own prose description of it. OGX's OpenAI compatible Responses API accepts a request carrying an MCP tool object with server_url, headers and authorization fields, all caller supplied. Inside _process_mcp_tool, the only check applied to server_url before it is used is a null check, raising a ValueError only when the field is missing entirely. The value then passes to list_mcp_tools, called with the caller's own server_url, headers and authorization, which in turn calls into mcp.py to open a Model Context Protocol session against that endpoint.

The MCP session mechanism, and why initialization is not a lesser moment than invocation

mcp.py builds the transport for that session from a strategy selection: streamablehttp_client(endpoint, headers=headers) for the default Streamable HTTP strategy, or sse_client(endpoint, headers=headers) when the caller's tool definition selects SSE. Either client is opened directly against the caller supplied endpoint, and the resulting streams are handed to a ClientSession whose initialize method is awaited immediately after. That initialize call is not a formality ahead of the part that matters. It is the point at which OGX's own server process, from wherever it is deployed, opens a real outbound network connection to an address the caller chose, and it happens before any tool the MCP server might expose is ever listed, let alone called. A resource authority question that only gets asked at tools/call would already be too late here: the network effect this record is about occurs at session initialization, during what the Responses API surfaces to the caller as tool discovery.

The header and authorization asymmetry, read precisely

mcp.py's prepare_mcp_headers function does contain a real, working restriction: if a caller supplied headers dictionary carries a key that case insensitively matches authorization, the function raises a ValueError, stating that Authorization must be passed through the dedicated authorization parameter instead. That restriction is genuine and this record does not describe it as absent. What the same function does next is forward exactly the material that restriction was meant to gate through a different door: when a caller supplies a value through the dedicated authorization parameter, prepare_mcp_headers sets headers["Authorization"] to a Bearer token built from it, and that header reaches whatever endpoint server_url named. The caller cannot smuggle an Authorization value through the generic headers dict, but a caller who uses the field the API provides for exactly this purpose has their own credential material forwarded to a destination nothing has independently authorized. This record states that distinction because the accurate claim is narrower and more precise than either the API accepts arbitrary Authorization headers or the API never forwards credentials to a caller chosen destination.

A validation helper that already exists, and already governs two sibling paths

The codebase's own validate_url_not_private function, read directly in src/ogx/providers/utils/common/url_validation.py, takes a URL, resolves its hostname either as a literal IP address or through DNS lookup, and raises a ValueError if any resolved address is not globally routable. That check covers loopback addresses, link local ranges including 169.254.169.254, and private RFC 1918 space; it does not itself constrain which URL scheme is accepted. This record confirmed, by reading the calling source directly rather than by inference from the helper's own existence, that this exact function already gates two other caller controlled URL inputs in this codebase. prompt_adapter.py's localize_image_content calls validate_url_not_private on a caller supplied image URI before fetching its content. file_search.py's raw_data_from_doc calls the same function on a caller supplied RAG document URI before fetching it. Neither call appears anywhere in _process_mcp_tool's path to list_mcp_tools.

What the reproduction shows, and what it does not

The primary issue's own proof of concept deploys a listener on a loopback address, distinct from any production internal service, and shows that a POST /v1/responses request naming that address as an MCP tool's server_url causes OGX's own server process to connect to it, evidenced by the listener receiving the connection. This record treats that as sufficient, independently verifiable evidence of the mechanism: a caller can direct the server's own network position at an address the caller chose, and the server acts on that direction without an independent check. It does not establish, and this record does not claim, that any specific internal service or cloud metadata endpoint was reached in this reproduction, that any credential was exfiltrated, or that the vulnerability has been exploited against a production OGX deployment. Cloud metadata reachability is a class of impact the mechanism plausibly extends to under a deployment where such an endpoint sits within the server's own network reach, not a demonstrated outcome this record can independently confirm.

Authentication scope: the tested starter configuration, not every deployment

The primary issue states that under the tested configuration, a default starter setup carrying no auth: block, GET /v1/health returns 200 with no Authorization header, which this record reads as establishing that the specific starter configuration tested was reachable without authentication, not as a general claim that every OGX deployment runs unauthenticated. OGX's own configuration surface supports an auth: block an operator can add, and this record found nothing in the primary issue or the advisory stating what fraction of real deployments run with or without one. The severity a caller supplied server_url with no destination check carries is worse under an unauthenticated deployment, since no credential is required to reach the vulnerable path at all, but the underlying mechanism, an accepted MCP tool definition's server_url reaching list_mcp_tools unchecked, does not itself depend on the endpoint being unauthenticated; it depends on the destination never being checked once a request, however it was authenticated, reaches _process_mcp_tool.

Two proposed fixes, converging on the same call and diverging on scope

Pull request 6390, titled by its own author fix(inference): validate MCP tool server_url to block SSRF to private addresses, adds a single call, validate_url_not_private(mcp_tool.server_url), to _process_mcp_tool immediately after the existing null check and before list_mcp_tools is reached, referencing issue 6287 directly in its own comment. It adds a new test file exercising three cases: a link local address, 169.254.169.254, rejected before list_mcp_tools is ever called; a loopback address, 127.0.0.1, rejected the same way; and a public address, 8.8.8.8, permitted through to list_mcp_tools as before. As of this record, the pull request carries one community review, is not yet approved by a maintainer with commit authority on the affected path, and has not merged. This record does not treat it as a shipped mitigation, and does not attribute CVE-2026-85666 a resolved status on the strength of an open pull request. The pull request's own description, read directly, does not add redirect revalidation or bind the eventual outbound connection to the specific address validate_url_not_private already resolved; a check that runs once ahead of a separate connection step is a real improvement over no check at all, but this record does not claim it closes a DNS rebinding or time of check to time of use gap between validation and connection, a distinct and separately evidenced mechanism this record keeps apart from what this pull request, as currently written, actually does.

A second pull request, 6291, titled fix(security): block SSRF via caller-supplied MCP server_url in Responses, opened independently of 6390 and remains a draft as of this record. It proposes the same underlying correction, a private address check applied to a caller supplied server_url reached through the Responses API, and additionally restricts the accepted scheme to http and https. What 6291 states that 6390's own description does not is an explicit boundary between two kinds of MCP endpoint: a caller supplied server_url submitted directly in a POST /v1/responses request, which the pull request's own description says is now validated against private address ranges, and an administrator configured connector or toolgroup endpoint, resolved through a path this record did not find sharing code with _process_mcp_tool, which the same description states explicitly remains permitted to reach a private address, quoting the pull request's own words directly: admin configured connector and toolgroup private MCP endpoints remain allowed, and connector resolved Responses URLs are trusted. This record reads that distinction as the same one this desk's own authority framework already draws for other intermediaries, that an endpoint an operator configured in advance and a destination a caller names in the request carry different provenance, and that a correction closing the caller supplied path does not need to, and should not, close the administrator's own configured one along with it. The pull request awaits review from six named code owners and, as a draft, has not been submitted for merge.

The Authority Provenance ledger

Authority grantor. The operator who deploys OGX and decides whether to configure an auth: block gating POST /v1/responses. Nothing in the primary issue or the advisory names an organizational principal, distinct from that operator, who separately decided a caller reaching this endpoint should be able to direct the server's own outbound connections anywhere the caller names.

Caller identity. Under the tested starter configuration, unauthenticated: the primary issue's own reproduction reaches POST /v1/responses with no Authorization header. Under a deployment carrying an auth: block, an authenticated caller of whatever scope that configuration grants; this record does not establish that OGX's authentication layer, where configured, independently constrains which MCP server_url values an otherwise authenticated caller may name.

Caller mandate. Whatever mandate, if any, admits a caller to invoke the Responses API at all. Nothing in the primary issue or the affected source describes that mandate as extending to, or as ever having been evaluated against, the destination of the server's own outbound MCP session.

Intermediary. OGX's own server process, specifically the Responses API's _process_mcp_tool method and the MCP client session mcp.py constructs from the caller supplied server_url.

Intermediary credential. None of OGX's own is described as forwarded in the material this record could verify. What is forwarded is the caller's own credential, supplied through the dedicated authorization parameter, as an Authorization Bearer header sent to whatever destination the same caller named.

Intermediary network authority. Whatever loopback, link local, private network and, where reachable from the deployment, cloud metadata destinations the OGX server process could reach from wherever the operator deployed it, evidenced directly by the primary issue's own loopback reproduction.

Downstream target. Before the vulnerability, presumably any MCP server the deployment intended callers to reach. As demonstrated, any address the OGX process itself could reach, evidenced concretely for loopback and, by the mechanism validate_url_not_private is designed to block, extending to link local and private network destinations reachable from the same deployment.

Failed limit. No destination check on server_url in _process_mcp_tool, confirmed directly against the affected source, despite validate_url_not_private already existing and already gating two sibling caller controlled URL inputs in the same codebase.

Inherited assumption. That a caller admitted to name an MCP tool's server_url was thereby entitled to direct the server's own network connection to that address, the same substitution of reachability for authorization this desk has already read in Grafana's own advisory for CVE-2026-19516, evidenced here at the point of MCP session initialization rather than at a later tool call.

Credential binding. Partially present. prepare_mcp_headers blocks an Authorization value smuggled through the generic headers dict, but forwards a value supplied through the dedicated authorization parameter to the caller named destination without checking that destination first.

Destination binding. Absent on this path at the time of this record's review. validate_url_not_private exists and is correctly applied on two sibling caller controlled URL paths in the same codebase; it is not applied here.

Challenge authority. Under the tested starter configuration, none: POST /v1/responses accepts the request with no Authorization header. Under a configuration carrying an auth: block, whatever that configuration checks, which nothing in the material this record could verify describes as reaching the destination of the resulting MCP session.

Revocation or modification. Not applicable; no fix has shipped in a released version as of this record.

Recovery path. Two open, unmerged pull requests propose the specific corrective. Pull request 6390 calls validate_url_not_private on mcp_tool.server_url before list_mcp_tools opens a connection; it is community reviewed but not maintainer approved. Pull request 6291, an independently opened draft, proposes the same check plus a scheme restriction, and states explicitly that an administrator configured connector or toolgroup endpoint remains outside it, trusted on a separate resolution path. Neither has been reviewed by a maintainer with commit authority on the affected path.

Exploitation. Unknown. No source available to this record states the vulnerability has been exploited against a production OGX deployment. The primary issue's own reproduction is a controlled demonstration against a listener the reporter deployed, not evidence of exploitation in the wild.

Provenance evidence quality. Strong for the mechanism itself: this record read the affected source directly at the commit the primary issue names, confirming the absent destination check, the MCP session construction, the header and authorization handling, and the two sibling paths that already call validate_url_not_private. Strong for the CVE's own metadata, read directly from GitHub's Security Advisory record. Weaker for the underlying CVE Program record itself: cve.org was blocked to direct fetch in this session on every attempt, and this record relies on the GitHub Advisory Database's mirrored record rather than a direct read of the Program's own page.

Where this sits in the pattern

Grafana's own advisory for CVE-2026-19516 already documents a Grafana MCP server whose caller supplied X-Grafana-URL header directed the server's own outbound request at internal, loopback and link local destinations, unconstrained until a later fix added exactly the destination check this record finds missing here. This record reads OGX's own mechanism as the same weakness occurring earlier in an MCP client's own lifecycle, at session initialization inside tool discovery rather than at a dedicated proxying tool call, which is why this record treats MCP initialization itself, not only a later tools/call, as the point where a destination authority question was owed and was not asked. LiteLLM's own patched authentication bypass showed a different boundary at the same kind of intermediary, an identity check whose failure was converted into an accepted result rather than a destination left unchecked once a caller was admitted; this record keeps the two apart, since OGX's caller in the tested starter configuration was never required to present a credential in the first place, and the gap here sits entirely at the destination the request was allowed to reach. This desk's broader argument that a reachable resource functions as an authorized one wherever nothing independently checks reachability against authorization holds here in close to its cleanest form yet: the check existed in the same codebase, worked correctly on two other paths, and the MCP tool path was simply never connected to it. The wider thesis that execution authority has to be evaluated at the moment of the consequential action, not assumed from an earlier admission, extends here to a moment this record's own reading of the source shows arrives earlier than a tool call: OGX's own MCP session initialize, run during what the API frames as tool discovery, is already the consequential network action.

What this record does not establish

This record does not claim CVE-2026-85666 has been exploited against a real OGX deployment, that any cloud metadata service was actually reached in the primary issue's own reproduction, that every OGX deployment runs without an auth: block, that pull request 6390 or pull request 6291 has merged or shipped in a released version, or that either proposed fix addresses redirect revalidation or DNS rebinding between validation and connection. It does not claim a third remediation has been merged instead of these two, or that 6291's own separate treatment of administrator configured connector and toolgroup endpoints has been independently verified against that resolution path's own source; this record read that treatment from the pull request's own description rather than from the connector resolution code itself. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the pattern this weakness class already shows elsewhere.