CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5944 vulnerabilities reference this CWE, most recent first.
GHSA-9GCX-XJJ8-2XXM
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10In JetBrains TeamCity before 2021.1.1, insufficient authentication checks for agent requests were made.
{
"affected": [],
"aliases": [
"CVE-2021-37545"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-06T14:15:00Z",
"severity": "HIGH"
},
"details": "In JetBrains TeamCity before 2021.1.1, insufficient authentication checks for agent requests were made.",
"id": "GHSA-9gcx-xjj8-2xxm",
"modified": "2022-05-24T19:10:18Z",
"published": "2022-05-24T19:10:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37545"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2021/08/05/jetbrains-security-bulletin-q2-2021"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-9GF4-MQ65-QX36
Vulnerability from github – Published: 2024-07-02 21:32 – Updated: 2024-07-02 21:32Improper authentication in MTP application prior to SMR Jul-2024 Release 1 allows local attackers to enter MTP mode without proper authentication.
{
"affected": [],
"aliases": [
"CVE-2024-20900"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-02T10:15:05Z",
"severity": "MODERATE"
},
"details": "Improper authentication in MTP application prior to SMR Jul-2024 Release 1 allows local attackers to enter MTP mode without proper authentication.",
"id": "GHSA-9gf4-mq65-qx36",
"modified": "2024-07-02T21:32:13Z",
"published": "2024-07-02T21:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20900"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=07"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-9GGQ-G75C-F8WX
Vulnerability from github – Published: 2022-05-14 03:01 – Updated: 2022-05-14 03:01On TP-Link TL-WR841N v13 00000001 0.9.1 4.16 v0001.0 Build 171019 Rel.55346n devices, all actions in the web interface are affected by bypass of authentication via an HTTP request.
{
"affected": [],
"aliases": [
"CVE-2018-12575"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-02T16:29:00Z",
"severity": "CRITICAL"
},
"details": "On TP-Link TL-WR841N v13 00000001 0.9.1 4.16 v0001.0 Build 171019 Rel.55346n devices, all actions in the web interface are affected by bypass of authentication via an HTTP request.",
"id": "GHSA-9ggq-g75c-f8wx",
"modified": "2022-05-14T03:01:07Z",
"published": "2022-05-14T03:01:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-12575"
},
{
"type": "WEB",
"url": "https://software-talk.org/blog/2018/06/tplink-wr841n-broken-auth-cve-2018-12575"
}
],
"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"
}
]
}
GHSA-9GHH-MMCQ-8PHC
Vulnerability from github – Published: 2024-06-17 22:30 – Updated: 2024-10-16 19:26Impact
A vulnerability has been identified in which Rancher does not automatically clean up a user which has been deleted from the configured authentication provider (AP). This characteristic also applies to disabled or revoked users, Rancher will not reflect these modifications which may leave the user’s tokens still usable.
An AP must be enabled to be affected by this, as the built-in User Management feature is not affected by this vulnerability. This issue may lead to an adversary gaining unauthorized access, as the user’s access privileges may still be active within Rancher even though they are no longer valid on the configured AP (please consult the MITRE ATT&CK - Technique - Valid Accounts for further information about the associated technique of attack).
It’s important to note that all configurable APs are impacted, see Rancher Docs - Configuring Authentication - External vs. Local Authentication to get the full authentication providers list.
To address this issue, the fix introduces a new user retention process that can be configured to run periodically and disable and/or delete inactive users. If enabled a user becomes subject to retention if they don't login for a configurable period of time. It's possible to set overrides for users that are used mainly for programmatic access (e.g. CI, scripts etc.) so that they don't become subject to retention for a longer period of time or at all. The user retention process is disabled by default, to avoid deleting wrong accounts. It is up to each user to enable it and configure the retention period as it best suits its environment.
Be aware that once the process is enabled, it might take a few days for previous users that have been revoked or deleted from the AP to be automatically removed from Rancher. To attenuate the risk of this condition, we recommend to regularly audit the AP’s user accounts for activity and manually deactivate or remove them from Rancher, if they are no longer needed.
For further information about the user retention process configuration, please refer to the dedicated documentation Rancher Docs - Advanced User Guides - Enable User Retention.
Patches
Patched versions include releases 2.7.14 and 2.8.5.
Workarounds
Administrators that are unable to update to a patched Rancher Manager version, are advised to delete Rancher users, via kubectl or through the UI, as soon as those users are deleted from the Authentication Provider. If a user needs to be temporarily disabled on the Authentication Provider, similar intervention will need to take place to reflect that change on Rancher Manager.
Below is a procedure to list and remove a deleted/disabled user in Rancher using kubectl (with a privileged kubeconfig).
- List all users bound to a supported external auth provider, then returns
username,uid,displayNameandPrincipalIdswhich contains the relatedauthprovider_user://ID
#!/bin/bash
for authprovider in {activedirectory,azure,common,genericoidc,github googleauth, keycloakoidc,ldap,oidc,publicapi,saml}
do
kubectl get users -o json | jq --arg authprovider "$authprovider" '.items[] | select(.principalIds[] | test("^" + $authprovider + "_user://")) | {username: .metadata.name, uid: .metadata.uid, displayName: .displayName, principalIds: .principalIds}'
done
- Once the
authprovider_user://ID(and/orDisplayName) is confirmed, remove the user from the Rancher UI or usingkubectl delete users <USERNAME>.
For more information
If you have any questions or comments about this advisory:
- Reach out to the SUSE Rancher Security team for security related inquiries.
- Open an issue in the Rancher repository.
- Verify with our support matrix and product support lifecycle.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.7.0"
},
{
"fixed": "2.7.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.8.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-22650"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306",
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-17T22:30:46Z",
"nvd_published_at": "2024-10-16T09:15:02Z",
"severity": "HIGH"
},
"details": "### Impact\n\nA vulnerability has been identified in which Rancher does not automatically clean up a user which has been deleted from the configured authentication provider (AP). This characteristic also applies to disabled or revoked users, Rancher will not reflect these modifications which may leave the user\u2019s tokens still usable.\n\nAn AP must be enabled to be affected by this, as the built-in User Management feature is not affected by this vulnerability.\nThis issue may lead to an adversary gaining unauthorized access, as the user\u2019s access privileges may still be active within Rancher even though they are no longer valid on the configured AP (please consult the [MITRE ATT\u0026CK - Technique - Valid Accounts](https://attack.mitre.org/techniques/T1078/) for further information about the associated technique of attack).\n\nIt\u2019s important to note that all configurable APs are impacted, see [Rancher Docs - Configuring Authentication - External vs. Local Authentication](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/authentication-config#external-vs-local-authentication) to get the full authentication providers list.\n\n\nTo address this issue, the fix introduces a new user retention process that can be configured to run periodically and disable and/or delete inactive users. If enabled a user becomes subject to retention if they don\u0027t login for a configurable period of time. It\u0027s possible to set overrides for users that are used mainly for programmatic access (e.g. CI, scripts etc.) so that they don\u0027t become subject to retention for a longer period of time or at all. The user retention process is disabled by default, to avoid deleting wrong accounts. It is up to each user to enable it and configure the retention period as it best suits its environment.\n\nBe aware that once the process is enabled, it might take a few days for previous users that have been revoked or deleted from the AP to be automatically removed from Rancher. To attenuate the risk of this condition, we recommend to regularly audit the AP\u2019s user accounts for activity and manually deactivate or remove them from Rancher, if they are no longer needed.\n\nFor further information about the user retention process configuration, please refer to the dedicated documentation [Rancher Docs - Advanced User Guides - Enable User Retention](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-user-retention).\n\n### Patches\n\nPatched versions include releases `2.7.14` and `2.8.5`.\n\n### Workarounds\n\nAdministrators that are unable to update to a patched Rancher Manager version, are advised to delete Rancher users, via kubectl or through the UI, as soon as those users are deleted from the Authentication Provider. If a user needs to be temporarily disabled on the Authentication Provider, similar intervention will need to take place to reflect that change on Rancher Manager.\n\n\nBelow is a procedure to list and remove a deleted/disabled user in Rancher using `kubectl` (with a privileged kubeconfig).\n\n1. List all users bound to a supported external auth provider, then returns `username`, `uid`, `displayName` and `PrincipalIds` which contains the related `authprovider_user://ID`\n\n```shell\n#!/bin/bash\n\nfor authprovider in {activedirectory,azure,common,genericoidc,github googleauth, keycloakoidc,ldap,oidc,publicapi,saml}\ndo \n\tkubectl get users -o json | jq --arg authprovider \"$authprovider\" \u0027.items[] | select(.principalIds[] | test(\"^\" + $authprovider + \"_user://\")) | {username: .metadata.name, uid: .metadata.uid, displayName: .displayName, principalIds: .principalIds}\u0027\ndone\n```\n\n2. Once the `authprovider_user://ID` (and/or `DisplayName`) is confirmed, remove the user from the Rancher UI or using `kubectl delete users \u003cUSERNAME\u003e`.\n\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.\n- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.\n- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).\n",
"id": "GHSA-9ghh-mmcq-8phc",
"modified": "2024-10-16T19:26:09Z",
"published": "2024-06-17T22:30:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/security/advisories/GHSA-9ghh-mmcq-8phc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22650"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-22650"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rancher does not automatically clean up a user deleted or disabled from the configured Authentication Provider"
}
GHSA-9GPQ-82H8-HGX9
Vulnerability from github – Published: 2021-12-15 00:01 – Updated: 2023-08-08 15:31glFusion CMS 1.7.9 is affected by an access control vulnerability via /public_html/users.php.
{
"affected": [],
"aliases": [
"CVE-2021-44949"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-14T15:15:00Z",
"severity": "CRITICAL"
},
"details": "glFusion CMS 1.7.9 is affected by an access control vulnerability via /public_html/users.php.",
"id": "GHSA-9gpq-82h8-hgx9",
"modified": "2023-08-08T15:31:24Z",
"published": "2021-12-15T00:01:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-44949"
},
{
"type": "WEB",
"url": "https://github.com/glFusion/glfusion/issues/487"
}
],
"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"
}
]
}
GHSA-9GQH-5752-RJF6
Vulnerability from github – Published: 2022-05-05 00:29 – Updated: 2023-04-26 21:30D-Link DIR-100 4.03B07: cli.cgi security bypass due to failure to check authentication parameters
{
"affected": [],
"aliases": [
"CVE-2013-7051"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-04T14:15:00Z",
"severity": "MODERATE"
},
"details": "D-Link DIR-100 4.03B07: cli.cgi security bypass due to failure to check authentication parameters",
"id": "GHSA-9gqh-5752-rjf6",
"modified": "2023-04-26T21:30:29Z",
"published": "2022-05-05T00:29:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2013-7051"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/90904"
},
{
"type": "WEB",
"url": "https://www.securityfocus.com/bid/65290"
},
{
"type": "WEB",
"url": "http://pigstarter.krebsco.de/report/2013-12-18_dir100.txt"
},
{
"type": "WEB",
"url": "http://www.exploit-db.com/exploits/31425"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-9GRP-VP5P-RX5W
Vulnerability from github – Published: 2022-05-17 02:39 – Updated: 2022-05-17 02:39An issue was discovered in WAGO 750-8202/PFC200 prior to FW04 (released August 2015), WAGO 750-881 prior to FW09 (released August 2016), and WAGO 0758-0874-0000-0111. By accessing a specific uniform resource locator (URL) on the web server, a malicious user is able to edit and to view settings without authenticating.
{
"affected": [],
"aliases": [
"CVE-2016-9362"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-13T21:59:00Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in WAGO 750-8202/PFC200 prior to FW04 (released August 2015), WAGO 750-881 prior to FW09 (released August 2016), and WAGO 0758-0874-0000-0111. By accessing a specific uniform resource locator (URL) on the web server, a malicious user is able to edit and to view settings without authenticating.",
"id": "GHSA-9grp-vp5p-rx5w",
"modified": "2022-05-17T02:39:40Z",
"published": "2022-05-17T02:39:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9362"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-16-357-02"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95074"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-9GW6-46QC-99VR
Vulnerability from github – Published: 2026-06-11 13:28 – Updated: 2026-06-11 13:28Unauthenticated HTTP MCP Tool Execution Leaks Operator Meta Access Token
| Field | Value |
|---|---|
| Repository | pipeboard-co/meta-ads-mcp |
| Affected version | ≤ 1.0.101 (commit 496c988 ~ 7d14226); Versions 1.0.102–1.0.105 lack git tags, so patch status is unconfirmed. |
| Vulnerability | CWE-287 — Improper Authentication |
| Severity | Critical |
| CVSS 3.1 | 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) |
Summary
AuthInjectionMiddleware.dispatch() at http_auth_integration.py:272 unconditionally forwards unauthenticated Streamable HTTP requests to downstream MCP tool handlers without issuing a 401 response, allowing any network-reachable caller to invoke MCP tools without authentication. When no per-request credential is present, tool handlers fall back to the META_ACCESS_TOKEN environment variable, and when the downstream Meta Graph API call fails, api.py:263–269 serialises the raw httpx request URL—including the operator's access_token as a query parameter—into the JSON-RPC response body, delivering the credential to the unauthenticated caller.
Affected Code
meta_ads_mcp/core/http_auth_integration.py:272 — middleware unconditionally calls call_next(request) even when no auth headers are present
if not auth_token and not pipeboard_token:
logger.warning("HTTP Auth Middleware: No authentication tokens found in headers")
try:
response = await call_next(request) # line 272: no 401 returned
return response
finally:
if auth_token:
FastMCPAuthIntegration.clear_auth_token()
if pipeboard_token:
FastMCPAuthIntegration.clear_pipeboard_token()
meta_ads_mcp/core/api.py:136 — operator token appended to URL query parameters, exposed verbatim in Graph API error response request_url
request_params = params or {}
request_params["access_token"] = access_token
Unauthenticated HTTP POST /mcp → AuthInjectionMiddleware.dispatch():272 (no 401 returned) → tool handler invokes make_api_request() using META_ACCESS_TOKEN env fallback → request_params["access_token"]:136 (token in URL) → Graph API error path at api.py:263–269 returns request_url containing access_token=… in 200 OK JSON-RPC response.
Proof of Concept
Step 1 — POST /mcp with no auth headers: HTTP 200 OK with operator access_token in request_url — proves unauthenticated tool execution and operator credential leakage.
docker run --rm -p 127.0.0.1:8080:8080 -e META_ACCESS_TOKEN=FAKE_TOKEN_FOR_POC_DEMO_123456789 meta-ads-mcp-vuln001 &
python3 poc.py
POST /mcp HTTP/1.1
Host: 127.0.0.1:8080
Content-Type: application/json
Accept: application/json, text/event-stream
{"jsonrpc":"2.0","method":"tools/call","id":2,"params":{"name":"get_ad_accounts","arguments":{"limit":1}}}
HTTP/1.1 200 OK
Content-Type: application/json
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"content": [
{
"type": "text",
"text": "{\"data\": \"{\\n \\\"error\\\": {\\n \\\"message\\\": \\\"HTTP Error: 400\\\",\\n \\\"details\\\": {\\n \\\"error\\\": {\\n \\\"message\\\": \\\"Invalid OAuth access token data.\\\",\\n \\\"type\\\": \\\"OAuthException\\\",\\n \\\"code\\\": 190\\n }\\n },\\n \\\"full_response\\\": {\\n \\\"status_code\\\": 400,\\n \\\"url\\\": \\\"https://graph.facebook.com/v24.0/me/adaccounts?...&access_token=FAKE_TOKEN_FOR_POC_DEMO_123456789\\\",\\n \\\"request_url\\\": \\\"https://graph.facebook.com/v24.0/me/adaccounts?fields=id%2Cname%2Caccount_id%2Caccount_status%2Camount_spent%2Cbalance%2Ccurrency%2Cage%2Cbusiness_city%2Cbusiness_country_code&limit=1&access_token=FAKE_TOKEN_FOR_POC_DEMO_123456789\\\"\\n }\\n }\\n}\"}"
}
],
"isError": false
}
}
Impact
An unauthenticated attacker who can reach the MCP server's HTTP port (default 8080) can invoke any registered MCP tool as the operator, consuming the operator's Meta Ads API quota and performing read or write operations on connected Meta ad accounts. When any tool call triggers a Graph API error, the operator's META_ACCESS_TOKEN is returned verbatim in the request_url field of the 200 OK JSON-RPC response, enabling the attacker to exfiltrate the long-lived credential and subsequently access the Meta Graph API directly outside the MCP interface.
Remediation
In AuthInjectionMiddleware.dispatch() (http_auth_integration.py), return a 401 Unauthorized response when neither auth_token nor pipeboard_token is present, instead of falling through to call_next:
from starlette.responses import Response
if not auth_token and not pipeboard_token:
return Response(
content='{"error":"Unauthorized"}',
status_code=401,
media_type="application/json",
)
In make_api_request() (api.py), strip access_token from the request_url in error payloads, or transmit the token via an Authorization: Bearer header rather than a URL query parameter to prevent it from appearing in URLs, server logs, or error responses.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.108"
},
"package": {
"ecosystem": "PyPI",
"name": "meta-ads-mcp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.109"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48039"
],
"database_specific": {
"cwe_ids": [
"CWE-209",
"CWE-287",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-11T13:28:29Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# Unauthenticated HTTP MCP Tool Execution Leaks Operator Meta Access Token\n\n| Field | Value |\n| ---------------- | ----- |\n| Repository | pipeboard-co/meta-ads-mcp |\n| Affected version | \u2264 1.0.101 (commit 496c988 ~ 7d14226); Versions 1.0.102\u20131.0.105 lack git tags, so patch status is unconfirmed. |\n| Vulnerability | CWE-287 \u2014 Improper Authentication |\n| Severity | Critical |\n| CVSS 3.1 | 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) |\n\n\n## Summary\n\n`AuthInjectionMiddleware.dispatch()` at `http_auth_integration.py:272` unconditionally forwards unauthenticated Streamable HTTP requests to downstream MCP tool handlers without issuing a `401` response, allowing any network-reachable caller to invoke MCP tools without authentication. When no per-request credential is present, tool handlers fall back to the `META_ACCESS_TOKEN` environment variable, and when the downstream Meta Graph API call fails, `api.py:263\u2013269` serialises the raw `httpx` request URL\u2014including the operator\u0027s `access_token` as a query parameter\u2014into the JSON-RPC response body, delivering the credential to the unauthenticated caller.\n\n## Affected Code\n\n`meta_ads_mcp/core/http_auth_integration.py:272` \u2014 middleware unconditionally calls `call_next(request)` even when no auth headers are present\n\n```python\n if not auth_token and not pipeboard_token:\n logger.warning(\"HTTP Auth Middleware: No authentication tokens found in headers\")\n\n try:\n response = await call_next(request) # line 272: no 401 returned\n return response\n finally:\n if auth_token:\n FastMCPAuthIntegration.clear_auth_token()\n if pipeboard_token:\n FastMCPAuthIntegration.clear_pipeboard_token()\n```\n\n`meta_ads_mcp/core/api.py:136` \u2014 operator token appended to URL query parameters, exposed verbatim in Graph API error response `request_url`\n\n```python\n request_params = params or {}\n request_params[\"access_token\"] = access_token\n```\n\nUnauthenticated HTTP POST /mcp \u2192 `AuthInjectionMiddleware.dispatch():272` (no 401 returned) \u2192 tool handler invokes `make_api_request()` using `META_ACCESS_TOKEN` env fallback \u2192 `request_params[\"access_token\"]:136` (token in URL) \u2192 Graph API error path at `api.py:263\u2013269` returns `request_url` containing `access_token=\u2026` in 200 OK JSON-RPC response.\n\n## Proof of Concept\n\nStep 1 \u2014 POST /mcp with no auth headers: HTTP 200 OK with operator `access_token` in `request_url` \u2014 proves unauthenticated tool execution and operator credential leakage.\n\n```bash\ndocker run --rm -p 127.0.0.1:8080:8080 -e META_ACCESS_TOKEN=FAKE_TOKEN_FOR_POC_DEMO_123456789 meta-ads-mcp-vuln001 \u0026\npython3 poc.py\n```\n\n```http\nPOST /mcp HTTP/1.1\nHost: 127.0.0.1:8080\nContent-Type: application/json\nAccept: application/json, text/event-stream\n\n{\"jsonrpc\":\"2.0\",\"method\":\"tools/call\",\"id\":2,\"params\":{\"name\":\"get_ad_accounts\",\"arguments\":{\"limit\":1}}}\n```\n\n```http\nHTTP/1.1 200 OK\nContent-Type: application/json\n\n{\n \"jsonrpc\": \"2.0\",\n \"id\": 2,\n \"result\": {\n \"content\": [\n {\n \"type\": \"text\",\n \"text\": \"{\\\"data\\\": \\\"{\\\\n \\\\\\\"error\\\\\\\": {\\\\n \\\\\\\"message\\\\\\\": \\\\\\\"HTTP Error: 400\\\\\\\",\\\\n \\\\\\\"details\\\\\\\": {\\\\n \\\\\\\"error\\\\\\\": {\\\\n \\\\\\\"message\\\\\\\": \\\\\\\"Invalid OAuth access token data.\\\\\\\",\\\\n \\\\\\\"type\\\\\\\": \\\\\\\"OAuthException\\\\\\\",\\\\n \\\\\\\"code\\\\\\\": 190\\\\n }\\\\n },\\\\n \\\\\\\"full_response\\\\\\\": {\\\\n \\\\\\\"status_code\\\\\\\": 400,\\\\n \\\\\\\"url\\\\\\\": \\\\\\\"https://graph.facebook.com/v24.0/me/adaccounts?...\u0026access_token=FAKE_TOKEN_FOR_POC_DEMO_123456789\\\\\\\",\\\\n \\\\\\\"request_url\\\\\\\": \\\\\\\"https://graph.facebook.com/v24.0/me/adaccounts?fields=id%2Cname%2Caccount_id%2Caccount_status%2Camount_spent%2Cbalance%2Ccurrency%2Cage%2Cbusiness_city%2Cbusiness_country_code\u0026limit=1\u0026access_token=FAKE_TOKEN_FOR_POC_DEMO_123456789\\\\\\\"\\\\n }\\\\n }\\\\n}\\\"}\"\n }\n ],\n \"isError\": false\n }\n}\n```\n\n## Impact\n\nAn unauthenticated attacker who can reach the MCP server\u0027s HTTP port (default 8080) can invoke any registered MCP tool as the operator, consuming the operator\u0027s Meta Ads API quota and performing read or write operations on connected Meta ad accounts. When any tool call triggers a Graph API error, the operator\u0027s `META_ACCESS_TOKEN` is returned verbatim in the `request_url` field of the 200 OK JSON-RPC response, enabling the attacker to exfiltrate the long-lived credential and subsequently access the Meta Graph API directly outside the MCP interface.\n\n## Remediation\n\nIn `AuthInjectionMiddleware.dispatch()` (`http_auth_integration.py`), return a `401 Unauthorized` response when neither `auth_token` nor `pipeboard_token` is present, instead of falling through to `call_next`:\n\n```python\nfrom starlette.responses import Response\n\nif not auth_token and not pipeboard_token:\n return Response(\n content=\u0027{\"error\":\"Unauthorized\"}\u0027,\n status_code=401,\n media_type=\"application/json\",\n )\n```\n\nIn `make_api_request()` (`api.py`), strip `access_token` from the `request_url` in error payloads, or transmit the token via an `Authorization: Bearer` header rather than a URL query parameter to prevent it from appearing in URLs, server logs, or error responses.",
"id": "GHSA-9gw6-46qc-99vr",
"modified": "2026-06-11T13:28:29Z",
"published": "2026-06-11T13:28:29Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pipeboard-co/meta-ads-mcp/security/advisories/GHSA-9gw6-46qc-99vr"
},
{
"type": "PACKAGE",
"url": "https://github.com/pipeboard-co/meta-ads-mcp"
},
{
"type": "WEB",
"url": "https://github.com/pipeboard-co/meta-ads-mcp/releases/tag/1.0.109"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "Meta Ads MCP: Unauthenticated HTTP MCP Tool Execution Leaks Operator Meta Access Token"
}
GHSA-9H28-9GG8-2PM4
Vulnerability from github – Published: 2026-04-01 06:31 – Updated: 2026-04-01 15:31The Order Notification for WooCommerce WordPress plugin before 3.6.3 overrides WooCommerce's permission checks to grant full access to all unauthenticated requests, enabling complete read/write access to store resources like products, coupons, and customers.
{
"affected": [],
"aliases": [
"CVE-2025-15484"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-01T06:16:14Z",
"severity": "CRITICAL"
},
"details": "The Order Notification for WooCommerce WordPress plugin before 3.6.3 overrides WooCommerce\u0027s permission checks to grant full access to all unauthenticated requests, enabling complete read/write access to store resources like products, coupons, and customers.",
"id": "GHSA-9h28-9gg8-2pm4",
"modified": "2026-04-01T15:31:15Z",
"published": "2026-04-01T06:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15484"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/ee9f1c0c-86bb-4922-9eb5-8aae78003eff"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-9H2G-5FP5-MW6Q
Vulnerability from github – Published: 2022-09-14 00:00 – Updated: 2022-09-16 00:00SAP GRC Access control Emergency Access Management allows an authenticated attacker to access a Firefighter session even after it is closed in Firefighter Logon Pad. This attack can be launched only within the firewall. On successful exploitation the attacker can gain access to admin session and completely compromise the application.
{
"affected": [],
"aliases": [
"CVE-2022-39801"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-13T16:15:00Z",
"severity": "HIGH"
},
"details": "SAP GRC Access control Emergency Access Management allows an authenticated attacker to access a Firefighter session even after it is closed in Firefighter Logon Pad. This attack can be launched only within the firewall. On successful exploitation the attacker can gain access to admin session and completely compromise the application.",
"id": "GHSA-9h2g-5fp5-mw6q",
"modified": "2022-09-16T00:00:32Z",
"published": "2022-09-14T00:00:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cla-assistant/cla-assistant/security/advisories/GHSA-jjjv-grgr-v8h3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39801"
},
{
"type": "WEB",
"url": "https://launchpad.support.sap.com/#/notes/3237075"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.