T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:52- Finding
Installation Executes a Remotely Retrieved, Externally Maintained Binary
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 52-53
Vulnerability Type: Remote payload retrieval through an npm lifecycle script and third-party supply chain
Risk Level: Hightext 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**The associated package declaration appears at
SKILL.md, lines 17-20:yaml install: - kind: node package: "@temporal-cortex/cortex-mcp@0.9.1" bins: [cortex-mcp]An alternative installation method at
SKILL.md, line 95 also builds from a remote, unpinned Git repository reference:bash docker build -t cortex-mcp https://github.com/temporal-cortex/mcp.gitTechnical Analysis
The audited project does not contain the MCP server implementation or the installer responsible for retrieving its executable. Installation resolves an npm package and permits its
postinstalllifecycle script to download a platform-specific binary from GitHub. Consequently, the code ultimately executed is outside the reviewed project and cannot be validated from the supplied files.Pinning the npm package to version
0.9.1reduces accidental version drift but does not eliminate supply-chain risk. The documented embeddedchecksums.jsoncheck establishes artifact integrity only relative to a checksum delivered through the same package or release process. If an attacker compromises the relevant npm publisher, release workflow, repository, or both the binary and its expected checksum, the check may still succeed.The suggested independent
SHA256SUMS.txtverification provides useful defense in depth, but the checksum is also retrie ...[truncated 2755 chars]- Remediation
View remediation
Remediation Suggestions
- Vendor the reviewed MCP source or reviewed platform binaries into a controlled release process so that the executable being run is directly associated with the audited Skill version.
- Avoid automatic network retrieval from npm lifecycle scripts. Install dependencies with lifecycle scripts disabled where feasible, then retrieve and verify the required executable through an explicit, separately reviewed process.
- Publish cryptographically signed checksums or provenance attestations and verify them with a trusted public key distributed independently from npm and GitHub release artifacts.
- Pin the Docker build to an immutable Git commit and, where possible, use a base image and resulting image identified by cryptographic digests rather than mutable tags or repository tips.
- Require reproducible builds and compare locally produced binaries with published artifacts.
- Run installation as an unprivileged user in an isolated environment with access limited to required directories. Do not use
sudofor npm installation. - Enforce runtime containment using a read-only filesystem, no host volume mounts, dropped Linux capabilities, a non-root container user, resource limits, and
--network=none. - Document the exact expected binary hashes for every supported platform in an immutable, reviewed Skill release, while still retaining signature verification.
- Audit the external Rust source, npm installer, lifecycle scripts, release workflow, and Dockerfile before approving the dependency, because those components were absent from this audit artifact.
