CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
3467 vulnerabilities reference this CWE, most recent first.
GHSA-4XP2-W642-7MCX
Vulnerability from github – Published: 2023-09-27 00:35 – Updated: 2023-10-02 20:13Impact
An attacker with the ability to create or modify CiliumNetworkPolicy objects in a particular namespace is able to affect traffic on an entire Cilium cluster, potentially bypassing policy enforcement in other namespaces.
By using a crafted endpointSelector that uses the DoesNotExist operator on the reserved:init label, the attacker can create policies that bypass namespace restrictions and affect the entire Cilium cluster. This includes potentially allowing or denying all traffic.
This attack requires API server access, as described in the Kubernetes API Server Attacker section of the Cilium Threat Model.
Patches
This issue was patched in https://github.com/cilium/cilium/pull/28007
This issue affects:
- Cilium <= v1.14.1
- Cilium <= v1.13.6
- Cilium <= v1.12.13
This issue has been resolved in:
- Cilium v1.14.2
- Cilium v1.13.7
- Cilium v1.12.14
Workarounds
An admission webhook can be used to prevent the use of endpointSelectors that use the DoesNotExist operator on the reserved:init label in CiliumNetworkPolicies.
Acknowledgements
The Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and @joestringer for the fix.
For more information
If you have any questions or comments about this advisory, please reach out on Slack.
If you think you have found a vulnerability in Cilium, we strongly encourage you to report it to our private security mailing list at security@cilium.io first, before disclosing it in any public forum. This is a private mailing list for Cilium's internal security team, and your report will be treated as top priority.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.14.0"
},
{
"fixed": "1.14.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "1.13.0"
},
{
"fixed": "1.13.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cilium/cilium"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.12.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41333"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-27T00:35:26Z",
"nvd_published_at": "2023-09-27T15:19:30Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nAn attacker with the ability to create or modify CiliumNetworkPolicy objects in a particular namespace is able to affect traffic on an entire Cilium cluster, potentially bypassing policy enforcement in other namespaces.\n\nBy using a crafted `endpointSelector` that uses the `DoesNotExist` operator on the `reserved:init` label, the attacker can create policies that bypass namespace restrictions and affect the entire Cilium cluster. This includes potentially allowing or denying all traffic.\n\nThis attack requires API server access, as described in the [Kubernetes API Server Attacker](https://docs.cilium.io/en/stable/security/threat-model/#kubernetes-api-server-attacker) section of the Cilium Threat Model.\n\n### Patches\n\nThis issue was patched in https://github.com/cilium/cilium/pull/28007\n\nThis issue affects:\n\n- Cilium \u003c= v1.14.1\n- Cilium \u003c= v1.13.6\n- Cilium \u003c= v1.12.13\n\nThis issue has been resolved in:\n\n- Cilium v1.14.2\n- Cilium v1.13.7\n- Cilium v1.12.14\n\n### Workarounds\n\nAn admission webhook can be used to prevent the use of `endpointSelector`s that use the `DoesNotExist` operator on the `reserved:init` label in CiliumNetworkPolicies.\n\n### Acknowledgements\nThe Cilium community has worked together with members of Palantir and Isovalent to prepare these mitigations. Special thanks to @odinuge for reporting this issue and @joestringer for the fix.\n\n### For more information\nIf you have any questions or comments about this advisory, please reach out on [Slack](https://docs.cilium.io/en/latest/community/community/#slack).\n\nIf you think you have found a vulnerability in Cilium, we strongly encourage you to report it to our private security mailing list at [security@cilium.io](mailto:security@cilium.io) first, before disclosing it in any public forum. This is a private mailing list for Cilium\u0027s internal security team, and your report will be treated as top priority. ",
"id": "GHSA-4xp2-w642-7mcx",
"modified": "2023-10-02T20:13:42Z",
"published": "2023-09-27T00:35:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/security/advisories/GHSA-4xp2-w642-7mcx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41333"
},
{
"type": "WEB",
"url": "https://github.com/cilium/cilium/pull/28007"
},
{
"type": "WEB",
"url": "https://docs.cilium.io/en/stable/security/threat-model/#kubernetes-api-server-attacker"
},
{
"type": "PACKAGE",
"url": "https://github.com/cilium/cilium"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cilium vulnerable to bypass of namespace restrictions in CiliumNetworkPolicy "
}
GHSA-522H-49X4-XQ7R
Vulnerability from github – Published: 2024-11-18 09:31 – Updated: 2024-11-18 09:31A low privileged remote attacker may modify the configuration of the CODESYS V3 service through a missing authentication vulnerability which could lead to full system access and/or DoS.
{
"affected": [],
"aliases": [
"CVE-2024-41969"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-18T09:15:05Z",
"severity": "HIGH"
},
"details": "A low privileged remote attacker may\u00a0modify the configuration of the CODESYS V3 service through a missing authentication vulnerability which could lead to full system access and/or DoS.",
"id": "GHSA-522h-49x4-xq7r",
"modified": "2024-11-18T09:31:13Z",
"published": "2024-11-18T09:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41969"
},
{
"type": "WEB",
"url": "https://cert.vde.com/en/advisories/VDE-2024-047"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-524H-35W7-86XP
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23In all versions of FactoryTalk View SEA remote, an authenticated attacker may be able to utilize certain handlers to interact with the data on the remote endpoint since those handlers do not enforce appropriate permissions. Rockwell Automation recommends enabling built in security features found within FactoryTalk View SE. Users should follow guidance found in knowledge base articles 109056 and 1126943 to set up IPSec and/or HTTPs.
{
"affected": [],
"aliases": [
"CVE-2020-12028"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-20T16:15:00Z",
"severity": "MODERATE"
},
"details": "In all versions of FactoryTalk View SEA remote, an authenticated attacker may be able to utilize certain handlers to interact with the data on the remote endpoint since those handlers do not enforce appropriate permissions. Rockwell Automation recommends enabling built in security features found within FactoryTalk View SE. Users should follow guidance found in knowledge base articles 109056 and 1126943 to set up IPSec and/or HTTPs.",
"id": "GHSA-524h-35w7-86xp",
"modified": "2022-05-24T17:23:57Z",
"published": "2022-05-24T17:23:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12028"
},
{
"type": "WEB",
"url": "https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1126944"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsa-20-170-05"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/160156/Rockwell-FactoryTalk-View-SE-SCADA-Unauthenticated-Remote-Code-Execution.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-525J-95GF-766F
Vulnerability from github – Published: 2026-03-09 19:48 – Updated: 2026-04-27 14:57Summary
The remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2.
Details
The issue stems from two flaws: 1. Tokenized download URLs are written into the persistent share model
backend/http/share.go
convertToFrontendShareResponse(line 63)
s.DownloadURL = getShareURL(r, s.Hash, true, s.Token)
- The public endpoint:
GET /public/api/share/info
returns shareLink.CommonShare without clearing DownloadURL.
Since Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability.
The previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL
PoC
-
Create a password protected share as an authenticated user
-
Copy the public share URL (the clipboard WITHOUT an arrow)
http://yourdomain/public/share/yoursharedhash
Example:
http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw -
Query the public share endpoint via curl request:
curl 'http://yourdomain/public/api/share/info?hash=(your-share-hash)' -H 'Accept: */*'
Example:
curl 'http://yourdomain/public/api/share/info?hash=2EBGbXgXg5dpw-nK0RG6vw' -H 'Accept: */*'Response includes:
{ "shareTheme": "default", "title": "Shared files - test.md", "description": "A share has been sent to you to view or download.", "disableSidebar": false, "downloadURL": "http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D", "shareURL": "http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw", "enforceDarkLightMode": "default", "viewMode": "normal", "shareType": "normal", "sidebarLinks": [ { "name": "Share QR Code and Info", "category": "shareInfo", "target": "#", "icon": "qr_code" }, { "name": "Download", "category": "download", "target": "#", "icon": "download" }, { "name": "sourceLocation", "category": "custom", "target": "/srv/test.md", "icon": "" } ], "hasPassword": true, "disableLoginOption": false, "sourceURL": "/srv/test.md" }Note the response "hasPassword": true and downloadURL includes token= parameter -
Take the downloadURL(seen in json data response) and replace \u0026 with & and paste link into Incognito or private browser to ensure cookies are not interfering
Example:http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw&token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D
Browser downloads file immediately without requiring password
Impact
An unauthenticated attacker can retrieve password protected shared files without the password. Results in authentication bypass, unauthorized file access and confidentiality compromise
Recommended Remediation
Sanitize DownloadURL in public share info responses via commonShare.DownloadURL = "" before returning the json response in shareInfoHandler method located in backend/share.go
Structural fix, only generate tokenized URLs after successful password validation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/gtsteffaniak/filebrowser/backend"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260307130210-09713b32a5f6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30933"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306",
"CWE-602"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T19:48:12Z",
"nvd_published_at": "2026-03-10T18:18:53Z",
"severity": "HIGH"
},
"details": "### Summary\nThe remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2. \n\n\n### Details\nThe issue stems from two flaws:\n1. Tokenized download URLs are written into the persistent share model\n```\nbackend/http/share.go\nconvertToFrontendShareResponse(line 63)\ns.DownloadURL = getShareURL(r, s.Hash, true, s.Token)\n```\n2. The public endpoint:\n```\nGET /public/api/share/info\nreturns shareLink.CommonShare without clearing DownloadURL.\n```\n\nSince Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability.\n\nThe previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL\n\n\n### PoC\n1. Create a password protected share as an authenticated user \n\n2. Copy the public share URL (the clipboard WITHOUT an arrow) \n `http://yourdomain/public/share/yoursharedhash` \n Example: \n `http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw` \n\n3. Query the public share endpoint via curl request: \n`curl \u0027http://yourdomain/public/api/share/info?hash=(your-share-hash)\u0027 -H \u0027Accept: */*\u0027 ` \nExample: \n`curl \u0027http://yourdomain/public/api/share/info?hash=2EBGbXgXg5dpw-nK0RG6vw\u0027 -H \u0027Accept: */*\u0027 ` \n \n Response includes:\n ```\n {\n \"shareTheme\": \"default\",\n \"title\": \"Shared files - test.md\",\n \"description\": \"A share has been sent to you to view or download.\",\n \"disableSidebar\": false,\n \"downloadURL\": \"http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D\",\n \"shareURL\": \"http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw\",\n \"enforceDarkLightMode\": \"default\",\n \"viewMode\": \"normal\",\n \"shareType\": \"normal\",\n \"sidebarLinks\": [\n {\n \"name\": \"Share QR Code and Info\",\n \"category\": \"shareInfo\",\n \"target\": \"#\",\n \"icon\": \"qr_code\"\n },\n {\n \"name\": \"Download\",\n \"category\": \"download\",\n \"target\": \"#\",\n \"icon\": \"download\"\n },\n {\n \"name\": \"sourceLocation\",\n \"category\": \"custom\",\n \"target\": \"/srv/test.md\",\n \"icon\": \"\"\n }\n ],\n \"hasPassword\": true,\n \"disableLoginOption\": false,\n \"sourceURL\": \"/srv/test.md\"\n }\n ```\nNote the response \"hasPassword\": true and downloadURL includes token= parameter\n\n\n4. Take the downloadURL(seen in json data response) and replace \\u0026 with \u0026 and paste link into Incognito or private browser to ensure cookies are not interfering \nExample:\n`http://yourdomain/public/api/resources/download?hash=2EBGbXgXg5dpw-nK0RG6vw\u0026token=EGGYjfyMgqlqknDAIjXekI3DXJ40Nxht.5-q3gnZVbeJ1KYTc-gLb04N6smp-AH2-d4AUFLXgQ6I%3D`\n\nBrowser downloads file immediately without requiring password\n\n### Impact \nAn unauthenticated attacker can retrieve password protected shared files without the password.\nResults in authentication bypass, unauthorized file access and confidentiality compromise\n\n### Recommended Remediation\nSanitize DownloadURL in public share info responses via `commonShare.DownloadURL = \"\"` before returning the json response in shareInfoHandler method located in backend/share.go\n\nStructural fix, only generate tokenized URLs after successful password validation",
"id": "GHSA-525j-95gf-766f",
"modified": "2026-04-27T14:57:02Z",
"published": "2026-03-09T19:48:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/security/advisories/GHSA-525j-95gf-766f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30933"
},
{
"type": "PACKAGE",
"url": "https://github.com/gtsteffaniak/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/releases/tag/v1.2.2-stable"
},
{
"type": "WEB",
"url": "https://github.com/gtsteffaniak/filebrowser/releases/tag/v1.3.1-beta"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "FileBrowser Quantum: Password-Protected Share Bypass via /public/api/share/info"
}
GHSA-528V-FV7H-V892
Vulnerability from github – Published: 2024-02-29 03:33 – Updated: 2024-11-05 21:30Internet passwords stored in Person documents in the Domino® Directory created using the "Add Person" action on the People & Groups tab in the Domino® Administrator are secured using a cryptographically weak hash algorithm. This could enable attackers with access to the hashed value to determine a user's password, e.g. using a brute force attack. This issue does not impact Person documents created through user registration https://help.hcltechsw.com/domino/10.0.1/admin/conf_userregistration_c.html .
{
"affected": [],
"aliases": [
"CVE-2023-37495"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-29T01:40:04Z",
"severity": "MODERATE"
},
"details": "Internet passwords stored in Person documents in the Domino\u00ae Directory created using the \"Add Person\" action on the People \u0026 Groups tab in the Domino\u00ae Administrator are secured using a cryptographically weak hash algorithm. This could enable attackers with access to the hashed value to determine a user\u0027s password, e.g. using a brute force attack. This issue does not impact Person documents created through user registration https://help.hcltechsw.com/domino/10.0.1/admin/conf_userregistration_c.html . \n",
"id": "GHSA-528v-fv7h-v892",
"modified": "2024-11-05T21:30:31Z",
"published": "2024-02-29T03:33:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37495"
},
{
"type": "WEB",
"url": "https://support.hcltechsw.com/csm?id=kb_article\u0026sysparm_article=KB0107585"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-52CQ-7V8R-62C6
Vulnerability from github – Published: 2026-05-08 16:32 – Updated: 2026-05-08 16:32Unauthenticated 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:
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:
# 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:
- In HTTP transport mode, refuse to start if
MCP_API_KEYis unset. Add a startup check inserver.py(orrun.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." ) - Update
.env.example— changeMCP_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))" - Add a one-line warning to the README before the ngrok step: "Before running ngrok, set
MCP_API_KEYin 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:
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:
import re
PLACE_ID_PATTERN = re.compile(r'^[A-Za-z0-9_\-]+(/[A-Za-z0-9_\-]+)?$')
async def get_place_details(self, place_id: str) -> dict:
if not PLACE_ID_PATTERN.match(place_id):
raise ValueError(f"Invalid place_id format: {place_id!r}")
url = f"https://places.googleapis.com/v1/places/{place_id}"
...
Google Place IDs are alphanumeric strings with an optional places/ segment prefix. That pattern eliminates all path and query injection.
The third issue is structural and currently benign, but worth flagging given the package is installable via PyPI as gmaps-mcp.
The repository ships .claude/skills/google-maps-mcp/SKILL.md at the repo root. Claude Code and any harness using the same skill auto-discovery path pattern will auto-load this file as a system-level instruction when an agent clones the repository or opens the directory after install. The current content is legitimate usage documentation, so there's no active harm — but the file is a persistent injection surface. A future commit to SKILL.md could plant arbitrary instructions (exfiltrate environment variables, call an attacker-controlled URL before each tool response, silently modify output) that would enter agent context without any visible indicator for every developer or agent that installs gmaps-mcp.
The exposure is broader than it would be for a private repo: PyPI install means the audience includes every Claude Code, Cursor, and similar agent-enabled IDE user who pulls the package and opens it in an agent context.
Fix: Move the skill documentation out of the auto-load path. Rename it to docs/claude-skill-reference.md (not auto-loaded), or remove it and note in the README that users who want Claude Code skill integration should add the file locally. Either approach preserves the UX without leaving a standing injection surface in the install tree.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.1.2"
},
"package": {
"ecosystem": "PyPI",
"name": "gmaps-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T16:32:29Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Unauthenticated HTTP Transport Allows Unlimited Google Maps API Calls at Operator Expense\n\nThe `gmaps-mcp` codebase was reviewed at commit `e671db68c804c9e67d51582d3280839ffa65f127` and three issues worth flagging were discovered \u2014 one high-severity, one medium, one structural. There were no preexisiting CVEs for this package yet and the repository had no prior security issues.\n\nThe primary issue is that the HTTP transport in `server.py` skips authentication entirely when `MCP_API_KEY` is not set \u2014 which is the default, since `.env.example` ships the key as a blank value. Any unauthenticated caller who knows the server\u0027s public URL can invoke all six tools and generate live, billed Google Maps API requests against the operator\u0027s 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.\n\n**Affected files and exact lines:**\n\n`src/google_maps_mcp/server.py`, lines 186\u2013192:\n```python\nexpected_key = os.getenv(\"MCP_API_KEY\")\n\nif not expected_key:\n # If no MCP_API_KEY is set, allow all requests (development mode)\n return await call_next(request)\n\nif api_key != expected_key:\n return JSONResponse(\n {\"error\": \"Invalid or missing API key. Provide X-API-Key header.\"},\n status_code=401\n )\n```\n\n`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 \u2014 not in the middleware stack, not in `GoogleMapsClient`, not in the tool handlers.\n\n**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\u0027s public endpoint scan surface or via a targeted test of shared URLs. No credentials needed to call the server.\n\n**PoC \u2014 reproduces from the default config:**\n```bash\n# Start with default .env.example (MCP_API_KEY blank/unset)\nexport GOOGLE_MAPS_API_KEY=\u003coperator_key\u003e\npython run.py # binds 0.0.0.0:8000\n\n# From attacker machine \u2014 no X-API-Key header needed:\ncurl -X POST http://\u003cserver\u003e:8000/mcp/ \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\"params\":{\"name\":\"geocode\",\"arguments\":{\"address\":\"Times Square New York\"}}}\u0027\n# Returns geocoding results. Request billed to operator\u0027s GCP project.\n```\n\nThe financial harm is real and accumulates fast. Google\u0027s $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\u0027t need the `GOOGLE_MAPS_API_KEY` value \u2014 they only need the MCP server URL.\n\n**Fix \u2014 three concrete changes, no new dependencies:**\n\n1. 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:\n ```python\n if transport == \"http\" and not os.getenv(\"MCP_API_KEY\"):\n raise SystemExit(\n \"ERROR: MCP_API_KEY must be set before starting the HTTP server. \"\n \"Unset key allows unauthenticated access to all Google Maps API calls.\"\n )\n ```\n2. Update `.env.example` \u2014 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))\"`\n3. 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.\"\n\nA 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.\n\n---\n\nThe second issue is in `src/google_maps_mcp/client.py` at line 130:\n\n```python\nurl = f\"https://places.googleapis.com/v1/places/{place_id}\"\n```\n\n`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 \u2014 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.\n\n**Fix:**\n```python\nimport re\n\nPLACE_ID_PATTERN = re.compile(r\u0027^[A-Za-z0-9_\\-]+(/[A-Za-z0-9_\\-]+)?$\u0027)\n\nasync def get_place_details(self, place_id: str) -\u003e dict:\n if not PLACE_ID_PATTERN.match(place_id):\n raise ValueError(f\"Invalid place_id format: {place_id!r}\")\n url = f\"https://places.googleapis.com/v1/places/{place_id}\"\n ...\n```\n\nGoogle Place IDs are alphanumeric strings with an optional `places/` segment prefix. That pattern eliminates all path and query injection.\n\n---\n\nThe third issue is structural and currently benign, but worth flagging given the package is installable via PyPI as `gmaps-mcp`.\n\nThe repository ships `.claude/skills/google-maps-mcp/SKILL.md` at the repo root. Claude Code and any harness using the same skill auto-discovery path pattern will auto-load this file as a system-level instruction when an agent clones the repository or opens the directory after install. The current content is legitimate usage documentation, so there\u0027s no active harm \u2014 but the file is a persistent injection surface. A future commit to `SKILL.md` could plant arbitrary instructions (exfiltrate environment variables, call an attacker-controlled URL before each tool response, silently modify output) that would enter agent context without any visible indicator for every developer or agent that installs `gmaps-mcp`.\n\nThe exposure is broader than it would be for a private repo: PyPI install means the audience includes every Claude Code, Cursor, and similar agent-enabled IDE user who pulls the package and opens it in an agent context.\n\n**Fix:** Move the skill documentation out of the auto-load path. Rename it to `docs/claude-skill-reference.md` (not auto-loaded), or remove it and note in the README that users who want Claude Code skill integration should add the file locally. Either approach preserves the UX without leaving a standing injection surface in the install tree.",
"id": "GHSA-52cq-7v8r-62c6",
"modified": "2026-05-08T16:32:29Z",
"published": "2026-05-08T16:32:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/arthurkatcher/google-maps-mcp/security/advisories/GHSA-52cq-7v8r-62c6"
},
{
"type": "WEB",
"url": "https://github.com/arthurkatcher/google-maps-mcp/commit/00d872507c78e8116bbf9de7be7cd112945c0fd8"
},
{
"type": "WEB",
"url": "https://github.com/arthurkatcher/google-maps-mcp/commit/3ae32643da469f962e67e8ef9726cd4d9bf4587d"
},
{
"type": "PACKAGE",
"url": "https://github.com/arthurkatcher/google-maps-mcp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "gmaps-mcp\u0027s unauthenticated HTTP transport allows unlimited Google Maps API calls at operator expense"
}
GHSA-52GQ-7J6C-XW6X
Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2024-03-04 23:14The default configuration in Apache Cassandra 3.8 through 3.11.1 binds an unauthenticated JMX/RMI interface to all network interfaces, which allows remote attackers to execute arbitrary Java code via an RMI request. This issue is a regression of CVE-2015-0225. The regression was introduced in https://issues.apache.org/jira/browse/CASSANDRA-12109. The fix for the regression is implemented in https://issues.apache.org/jira/browse/CASSANDRA-14173. This fix is contained in the 3.11.2 release of Apache Cassandra.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.11.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.apache.cassandra:cassandra-all"
},
"ranges": [
{
"events": [
{
"introduced": "3.8"
},
{
"fixed": "3.11.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-8016"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-29T18:54:45Z",
"nvd_published_at": "2018-06-28T16:29:00Z",
"severity": "CRITICAL"
},
"details": "The default configuration in Apache Cassandra 3.8 through 3.11.1 binds an unauthenticated JMX/RMI interface to all network interfaces, which allows remote attackers to execute arbitrary Java code via an RMI request. This issue is a regression of CVE-2015-0225. The regression was introduced in https://issues.apache.org/jira/browse/CASSANDRA-12109. The fix for the regression is implemented in https://issues.apache.org/jira/browse/CASSANDRA-14173. This fix is contained in the 3.11.2 release of Apache Cassandra.",
"id": "GHSA-52gq-7j6c-xw6x",
"modified": "2024-03-04T23:14:46Z",
"published": "2022-05-13T01:53:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-8016"
},
{
"type": "WEB",
"url": "https://github.com/beobal/cassandra/commit/28ee665b3c0c9238b61a871064f024d54cddcc79"
},
{
"type": "WEB",
"url": "https://issues.apache.org/jira/browse/CASSANDRA-14173"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/bafb9060bbdf958a1c15ba66c68531116fba4a83858a2796254da066@%3Cuser.cassandra.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Missing Authentication for Critical Function in Apache Cassandra"
}
GHSA-52HF-8HGX-M78V
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-09-25 12:30Missing authentication in the StudentPopupDetails_Timetable method in IDAttend’s IDWeb application 3.1.052 and earlier allows extraction sensitive student data by unauthenticated attackers.
{
"affected": [],
"aliases": [
"CVE-2023-26570"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T18:17:25Z",
"severity": "HIGH"
},
"details": "Missing authentication in the StudentPopupDetails_Timetable method in IDAttend\u2019s IDWeb application 3.1.052 and earlier allows extraction sensitive student data by unauthenticated attackers. ",
"id": "GHSA-52hf-8hgx-m78v",
"modified": "2024-09-25T12:30:39Z",
"published": "2023-10-25T18:32:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26570"
},
{
"type": "WEB",
"url": "https://www.themissinglink.com.au/security-advisories/cve-2023-26570"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-52MV-RF68-XH44
Vulnerability from github – Published: 2026-03-05 18:31 – Updated: 2026-03-25 18:31Missing Authorization, Missing Authentication for Critical Function vulnerability in rustdesk-server RustDesk Server rustdesk-server, rustdesk-server-pro on hbbs/hbbr on all server platforms (Rendezvous server (hbbs), relay server (hbbr) modules) allows Privilege Abuse. This vulnerability is associated with program files src/rendezvous_server.Rs, src/relay_server.Rs and program routines handle_punch_hole_request(), RegisterPeer handler, relay forwarding.
This issue affects RustDesk Server: through 1.7.5, through 1.1.15.
{
"affected": [],
"aliases": [
"CVE-2026-30784"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-05T16:16:19Z",
"severity": "HIGH"
},
"details": "Missing Authorization, Missing Authentication for Critical Function vulnerability in rustdesk-server RustDesk Server rustdesk-server, rustdesk-server-pro on hbbs/hbbr on all server platforms (Rendezvous server (hbbs), relay server (hbbr) modules) allows Privilege Abuse. This vulnerability is associated with program files src/rendezvous_server.Rs, src/relay_server.Rs and program routines handle_punch_hole_request(), RegisterPeer handler, relay forwarding.\n\nThis issue affects RustDesk Server: through 1.7.5, through 1.1.15.",
"id": "GHSA-52mv-rf68-xh44",
"modified": "2026-03-25T18:31:36Z",
"published": "2026-03-05T18:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30784"
},
{
"type": "WEB",
"url": "https://docs.google.com/document/d/e/2PACX-1vSds6jjpd38oO_yIAyd1HYtKNUuea-I-ozAPpGhYI7QgAU-QGJ7D8a4rOZVj1vmiUXV1EcdRHf9aZAW/pub"
},
{
"type": "WEB",
"url": "https://rustdesk.com/docs/en/self-host"
},
{
"type": "WEB",
"url": "https://www.vulsec.org"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-52P3-PMR5-F54R
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50Missing message authentication in the meta-protocol in Tinc VPN version 1.0.34 and earlier allows a man-in-the-middle attack to disable the encryption of VPN packets.
{
"affected": [],
"aliases": [
"CVE-2018-16758"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-10T21:29:00Z",
"severity": "MODERATE"
},
"details": "Missing message authentication in the meta-protocol in Tinc VPN version 1.0.34 and earlier allows a man-in-the-middle attack to disable the encryption of VPN packets.",
"id": "GHSA-52p3-pmr5-f54r",
"modified": "2022-05-13T01:50:27Z",
"published": "2022-05-13T01:50:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16758"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2018/dsa-4312"
},
{
"type": "WEB",
"url": "https://www.starwindsoftware.com/security/sw-20190227-0003"
},
{
"type": "WEB",
"url": "http://tinc-vpn.org/security"
},
{
"type": "WEB",
"url": "http://www.tinc-vpn.org/git/browse?p=tinc;a=commit;h=e97943b7cc9c851ae36f5a41e2b6102faa74193f"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
- 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.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
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 entirely. Then, these modified values would be submitted to the server.
Mitigation
- 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. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.