CVE-2026-14748: Awesome-MCP-Server SSRF Vulnerability

CVE-2026-14748 Overview

CVE-2026-14748 is a Server-Side Request Forgery (SSRF) vulnerability in the AIAnytime Awesome-MCP-Server project, affecting the mcp-wiki/wiki-summary component. The flaw resides in mcp-wiki/src/mcp_wiki/server.py, where the url argument is processed without adequate validation. An authenticated remote attacker can manipulate the URL parameter to force the server to issue arbitrary outbound HTTP requests. The project follows a rolling release model, so specific fixed versions are not published. The affected commit range extends up to a884bb51bcd99e08e14fd712c749d55d9d9a13ab. A public exploit exists, and the maintainers had not responded to the disclosure at the time of publication.

Critical Impact
Attackers can abuse the wiki-summary tool to reach internal network services, cloud metadata endpoints, or arbitrary external hosts through the vulnerable MCP server.

Affected Products

AIAnytime Awesome-MCP-Server (rolling release, up to commit a884bb51bcd99e08e14fd712c749d55d9d9a13ab)
mcp-wiki module within the Awesome-MCP-Server repository
The mcp-wiki/wiki-summary server-side component defined in mcp-wiki/src/mcp_wiki/server.py

Discovery Timeline

2026-07-05 - CVE-2026-14748 published to the National Vulnerability Database (NVD)
2026-07-06 - Last updated in NVD database

Technical Details for CVE-2026-14748

Vulnerability Analysis

The vulnerability is classified as Server-Side Request Forgery [CWE-918]. The Model Context Protocol (MCP) server exposes a wiki-summary tool implemented in mcp-wiki/src/mcp_wiki/server.py. This tool accepts a caller-supplied url argument and issues an outbound HTTP request to that address. Because the input is not restricted to trusted domains or resolved against an allowlist, an attacker can substitute arbitrary URLs. The server then acts as a proxy, contacting endpoints reachable from its own network position. The attack is remotely initiated over the network and requires only low-privilege access to the MCP interface. Attackers can enumerate internal services, retrieve cloud instance metadata such as AWS IMDS, or interact with services bound to localhost.

Root Cause

The root cause is missing validation of the url parameter passed into the wiki-summary handler. The code trusts the client-supplied URL and passes it directly to an HTTP client. There is no scheme restriction, no hostname allowlist limiting requests to Wikipedia domains, and no filter blocking private IP ranges, link-local addresses, or loopback destinations.

Attack Vector

An attacker with access to the MCP tool invokes wiki-summary with a crafted url value. The server issues the request from its own context and returns the response body to the caller. This enables reconnaissance of internal HTTP services, exfiltration of metadata credentials, and pivoting into private networks. See the GitHub issue report #34 and GitHub issue report #35 for the disclosed exploitation details.

No verified proof-of-concept code is reproduced here. Consult the VulDB entry for CVE-2026-14748 for the published exploit description.

Detection Methods for CVE-2026-14748

Indicators of Compromise

Outbound HTTP requests from the MCP server host to destinations outside the Wikipedia domain set (*.wikipedia.org, *.wikimedia.org).
Requests originating from the MCP process to RFC1918 addresses, 127.0.0.1, 169.254.169.254, or cloud metadata endpoints.
MCP audit logs showing wiki-summary invocations with url values referencing non-wiki hosts, internal DNS names, or IP literals.
Unusual DNS resolutions performed by the MCP server for attacker-controlled domains used to confirm SSRF callbacks.

Detection Strategies

Instrument the MCP server to log every url argument passed to wiki-summary alongside the resolved destination IP and HTTP status.
Deploy egress network monitoring that flags any traffic from MCP server hosts leaving the expected Wikipedia CIDR ranges.
Correlate authentication logs with wiki-summary invocations to identify low-privilege accounts probing internal ranges.
Alert on any successful HTTP 200 responses from the MCP host to metadata service IPs.

Monitoring Recommendations

Forward MCP application logs and host process telemetry into a centralized data lake for retention and correlation.
Baseline normal wiki-summary traffic patterns and generate alerts on volume spikes or novel destination hosts.
Monitor for the specific commit a884bb51bcd99e08e14fd712c749d55d9d9a13ab or earlier in deployed inventories using software composition analysis.

How to Mitigate CVE-2026-14748

Immediate Actions Required

Restrict network egress from hosts running Awesome-MCP-Server to only Wikipedia and Wikimedia domains through a firewall or forward proxy.
Disable or remove the wiki-summary tool from the MCP server configuration until an upstream fix is available.
Block the MCP host from reaching cloud instance metadata endpoints such as 169.254.169.254 and private network ranges not required for operation.
Rotate any credentials that were reachable from the MCP host, including cloud instance role tokens.

Patch Information

At the time of publication, the maintainers of AIAnytime Awesome-MCP-Server had not responded to the disclosure and no official patch had been released. The project uses a rolling release model, so fixed version identifiers are not published. Monitor the Awesome-MCP-Server repository and the referenced issue #34 and issue #35 for remediation commits.

Workarounds

Apply a local patch to mcp-wiki/src/mcp_wiki/server.py that validates the url argument against an allowlist of Wikipedia hostnames before making outbound requests.
Reject any URL whose resolved IP address falls within private, loopback, link-local, or cloud metadata ranges.
Enforce a scheme allowlist limited to https and reject redirects to disallowed destinations.
Run the MCP server in a network namespace or container with an egress policy that permits only required Wikimedia endpoints.

bash

# Example egress restriction using iptables on the MCP host
# Drop traffic to cloud metadata and private ranges from the MCP process user
iptables -A OUTPUT -m owner --uid-owner mcp -d 169.254.169.254 -j DROP
iptables -A OUTPUT -m owner --uid-owner mcp -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -m owner --uid-owner mcp -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -m owner --uid-owner mcp -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -m owner --uid-owner mcp -d 127.0.0.0/8 -j DROP