MCP Server Unified Gateway (self-hosted)

The scope of the review, recorded as it stands: the delivered tree holds 682 files, reviewing every one of them was not feasible, so the approach was pattern scanning plus review of the paths that matter. Pattern scanning (src/ and frontend/src/): zero hits for eval( and new Function(; child_process appears in exactly one place, src/utils/cacheUtils.ts, where execFile runs a fixed command (npm/uv cache cleanup) with a timeout and no user input concatenated into it. Paths reviewed in detail: entrypoint.sh (npm registry / proxy settings and automatic dockerd startup — the latter only fires when docker is installed in the image, and the default image does not have it), the Dockerfile, src/config/ (the configuration loading paths) and src/routes/index.ts (route mounting and the authentication middleware). MCP servers are started as child processes by @modelcontextprotocol/sdk according to mcp_settings.json, which is what this product is designed to do, and that configuration file is under the buyer's control. In runtime testing (a local container) no anomalous behaviour was observed outside the endpoints gated by the features described above, but no packet-level egress monitoring was done, which is recorded as it stands.

Every executable script was looked at one by one: entrypoint.sh (described above), scripts/quickstart/init-env.sh (written by us, generating a random password from openssl/urandom, idempotent), and the rest of scripts/, which are upstream's development helpers and do not reach the buyer's path. The build-time fetching in the Dockerfile means that images built from the same commit on different days are not the same bytes — the same shape as the apt-get precedent on dsp-021, and it is the face a periodic health check exists to catch, not a sign that the script itself is unsafe.

Checked at the time of vetting (2026) with gh api: the upstream repository was not archived, the delivery base bfd153c3 was the main HEAD on the day of that check, and the iteration rhythm was several commits a day. The product repository is frozen at that upstream commit plus our own work, and does not follow upstream.

SPDX:LicenseRef-99LL-Product

Two layers of licence, both inside the delivered tree: (1) upstream samanhappy/mcphub is Apache-2.0 — gh api returns spdx_id=Apache-2.0, and the LICENSE at the root of the repository is word for word the full text of the Apache License 2.0 (checked at the proposal stage and re-checked inside the delivered tree, both in 2026), permitting commercial use, modification, redistribution and use in proprietary work, with the obligations being to keep the licence notice and to mark modifications; upstream's LICENSE is kept at the root of the delivered tree as it stands, with not one word altered. (2) On our side LICENSE-99LL was produced from the 99LL product licence template as the sale and liability terms for the product as a whole (this is a derivative of an open source upstream, so the template is additional terms and does not override upstream's licence), with spdx expressed as LicenseRef-99LL-Product.

Back-end production dependencies: actually scanned inside the delivered image at /app with license-checker --production (2026), and all 95 packages are permissive — MIT 82, Apache-2.0 7, BSD-3-Clause 2 (bcryptjs, tough-cookie), BSD-2-Clause 2 (dotenv, dotenv-expand), ISC 1, Unlicense 1 (the postgres driver, public domain), with zero GPL/AGPL/LGPL. The front-end dependencies are build-time devDependencies, only the static files produced by vite build are delivered with the image, and they were not scanned package by package, which is recorded as it stands.