T03 · Remote Payload Retrieval and Execution
Warning
- Location
- SKILL.md:105
- Finding
- Third-Party Postinstall Hook Downloads and Executes an External Native Binary## Vulnerability Details **File Location**: `SKILL.md`, lines 105–108 **Vulnerability Type**: Remote payload retrieval and execution through an npm installation lifecycle **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) ``` The corresponding installation configuration appears at `SKILL.md`, lines 16–18: ```yaml install: - kind: node package: "@temporal-cortex/cortex-mcp@0.9.1" bins: [cortex-mcp] ``` The Skill also directs users to invoke the package for credential setup at `SKILL.md`, line 159: ```text Layer 1 tools work immediately with zero configuration. 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 Installing the declared npm dependency runs package lifecycle code. According to the Skill documentation, its postinstall hook retrieves a platform-specific native executable from a GitHub Release. The retrieved executable is subsequently launched as a local MCP server. This creates a remote code-execution supply-chain boundary: the effective executable is not included in the audited project and can only be assessed by separately reviewing the npm package, postinstall script, checksum manifest, release artifact, and upstream source. None of those components were present in the supplied artifact. Version pinning to `0.9.1`, SHA2 ...[truncated 3117 chars]
- Remediation
- ## Remediation Suggestions 1. **Eliminate installation-time remote binary retrieval where practical.** Distribute the reviewed executable directly in a signed, immutable package, or require users to build it from a pinned source revision. 2. **Use cryptographic release signing.** Sign binaries and checksum manifests with a protected signing identity, and verify signatures before accepting downloaded artifacts. 3. **Publish verifiable provenance.** Provide SLSA-compatible build attestations linking each binary digest to the exact source commit and CI workflow that produced it. 4. **Strengthen dependency pinning.** Supply a lockfile or integrity metadata in addition to the semantic package version. Use immutable artifact digests for container-based distribution. 5. **Avoid unreviewed remote setup execution.** Include a pinned setup script in the Skill package for local inspection rather than relying only on a script reached through a remote repository link. 6. **Make verification fail closed.** Ensure the installer never executes a binary if the signature, digest, provenance, platform identification, or expected filename cannot be validated. 7. **Separate trust channels.** Publish signed checksums or trusted digest information through a channel whose compromise does not automatically imply compromise of the binary-hosting channel. 8. **Apply runtime containment.** Prefer a digest-pinned container with a non-root user, read-only root filesystem, dropped Linux capabilities, no host networking where unnecessary, and only the dedicated configuration directory mounted. 9. **Minimize credential exposure.** Restrict credential-file permissions to the owning user and request only the OAuth scopes needed for selected calendar operations. 10. **Document optional network behavior clearly.** Require explicit user consent before enabling Platform Mode or sending email addresses, slugs, or scheduling information to `api.temporal-cortex.com`.