GHSA-v2x6-wwfw-r2rq: Path Traversal and Parameter Injection in Agentgateway

Agentgateway serves as an intermediary layer—a "next-generation agentic proxy"—that facilitates communication between AI agents and services implementing the Model Context Protocol (MCP). A core function of this proxy is transforming abstract tool calls generated by an AI model into concrete HTTP requests defined by an OpenAPI specification. This conversion process requires inserting dynamic parameters provided by the agent (or an attacker controlling the agent's context) into URL paths, query strings, and HTTP headers.

The vulnerability lies in the implementation of this conversion logic. Instead of treating user input as untrusted data requiring strict encoding, the system performed naive string substitution and concatenation. This architectural oversight meant that special characters with semantic meaning in HTTP—such as forward slashes (/), question marks (?), and ampersands (&)—were preserved rather than encoded. Consequently, an attacker could break out of the intended data context and modify the control structure of the HTTP request itself.

The root cause is a classic injection flaw resulting from the unsafe construction of URIs and HTTP headers. The analysis of crates/agentgateway/src/mcp/upstream/openapi/mod.rs reveals three distinct vectors stemming from the same underlying negligence:

1. Path Parameter Injection via String Replacement The application used a simple string replacement method path.replace(&format!("{{{key}}}"), s_val) to inject parameters into URL templates. If a template defined a path as /api/v1/users/{id}, and the input for id was ../admin, the resulting string became /api/v1/users/../admin. Most web servers and proxies normalize this path to /api/v1/admin, granting the attacker access to a completely different endpoint than intended.

2. Query Parameter Injection Query parameters were appended to the URL string without percent-encoding. If the code simply concatenated key=value, an attacker providing a value of data&admin=true would transform the query string into key=data&admin=true. This effectively injects a new parameter (admin) that the upstream server might interpret to grant privileged access.

3. Header Injection (CRLF) The proxy allowed arbitrary header values to be passed through to the upstream request. Without validation or sanitization, this could facilitate HTTP Response Splitting or allow the injection of restricted headers like Host, X-Forwarded-For, or Authorization, enabling IP spoofing or session hijacking.

The patch introduces strict encoding and allows-listing to neutralize the injection vectors. Below is a conceptual comparison of the vulnerable logic versus the hardened implementation.

Vulnerable Implementation (Conceptual):

// DANGEROUS: Naive replacement allows path traversal
let mut url = openapi_path.clone();
for (key, value) in params {
    // If value is "../", it alters the directory structure
    url = url.replace(&format!("{{{key}}}"), value);
}
 
// DANGEROUS: No encoding allows query injection
if let Some(query) = query_params {
    url.push_str("?");
    url.push_str(&format!("{}={}", key, value)); 
}

Patched Implementation (Commit 9a52875):

use percent_encoding::{utf8_percent_encode, CONTROLS};
 
// FIXED: Use regex to safely identify parameters
// FIXED: Apply percent-encoding to neutralize special chars
let safe_value = utf8_percent_encode(value, PATH_SEGMENT_SAFE).to_string();
 
// The replacer now ensures that "../" becomes "%2E%2E%2F"
// which is treated as a literal string, not a directory traversal
let url = PathParamReplacer::new(&openapi_path).replace(params);
 
// FIXED: Header Allow-listing
// Only headers explicitly defined in the OpenAPI schema are forwarded.
// Sensitive headers (Host, Content-Length) are filtered out.

The fix fundamentally changes the trust model: inputs are now guilty until proven innocent (encoded/validated) rather than trusted by default.

Attackers can exploit this vulnerability if they can influence the parameters passed to the MCP tool call. This is common in agentic workflows where the agent processes untrusted user prompts.

Scenario 1: Path Traversal

• Target: An endpoint /api/files/{filename} intended to read user documents.
• Attack: The attacker supplies ../../etc/passwd as the filename.
• Result: The proxy generates GET /api/files/../../etc/passwd. The upstream server resolves this to GET /etc/passwd, returning sensitive system files.

Scenario 2: Privilege Escalation via Query Injection

• Target: An endpoint /api/update_profile?uid={user_id}.
• Attack: The attacker supplies 123&role=admin as the user_id.
• Result: The proxy generates GET /api/update_profile?uid=123&role=admin. If the backend trusts the role parameter, the user is silently promoted to an administrator.

Scenario 3: Header Manipulation

• Target: An API that relies on the X-User-ID header for authentication, which the proxy is supposed to set securely.
• Attack: The attacker injects a custom header via a tool parameter that maps to a header field.
• Result: The attacker masquerades as a different user ID, bypassing authentication checks on the upstream service.

Confidentiality (High): The most immediate risk is unauthorized access to sensitive data via path traversal. Attackers could read configuration files, credentials, or data belonging to other users on the upstream system.

Integrity (High): Query parameter injection allows attackers to manipulate the logic of the upstream application. This could lead to unauthorized state changes, such as modifying user permissions, triggering administrative actions, or corrupting data.

Availability (Low): While the vulnerability primarily targets data access and logic manipulation, malformed requests caused by injection could potentially trigger unhandled exceptions in the upstream service, leading to minor availability issues, though this is not the primary impact vector.

Risk Rating: Based on the ability to bypass access controls and modify request logic remotely, this vulnerability is rated High. It effectively breaks the isolation between the AI agent and the protected backend API.