VulnerabilityPublished 8 May 2026

gmaps-mcp's unauthenticated HTTP transport allows unlimited Google Maps API calls at operator expense

Affects gmaps-mcpSource GCVE Database

CVSS 8.3 High : upgrade to 0.1.3 soon.

Data as of 27 Oct 2026, 00:07 UTC

CVSS 4.0 base score

8.3High

How severe the flaw is on the 0–10 CVSS scale.

Patch: Available – fixed in 0.1.3

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:H/SC:N/SI:N/SA:N

Attack Vector: Network
Attack Complexity: Low
Attack Requirements: Present
Privileges Required: None
User Interaction: None
Vulnerable system confidentiality: High
Vulnerable system integrity: None
Vulnerable system availability: High
Subsequent system confidentiality: None
Subsequent system integrity: None
Subsequent system availability: None

Bold values are the worst case: easiest to exploit or largest impact.

Attack Vector: Network: The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers).
Attack Complexity: Low: The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Attack Requirements: Present: The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: a race condition must be won to successfully exploit the vulnerability (the successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker, or the attack may need to be launched multiple times against a single target before being successful); the attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker).
Privileges Required: None: The attacker is unauthorized prior to attack, and therefore does not require any access to settings or files of the vulnerable system to carry out an attack.
User Interaction: None: The vulnerable system can be exploited without interaction from any human user, other than the attacker.
Vulnerable system confidentiality: High: There is a total loss of confidentiality, resulting in all information within the Vulnerable System being divulged to the attacker. Alternatively, access to only some restricted information is obtained, but the disclosed information presents a direct, serious impact. For example, an attacker steals the administrator's password, or private encryption keys of a web server.
Vulnerable system integrity: None: There is no loss of integrity within the Vulnerable System.
Vulnerable system availability: High: There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the Vulnerable System; this loss is either sustained (while the attacker continues to deliver the attack) or persistent (the condition persists even after the attack has completed). Alternatively, the attacker has the ability to deny some availability, but the loss of availability presents a direct, serious consequence to the Vulnerable System (e.g., the attacker cannot disrupt existing connections, but can prevent new connections; the attacker can repeatedly exploit a vulnerability that, in each instance of a successful attack, leaks a only small amount of memory, but after repeated exploitation causes a service to become completely unavailable).
Subsequent system confidentiality: None: There is no loss of confidentiality within the Subsequent System or all confidentiality impact is constrained to the Vulnerable System.
Subsequent system integrity: None: There is no loss of integrity within the Subsequent System or all integrity impact is constrained to the Vulnerable System.
Subsequent system availability: None: There is no impact to availability within the Subsequent System or all availability impact is constrained to the Vulnerable System.

Definitions: FIRST CVSS v4.0 specification.

What to do

Upgrade gmaps-mcp to 0.1.3.

Affected software

