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.
4625 vulnerabilities reference this CWE, most recent first.
GHSA-QF8P-3W7C-8XGF
Vulnerability from github – Published: 2026-07-22 00:31 – Updated: 2026-07-22 00:31Vulnerability in the Service Delivery Platform product of Oracle Fusion Middleware (component: Messaging Enabler). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3, IIOP to compromise Service Delivery Platform. Successful attacks of this vulnerability can result in takeover of Service Delivery Platform. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
{
"affected": [],
"aliases": [
"CVE-2026-60387"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-21T22:17:41Z",
"severity": "CRITICAL"
},
"details": "Vulnerability in the Service Delivery Platform product of Oracle Fusion Middleware (component: Messaging Enabler). Supported versions that are affected are 12.2.1.4.0 and 14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3, IIOP to compromise Service Delivery Platform. Successful attacks of this vulnerability can result in takeover of Service Delivery Platform. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).",
"id": "GHSA-qf8p-3w7c-8xgf",
"modified": "2026-07-22T00:31:38Z",
"published": "2026-07-22T00:31:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60387"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2026.html"
}
],
"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-QFG5-F4WR-P29R
Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-08-13 00:00Tad Web is vulnerable to authorization bypass, thus remote attackers can exploit the vulnerability to use the original function of viewing bulletin boards and uploading files in the system.
{
"affected": [],
"aliases": [
"CVE-2021-41568"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-306",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-10-08T16:15:00Z",
"severity": "MODERATE"
},
"details": "Tad Web is vulnerable to authorization bypass, thus remote attackers can exploit the vulnerability to use the original function of viewing bulletin boards and uploading files in the system.",
"id": "GHSA-qfg5-f4wr-p29r",
"modified": "2022-08-13T00:00:37Z",
"published": "2022-05-24T19:17:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41568"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-5172-b012c-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QFH9-XG32-RP5P
Vulnerability from github – Published: 2024-06-14 06:34 – Updated: 2024-07-04 06:35Toshiba printers provides API without authentication for internal access. A local attacker can bypass authentication in applications, providing administrative access. As for the affected products/models/versions, see the reference URL.
{
"affected": [],
"aliases": [
"CVE-2024-27169"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-14T04:15:35Z",
"severity": "HIGH"
},
"details": "Toshiba printers provides API without authentication for internal access. A local attacker can bypass authentication in applications, providing administrative access. As for the affected products/models/versions, see the reference URL.",
"id": "GHSA-qfh9-xg32-rp5p",
"modified": "2024-07-04T06:35:04Z",
"published": "2024-06-14T06:34:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27169"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU97136265/index.html"
},
{
"type": "WEB",
"url": "https://www.toshibatec.com/information/20240531_01.html"
},
{
"type": "WEB",
"url": "https://www.toshibatec.com/information/pdf/information20240531_01.pdf"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Jul/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QFQR-55GF-4V3J
Vulnerability from github – Published: 2026-09-14 21:31 – Updated: 2026-09-14 21:31Missing Authentication for Critical Function (CWE-306) in the checkout session lookup handler (src/app/api/stripe/checkout_sessions/route.ts), exposed at GET /api/stripe/checkout_sessions, in MarcosCamara01 Ecommerce Template before commit 91e273c allows a remote, unauthenticated attacker holding a valid Stripe Checkout Session id (cs_...) to retrieve the full session object, including the buyer's name, email, phone, billing address, amount paid and internal userId, because the GET handler calls stripe.checkout.sessions.retrieve() and returns the result without checking for an authenticated session or session ownership. Sibling endpoints such as POST /api/stripe/payment already enforced authentication via auth.api.getSession(); this endpoint had no access control whatsoever. The session_id is exposed in the buyer's own browser URL after payment (success_url = /result?session_id={CHECKOUT_SESSION_ID}), so it leaks through Referer headers, analytics tools, server access logs and shared-machine browser history, resulting in disclosure of the buyer's personal data to an unauthenticated actor.
{
"affected": [],
"aliases": [
"CVE-2026-90896"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-14T21:17:42Z",
"severity": "HIGH"
},
"details": "Missing Authentication for Critical Function (CWE-306) in the checkout session lookup handler (src/app/api/stripe/checkout_sessions/route.ts), exposed at GET /api/stripe/checkout_sessions, in MarcosCamara01 Ecommerce Template before commit 91e273c allows a remote, unauthenticated attacker holding a valid Stripe Checkout Session id (cs_...) to retrieve the full session object, including the buyer\u0027s name, email, phone, billing address, amount paid and internal userId, because the GET handler calls stripe.checkout.sessions.retrieve() and returns the result without checking for an authenticated session or session ownership. Sibling endpoints such as POST /api/stripe/payment already enforced authentication via auth.api.getSession(); this endpoint had no access control whatsoever. The session_id is exposed in the buyer\u0027s own browser URL after payment (success_url = /result?session_id={CHECKOUT_SESSION_ID}), so it leaks through Referer headers, analytics tools, server access logs and shared-machine browser history, resulting in disclosure of the buyer\u0027s personal data to an unauthenticated actor.",
"id": "GHSA-qfqr-55gf-4v3j",
"modified": "2026-09-14T21:31:57Z",
"published": "2026-09-14T21:31:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-90896"
},
{
"type": "WEB",
"url": "https://github.com/MarcosCamara01/ecommerce-template/commit/91e273c69d976a3d205179e66e01fc399bfdd08b"
},
{
"type": "WEB",
"url": "https://secur0.com/en/cna/cve-list/cve-2026-90896-missing-authentication-ecommerce-template-checkout-session-pii"
}
],
"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:N/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-QG2G-G9W3-M5H8
Vulnerability from github – Published: 2026-09-18 17:16 – Updated: 2026-09-18 17:16Summary
A containerized MCP server running with the default network permission profile (insecure_allow_all: true) can reach host-local services via host.docker.internal. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host's localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.
Severity
High — This bypasses the container isolation model that is ToolHive's core security value proposition.
Reproduction
All tests performed from inside the filesystem MCP container (docker.io/mcp/filesystem:latest), started with default settings via thv run filesystem -- /tmp.
1. Container can reach the ToolHive control plane MCP endpoint
$ docker exec <container_id> wget -qO- \
--header="Content-Type: application/json" \
--header="Accept: application/json" \
--post-data='{"jsonrpc":"2.0","method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"evil-mcp","version":"1.0"}},"id":1}' \
http://host.docker.internal:50444/mcp
Result: Full MCP handshake succeeds:
{"jsonrpc":"2.0","id":1,"result":{"protocolVersion":"2025-03-26","capabilities":{"logging":{},"tools":{}},"serverInfo":{"name":"toolhive-mcp","version":"v0.9.3"}}}
2. Container can connect to another MCP server's proxy and call its tools
$ docker exec <container_id> wget -qO- \
--header="Content-Type: application/json" \
--header="Accept: application/json" \
--post-data='{"jsonrpc":"2.0","method":"tools/list","params":{},"id":2}' \
http://host.docker.internal:64965/mcp
Result: Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:
{"jsonrpc":"2.0","id":3,"result":{"content":[{"text":"Allowed directories:\n/tmp","type":"text"}]}}
3. Container can reach other host services
# Kubernetes API
$ docker exec <container_id> wget -qO- --no-check-certificate https://host.docker.internal:6443/version
{"major":"1","minor":"34","gitVersion":"v1.34.1"...}
# Ollama LLM API
$ docker exec <container_id> wget -qO- http://host.docker.internal:11434/api/tags
{"models":[{"name":"kimi-k2:1t-cloud"...}]}
Attack Scenarios
Scenario 1: Malicious MCP server pivots to privileged native MCP tools
Many users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have execute_command, write_file, or shell capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:
- Port-scan
host.docker.internalto discover listening services - Attempt MCP handshakes on discovered ports
- Call privileged tools (e.g.,
execute_command("rm -rf /")orwrite_file("/etc/crontab", "..."))
This achieves full host compromise without any container escape vulnerability.
Scenario 2: Compromised MCP server manipulates ToolHive itself
Via the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:
- List and stop other running MCP servers (denial of service)
- Start new MCP servers with attacker-controlled images
- Modify configurations
Scenario 3: Data exfiltration via cross-MCP-server access
A low-privilege MCP server (e.g., sequentialthinking with no file mounts) could reach the filesystem server's proxy and call read_file to access files it was never authorized to see.
Scenario 4: LLM model theft / abuse
As demonstrated, the container can reach Ollama's API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.
Root Causes
insecure_allow_all: trueas default — permits outbound connections to any destination includinghost.docker.internal- No authentication on ToolHive API / MCP proxies — any client that can reach the port can interact fully
- Docker's
host.docker.internalDNS — resolves to the host machine, bypassing localhost-only binding assumptions
Suggested Mitigations
Short-term
- Block
host.docker.internaland172.17.0.1(Docker gateway) in container networking by default, even wheninsecure_allow_allis enabled. These should require explicit opt-in. - Add authentication to MCP proxy endpoints — even a shared secret or token per session would prevent cross-container lateral movement.
Medium-term
- Network policy per container — ToolHive already has the
permission_profileinfrastructure. Add support for explicit allow-lists rather than just the binary none/all choice. - Isolate container networks — run each MCP server in its own Docker network with no access to the Docker bridge gateway.
Long-term
- Mutual TLS or token-based auth between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.
- Audit logging — log all MCP tool calls with source identification so lateral movement attempts are visible.
Environment
- ToolHive v0.9.3 (macOS desktop app, Docker runtime)
- Docker Desktop for Mac (host.docker.internal enabled by default)
- Tested with
docker.io/mcp/filesystem:latest
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/stacklok/toolhive"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.30.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-58197"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-18T17:16:02Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nA containerized MCP server running with the default `network` permission profile (`insecure_allow_all: true`) can reach host-local services via `host.docker.internal`. This includes the ToolHive API itself, other ToolHive-managed MCP server proxies, and any other service listening on the host\u0027s localhost. Combined with the unauthenticated ToolHive API and MCP proxy endpoints, this enables a compromised or malicious MCP server to perform lateral movement without any container escape.\n\n## Severity\n\n**High** \u2014 This bypasses the container isolation model that is ToolHive\u0027s core security value proposition.\n\n## Reproduction\n\nAll tests performed from inside the `filesystem` MCP container (`docker.io/mcp/filesystem:latest`), started with default settings via `thv run filesystem -- /tmp`.\n\n### 1. Container can reach the ToolHive control plane MCP endpoint\n\n```bash\n$ docker exec \u003ccontainer_id\u003e wget -qO- \\\n --header=\"Content-Type: application/json\" \\\n --header=\"Accept: application/json\" \\\n --post-data=\u0027{\"jsonrpc\":\"2.0\",\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{},\"clientInfo\":{\"name\":\"evil-mcp\",\"version\":\"1.0\"}},\"id\":1}\u0027 \\\n http://host.docker.internal:50444/mcp\n```\n\n**Result:** Full MCP handshake succeeds:\n```json\n{\"jsonrpc\":\"2.0\",\"id\":1,\"result\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{\"logging\":{},\"tools\":{}},\"serverInfo\":{\"name\":\"toolhive-mcp\",\"version\":\"v0.9.3\"}}}\n```\n\n### 2. Container can connect to another MCP server\u0027s proxy and call its tools\n\n```bash\n$ docker exec \u003ccontainer_id\u003e wget -qO- \\\n --header=\"Content-Type: application/json\" \\\n --header=\"Accept: application/json\" \\\n --post-data=\u0027{\"jsonrpc\":\"2.0\",\"method\":\"tools/list\",\"params\":{},\"id\":2}\u0027 \\\n http://host.docker.internal:64965/mcp\n```\n\n**Result:** Returns the full tool list of the target MCP server (read_file, write_file, edit_file, move_file, etc.), and tools can be called:\n\n```json\n{\"jsonrpc\":\"2.0\",\"id\":3,\"result\":{\"content\":[{\"text\":\"Allowed directories:\\n/tmp\",\"type\":\"text\"}]}}\n```\n\n### 3. Container can reach other host services\n\n```bash\n# Kubernetes API\n$ docker exec \u003ccontainer_id\u003e wget -qO- --no-check-certificate https://host.docker.internal:6443/version\n{\"major\":\"1\",\"minor\":\"34\",\"gitVersion\":\"v1.34.1\"...}\n\n# Ollama LLM API\n$ docker exec \u003ccontainer_id\u003e wget -qO- http://host.docker.internal:11434/api/tags\n{\"models\":[{\"name\":\"kimi-k2:1t-cloud\"...}]}\n```\n\n## Attack Scenarios\n\n### Scenario 1: Malicious MCP server pivots to privileged native MCP tools\n\nMany users run native (non-containerized) MCP servers like Desktop Commander, terminal servers, or custom tools that have `execute_command`, `write_file`, or `shell` capabilities with full host access. These typically listen on localhost ports. A malicious containerized MCP server can:\n\n1. Port-scan `host.docker.internal` to discover listening services\n2. Attempt MCP handshakes on discovered ports\n3. Call privileged tools (e.g., `execute_command(\"rm -rf /\")` or `write_file(\"/etc/crontab\", \"...\")`)\n\nThis achieves **full host compromise without any container escape vulnerability**.\n\n### Scenario 2: Compromised MCP server manipulates ToolHive itself\n\nVia the unauthenticated ToolHive MCP endpoint on port 50444, a compromised container could potentially:\n\n- List and stop other running MCP servers (denial of service)\n- Start new MCP servers with attacker-controlled images\n- Modify configurations\n\n### Scenario 3: Data exfiltration via cross-MCP-server access\n\nA low-privilege MCP server (e.g., `sequentialthinking` with no file mounts) could reach the `filesystem` server\u0027s proxy and call `read_file` to access files it was never authorized to see.\n\n### Scenario 4: LLM model theft / abuse\n\nAs demonstrated, the container can reach Ollama\u0027s API and could enumerate models, run inference, or exfiltrate model weights from self-hosted LLMs.\n\n## Root Causes\n\n1. **`insecure_allow_all: true` as default** \u2014 permits outbound connections to any destination including `host.docker.internal`\n2. **No authentication on ToolHive API / MCP proxies** \u2014 any client that can reach the port can interact fully\n3. **Docker\u0027s `host.docker.internal` DNS** \u2014 resolves to the host machine, bypassing localhost-only binding assumptions\n\n## Suggested Mitigations\n\n### Short-term\n\n- **Block `host.docker.internal` and `172.17.0.1`** (Docker gateway) in container networking by default, even when `insecure_allow_all` is enabled. These should require explicit opt-in.\n- **Add authentication to MCP proxy endpoints** \u2014 even a shared secret or token per session would prevent cross-container lateral movement.\n\n### Medium-term\n\n- **Network policy per container** \u2014 ToolHive already has the `permission_profile` infrastructure. Add support for explicit allow-lists rather than just the binary none/all choice.\n- **Isolate container networks** \u2014 run each MCP server in its own Docker network with no access to the Docker bridge gateway.\n\n### Long-term\n\n- **Mutual TLS or token-based auth** between ToolHive proxy and containers, so even if network access exists, unauthorized MCP calls are rejected.\n- **Audit logging** \u2014 log all MCP tool calls with source identification so lateral movement attempts are visible.\n\n## Environment\n\n- ToolHive v0.9.3 (macOS desktop app, Docker runtime)\n- Docker Desktop for Mac (host.docker.internal enabled by default)\n- Tested with `docker.io/mcp/filesystem:latest`",
"id": "GHSA-qg2g-g9w3-m5h8",
"modified": "2026-09-18T17:16:02Z",
"published": "2026-09-18T17:16:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive/security/advisories/GHSA-qg2g-g9w3-m5h8"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive-studio/pull/2469"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive/pull/5583"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive-studio/commit/968182d7f3ee1e55123369e66ad88f82128119b0"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive/commit/d8f40cb1599b8bf66657f2dfff15bfbfc236e712"
},
{
"type": "PACKAGE",
"url": "https://github.com/stacklok/toolhive"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive-studio/releases/tag/v0.38.0"
},
{
"type": "WEB",
"url": "https://github.com/stacklok/toolhive/releases/tag/v0.30.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "ToolHive: containerized MCP servers can reach host services via host.docker.internal, enabling lateral movement"
}
GHSA-QG57-QH29-MJXF
Vulnerability from github – Published: 2022-05-24 17:20 – Updated: 2022-05-24 17:20D-link DSL-2750U ISL2750UEME3.V1E devices allow approximately 90 seconds of access to the control panel, after a restart, before MAC address filtering rules become active.
{
"affected": [],
"aliases": [
"CVE-2020-13150"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-15T16:15:00Z",
"severity": "MODERATE"
},
"details": "D-link DSL-2750U ISL2750UEME3.V1E devices allow approximately 90 seconds of access to the control panel, after a restart, before MAC address filtering rules become active.",
"id": "GHSA-qg57-qh29-mjxf",
"modified": "2022-05-24T17:20:30Z",
"published": "2022-05-24T17:20:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13150"
},
{
"type": "WEB",
"url": "https://gist.github.com/idris159/4c3ea746f4b19308b8ce8d8a7e313310"
},
{
"type": "WEB",
"url": "https://www.dlink.com/en/security-bulletin"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-QG79-8FM6-F6QW
Vulnerability from github – Published: 2025-05-12 03:30 – Updated: 2025-05-12 06:30The specific APIs of Parking Management System from ZONG YU has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to access specific APIs and operate system functions. These functions include opening gates and restarting the system.
{
"affected": [],
"aliases": [
"CVE-2025-4557"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-12T03:15:17Z",
"severity": "CRITICAL"
},
"details": "The specific APIs of Parking Management System from ZONG YU has a Missing Authentication vulnerability, allowing unauthenticated remote attackers to access specific APIs and operate system functions. These functions include opening gates and restarting the system.",
"id": "GHSA-qg79-8fm6-f6qw",
"modified": "2025-05-12T06:30:32Z",
"published": "2025-05-12T03:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4557"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-10113-58c29-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-10112-5de7e-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/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:H/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-QG98-F7Q6-8623
Vulnerability from github – Published: 2024-11-25 12:33 – Updated: 2024-11-25 12:33Improper control of framework service permissions with possibility of some sensitive device information leakage.
{
"affected": [],
"aliases": [
"CVE-2020-12491"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-25T10:15:04Z",
"severity": "MODERATE"
},
"details": "Improper control of framework service permissions with possibility of some sensitive device information leakage.",
"id": "GHSA-qg98-f7q6-8623",
"modified": "2024-11-25T12:33:23Z",
"published": "2024-11-25T12:33:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12491"
},
{
"type": "WEB",
"url": "https://www.vivo.com/en/support/security-advisory-detail?id=11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:L/VI:N/VA:N/SC:L/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-QGV4-X6MV-VH78
Vulnerability from github – Published: 2024-08-22 15:31 – Updated: 2024-08-22 21:31Swissphone DiCal-RED 4009 devices allow a remote attacker to gain a root shell via TELNET without authentication.
{
"affected": [],
"aliases": [
"CVE-2024-36445"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-22T15:15:16Z",
"severity": "CRITICAL"
},
"details": "Swissphone DiCal-RED 4009 devices allow a remote attacker to gain a root shell via TELNET without authentication.",
"id": "GHSA-qgv4-x6mv-vh78",
"modified": "2024-08-22T21:31:29Z",
"published": "2024-08-22T15:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36445"
},
{
"type": "WEB",
"url": "https://www.swissphone.com/en-us/solutions/components/terminals/radio-data-module-dical-red"
},
{
"type": "WEB",
"url": "https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2024-035.txt"
}
],
"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-QH35-4QRQ-2527
Vulnerability from github – Published: 2024-10-10 03:30 – Updated: 2024-10-10 03:30The WP Users Masquerade plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.0.0. This is due to incorrect authentication and capability checking in the 'ajax_masq_login' function. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to log in as any existing user on the site, such as an administrator.
{
"affected": [],
"aliases": [
"CVE-2024-9522"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-10T02:15:06Z",
"severity": "HIGH"
},
"details": "The WP Users Masquerade plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.0.0. This is due to incorrect authentication and capability checking in the \u0027ajax_masq_login\u0027 function. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to log in as any existing user on the site, such as an administrator.",
"id": "GHSA-qh35-4qrq-2527",
"modified": "2024-10-10T03:30:46Z",
"published": "2024-10-10T03:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9522"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/wp-users-masquerade/trunk/masquerade.php?rev=1703860#L162"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/4a4f0909-76f6-4d27-87b1-f6cd5f5cbbb7?source=cve"
}
],
"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"
}
]
}
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.