T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:18- Finding
Unreviewed Remote Native Binary Downloaded and Executed Through an npm Dependency
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 18-44
Vulnerability Type: T03: Remote Payload Retrieval and Execution, T08: Insecure Dependencies
Risk Level: MediumVulnerable Code Snippet
yaml metadata: author: temporal-cortex version: "0.9.1" mcp-server: "@temporal-cortex/cortex-mcp" homepage: "https://temporal-cortex.com" repository: "https://github.com/temporal-cortex/skills" openclaw: install: - kind: node package: "@temporal-cortex/cortex-mcp@0.9.1" bins: [cortex-mcp] requires: bins: - npx config: - ~/.config/temporal-cortex/credentials.json - ~/.config/temporal-cortex/config.jsontext **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) 4. Calendar tools make authenticated API calls to your configured providers (Google Calendar API, Microsoft Graph API, CalDAV endpoints)Technical Analysis
The Skill does not contain the implementation of its MCP server. Instead, it directs the runtime to install an npm package whose postinstall lifecycle downloads a platform-specific native executable from a remote GitHub release. The resulting executable therefore lies outside the reviewed project artifact and can execute with the privileges of the user running the Skill.
Version
0.9.1is pinned in the installation metadata, which limits ordinary dependency drift. However, the documented authentication commands in `references/MULTI-CA ...[truncated 3295 chars]- Remediation
View remediation
Remediation Suggestions
-
Pin every documented invocation to the reviewed package version, for example:
bash npx @temporal-cortex/cortex-mcp@0.9.1 auth google -
Avoid downloading executable content during postinstall. Distribute a reviewed binary as an integrity-addressed package artifact, or build it locally from a pinned source commit.
-
Require signature verification or a hard-coded SHA-256 digest obtained through an independent trust channel. Do not rely solely on checksums embedded in the package that performs the download.
-
Publish provenance attestations, signed release metadata, and reproducible-build instructions that bind the source commit, npm package, and native binaries together.
-
Make verification mandatory before execution rather than presenting it only as an optional pre-run recommendation.
-
Prefer a digest-pinned container image and run it with:
- A read-only root filesystem
- No privileged mode
- Dropped Linux capabilities
- A narrowly scoped, read-only credential mount where feasible
- Explicit network allowlisting for required calendar providers
- No access to unrelated host files or sockets
-
Apply restrictive filesystem permissions to credential files and store refresh tokens in an operating-system credential manager where supported.
-
Disable npm lifecycle scripts during package inspection, review the package contents, and only permit the required installer after artifact verification.
-
Include the installer and relevant runtime source in the audited project or perform a separate security review of the exact npm package, native binary, and release workflow before deployment.
-