Product	Affected	Fixed in
PyPIgmaps-mcp	Affected <0.1.3	Fixed in 0.1.3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## Unauthenticated HTTP Transport Allows Unlimited Google Maps API Calls at Operator Expense The `gmaps-mcp` codebase was reviewed at commit `e671db68c804c9e67d51582d3280839ffa65f127` and three issues worth flagging were discovered — one high-severity, one medium, one structural. There were no preexisiting CVEs for this package yet and the repository had no prior security issues. The primary issue is that the HTTP transport in `server.py` skips authentication entirely when `MCP_API_KEY` is not set — which is the default, since `.env.example` ships the key as a blank value. Any unauthenticated caller who knows the server's public URL can invoke all six tools and generate live, billed Google Maps API requests against the operator's key. Because the README explicitly instructs operators to expose the server via ngrok (`ngrok http 8000`, then point MCP clients at the ngrok URL), this configuration gets deployed internet-facing as a matter of normal usage. **Affected files and exact lines:** `src/google_maps_mcp/server.py`, lines 186–192: ```python expected_key = os.getenv("MCP_API_KEY") if not expected_key: # If no MCP_API_KEY is set, allow all requests (development mode) return await call_next(request) if api_key != expected_key: return JSONResponse( {"error": "Invalid or missing API key. Provide X-API-Key header."}, status_code=401 ) ``` `run.py` lines 37 and 38 bind to `0.0.0.0:8000` by default (`MCP_HOST=0.0.0.0`, `MCP_PORT=8000`). No rate-limiting middleware exists anywhere in the codebase — not in the middleware stack, not in `GoogleMapsClient`, not in the tool handlers. **Attack model:** operator deploys with default config (blank `MCP_API_KEY`), exposes via ngrok per the README instructions, attacker discovers the ngrok URL through ngrok's public endpoint scan surface or via a targeted test of shared URLs. No credentials needed to call the server. **PoC — reproduces from the default config:** ```bash # Start with default .env.example (MCP_API_KEY blank/unset) export GOOGLE_MAPS_API_KEY=<operator_key> python run.py # binds 0.0.0.0:8000 # From attacker machine — no X-API-Key header needed: curl -X POST http://<server>:8000/mcp/ \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"geocode","arguments":{"address":"Times Square New York"}}}' # Returns geocoding results. Request billed to operator's GCP project. ``` The financial harm is real and accumulates fast. Google's $200/month free credit exhausts in roughly 3 hours at Places API pricing (~$17/1,000 requests) with a sustained 1 req/sec flood. More practically: any developer testing the ngrok URL, sharing it in a project thread, or posting it in a demo context creates a window where anyone with the link can silently drain quota. The attacker doesn't need the `GOOGLE_MAPS_API_KEY` value — they only need the MCP server URL. **Fix — three concrete changes, no new dependencies:** 1. In HTTP transport mode, refuse to start if `MCP_API_KEY` is unset. Add a startup check in `server.py` (or `run.py`) that exits with a clear message if the environment variable is blank when the transport is HTTP. Something like: ```python if transport == "http" and not os.getenv("MCP_API_KEY"): raise SystemExit( "ERROR: MCP_API_KEY must be set before starting the HTTP server. " "Unset key allows unauthenticated access to all Google Maps API calls." ) ``` 2. Update `.env.example` — change `MCP_API_KEY=` to a comment that makes the requirement explicit: `# Required for HTTP transport. Generate with: python -c "import secrets; print(secrets.token_hex(32))"` 3. Add a one-line warning to the README before the ngrok step: "Before running ngrok, set `MCP_API_KEY` in your `.env`. Without it, anyone with the URL can make unlimited Google Maps API calls billed to your account." A token-bucket rate limiter (e.g., `slowapi`, which is already compatible with Starlette/FastAPI-style apps) would add another layer, but the auth fix is the critical path. --- The second issue is in `src/google_maps_mcp/client.py` at line 130: ```python url = f"https://places.googleapis.com/v1/places/{place_id}" ``` `place_id` comes from the MCP tool caller with no format validation and is interpolated verbatim into the URL path. `httpx` does not encode `/` or `?` in f-string URLs — only when using a `params=` dict. A crafted `place_id` like `":searchText?textQuery=attacker-query"` produces `https://places.googleapis.com/v1/places/:searchText?textQuery=attacker-query`, which routes to the text search endpoint instead of the details endpoint, with attacker-controlled query content. Injection is bounded to `places.googleapis.com` since the host is hardcoded, but it lets an attacker hit different endpoint semantics within that namespace and potentially force higher-cost API calls. **Fix:** ```python import re PLACE_ID_PATTERN = re.compile(r'^[A-Za-z0-9_\-]+(/[A-Z

CWE-20Improper Input Validation (opens in a new tab)
Class weaknessLikelihood of exploit: HighCWE Top 25 (2025): #18OWASP Top 10 A05:2025: Injection (opens in a new tab)
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
MITRE discourages mapping vulnerabilities to this broad entry; the root cause is usually a more specific weakness.
Architecture and Design · Attack Surface Reduction
Consider using language-theoretic security (LangSec) techniques that characterize inputs using a formal language and build "recognizers" for that language. This effectively requires parsing to be a distinct layer that effectively enforces a boundary between raw input and internal data representations, instead of…
Architecture and Design · Libraries or Frameworks
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
Architecture and Design · Implementation · Attack Surface Reduction
Understand all the potential areas where untrusted inputs can enter the product, including but not limited to: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any…
OWASP Cheat Sheets
XML Security (opens in a new tab)
Mass Assignment (opens in a new tab)
Injection Prevention (opens in a new tab)
SQL Injection Prevention (opens in a new tab)
Injection Prevention in Java (opens in a new tab)
OWASP ASVS 4.0.3
V13.3.1 (opens in a new tab)
V5.1.4 (opens in a new tab)
V5.1.3 (opens in a new tab)
Attack patterns
Buffer Overflow via Environment Variables (opens in a new tab)
Server Side Include (SSI) Injection (opens in a new tab)
Cross Zone Scripting (opens in a new tab)
Command Line Execution through SQL Injection (opens in a new tab)
Object Relational Mapping Injection (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).
CWE-306Missing Authentication for Critical Function (opens in a new tab)
Base weaknessLikelihood of exploit: HighCWE Top 25 (2025): #21OWASP Top 10 A07:2025: Authentication Failures (opens in a new tab)
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
Architecture and Design
Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks…
Architecture and Design
Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment.
OWASP Cheat Sheets
OWASP Authentication (opens in a new tab)
OWASP ASVS 4.0.3
V1.2.3 (opens in a new tab)
V1.2.2 (opens in a new tab)
V1.2.4 (opens in a new tab)
Attack patterns
Choosing Message Identifier (opens in a new tab)
Force the System to Reset Values (opens in a new tab)
Using Unpublished Interfaces or Functionality (opens in a new tab)
Cross Site Request Forgery (opens in a new tab)
Communication Channel Manipulation (opens in a new tab)
From MITRE CWE, MITRE CAPEC and OWASP (Top 10, OpenCRE).

References

Community reviews

Loading reviews…

What to do

Affected software

Description

WeaknessesCWE-20, CWE-306

Technical details

References

Community reviews

Related threats