T03 · Remote Payload Retrieval and Execution
Warning
- Location
- SKILL.md:109
- Finding
- Externally Retrieved Executable and Mutable Installation Sources## Vulnerability Details **File Location**: `SKILL.md:109-112`, `SKILL.md:154`, and `SKILL.md:158` **Vulnerability Type**: Remote executable retrieval and insecure supply-chain configuration **Risk Level**: Medium ### Vulnerable Code ```text **Install and startup lifecycle:** 1. `npx` resolves `@temporal-cortex/cortex-mcp` from the npm registry (one-time, cached locally after first download) 2. The postinstall script downloads the platform-specific binary from the [GitHub Release](https://github.com/temporal-cortex/mcp/releases/tag/mcp-v0.9.1) and verifies its SHA256 checksum against the embedded `checksums.json` — **installation halts on mismatch** 3. The MCP server starts as a local process communicating over stdio (no listening ports) ``` ```bash Build: `docker build -t cortex-mcp https://github.com/temporal-cortex/mcp.git` ``` ```text Calendar tools require a one-time OAuth setup — run the [setup script](https://github.com/temporal-cortex/skills/blob/main/scripts/setup.sh) or `npx @temporal-cortex/cortex-mcp auth google`. ``` ### Technical Analysis The documented installation process executes an npm package lifecycle hook that downloads and subsequently runs a compiled executable from an external GitHub Release. The downloaded binary, npm postinstall implementation, setup script, and corresponding source are not included in the audited artifact, so their behavior cannot be independently verified through this audit. Although the documentation states that SHA256 verification is performed, the embedded checksum and executable are distributed through infrastructure controlled by the same publisher. A checksum protects against accidental corruption or an inconsistent download, but it does not establish an independent trust boundary if an attacker can replace both the executable and its expected checksum. The Docker build command retrieves the repository's default revision without pinning an immutable commit. The set ...[truncated 2600 chars]
- Remediation
- ## Remediation Suggestions 1. Pin every remotely retrieved source to an immutable commit or content digest. Replace default-branch Docker builds and `main`-branch setup references with reviewed commit hashes. 2. Publish signed release artifacts and verify signatures before execution. Keep verification keys or trusted identity policy separate from the release assets. 3. Publish checksums through an independently controlled, authenticated channel rather than relying solely on checksum data embedded in the npm package or colocated with the release. 4. Pin npm package integrity in a lockfile and document installation using deterministic package-manager behavior. 5. Allow users to install without lifecycle scripts, inspect the unpacked package and postinstall logic, verify the binary, and only then execute it. 6. Provide reproducible-build instructions and provenance attestations so users can confirm that release binaries correspond to a specific audited source commit. 7. Prefer a prebuilt container pinned by an immutable image digest. Run it with the configuration directory as the only required mount, a non-root user, a read-only root filesystem, dropped Linux capabilities, and network allowlisting for configured providers. 8. Restrict OAuth scopes to the minimum needed for requested operations and protect credential files with owner-only filesystem permissions. 9. Separate credential-free datetime functionality from credential-bearing calendar functionality so the former does not require installing or running a component with access to OAuth tokens.