If your organization runs AI-powered automation tools connected to internal systems, a newly disclosed vulnerability means an attacker on the internet could use your own server as a spy inside your private network — without ever logging in.
Who Is at Risk — and Why It Matters Right Now
The affected software, GlutamateMCPServers by ShadowCloneLabs, is a Model Context Protocol (MCP) server framework — the kind of infrastructure quietly humming in the background of AI-integrated developer environments, enterprise automation pipelines, and cloud-native applications. MCP servers act as translators between AI models and real-world tools, letting systems browse the web, execute tasks, and interact with internal services. In short: they are highly trusted, deeply connected, and increasingly common.
Because GlutamateMCPServers uses a rolling release model — meaning there are no traditional version numbers, just continuous code commits — the exact count of exposed deployments is difficult to pin down. But security teams managing any installation built on commits up to e2de73280b01e5d943593dd1aa2c01c5b9112f78 should treat this as an active risk. The vulnerability is rated HIGH severity with a CVSS score of 7.3, and a working exploit has already been made public.
What an Attacker Can Actually Do
Imagine your company's AI assistant is connected to an internal dashboard — something that lives behind your firewall and would normally never be reachable from the outside internet. Now imagine a stranger on the internet can trick your server into knocking on that dashboard's door on their behalf, and then reporting back what it finds. That is the essence of what this vulnerability enables.
The attack works by feeding a specially crafted web address into a feature called puppeteer_navigate — the part of the software that instructs a headless browser to visit URLs and retrieve content. Because the server doesn't properly validate or restrict what addresses it's allowed to visit, an attacker can point it inward, toward cloud metadata endpoints, internal admin panels, databases, or other services that should never be exposed. The server obediently fetches the content and the attacker reads the response. No login, no credentials, no physical access — just a malicious URL sent from anywhere on the internet.
The danger compounds quickly in cloud environments. Services like AWS, Google Cloud, and Azure host a special internal address (commonly 169.254.169.254) that hands out API keys and instance credentials to any process that asks from inside the network. An attacker exploiting this flaw could potentially harvest those credentials and pivot into your cloud infrastructure entirely — turning a web address manipulation into a full account takeover.
The Technical Anchor Security Teams Need
The root cause is a classic Server-Side Request Forgery (SSRF) vulnerability located in src/puppeteer/index.ts, specifically within the puppeteer_navigate handler. The url argument passed to this function undergoes insufficient validation before being handed to Puppeteer's navigation engine, allowing arbitrary internal and external destinations. The flaw is tracked as CVE-2026-7094 with a CVSS v3 base score of 7.3 (HIGH) and carries a remote attack vector with no privileges or user interaction required — a combination that makes it highly attractive for automated scanning and exploitation frameworks.
Discovery, Disclosure, and the Current Threat Landscape
The vulnerability was assigned CVE-2026-7094 and has been publicly disclosed, with proof-of-concept exploit code already in circulation. As of publication, no confirmed active exploitation campaigns have been attributed to this flaw — but that window is typically short once a working exploit is public. Security researchers have observed that SSRF vulnerabilities in AI tooling infrastructure are an emerging focus for threat actors precisely because these servers sit at a privileged intersection: trusted by internal systems, yet often accessible from the internet.
The fact that GlutamateMCPServers operates on a rolling release cycle adds a layer of operational complexity. There is no "version 1.2.3 is safe, version 1.2.2 is not" clarity here. Defenders must work at the commit level — which is uncommon in most vulnerability management workflows and may cause this flaw to slip through standard patching processes undetected.
What You Should Do Right Now
Three concrete steps, in order of urgency:
-
Update to a commit after
e2de73280b01e5d943593dd1aa2c01c5b9112f78immediately. Pull the latest code from the ShadowCloneLabs GlutamateMCPServers repository. Because this is a rolling release project, check the commit history for any patches referencing URL validation insrc/puppeteer/index.tsor thepuppeteer_navigatehandler. If no upstream patch is yet available, take the service offline or isolate it from internet-facing exposure until one is released. -
Block outbound requests to internal network ranges at the firewall or egress layer. Configure your network so that the server running GlutamateMCPServers cannot reach RFC 1918 address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) or cloud metadata endpoints (
169.254.169.254,fd00:ec2::254on AWS, equivalent endpoints on GCP and Azure). This limits blast radius even if the software itself remains unpatched temporarily. - Audit your logs for suspicious outbound requests originating from the MCP server process. Look for HTTP requests to internal IPs, localhost, metadata service addresses, or unusual domains that the server would have no legitimate reason to contact. Tools like Falco, cloud-native VPC flow logs, or even simple grep patterns against your application logs can surface signs of early reconnaissance. If you find anomalies dating back weeks, treat it as a potential breach and begin incident response procedures.
CVE: CVE-2026-7094 |
CVSS: 7.3 HIGH |
Affected component: puppeteer_navigate in src/puppeteer/index.ts |
Affected through commit: e2de73280b01e5d943593dd1aa2c01c5b9112f78 |
Exploitation: Public PoC available, no confirmed active campaigns at time of publication