T03 · Remote Payload Retrieval and Execution
Error
- Location
- SKILL.md:30
- Finding
- Unpinned Remote Application Is Automatically Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 30–36 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Vulnerable Code ```markdown ## Step 1 — Fork and deploy to Railway 1. Fork `plagtech/spraay-shopify` (Node 20+ required if running outside Docker: `>=20.19 <22 || >=22.12`). 2. Easiest path: the **Deploy on Railway** button in the README — the template pre-prompts for every required env var, with PORT defaulted to 3000. Manual path: Railway → New Project → Deploy from GitHub repo → select the fork; the repo ships a `railway.json` and Dockerfile, so the build is automatic. 3. Generate a public domain for the service (Settings → Networking). Note the URL, e.g. `your-app.up.railway.app`. The app will crash-loop until env vars are set — that's expected. Continue. ``` The subsequent deployment instructions also state that remote application commands run automatically: ```markdown Migrations run automatically on boot (`prisma generate && prisma migrate deploy`, then `remix-serve`). ``` ### Technical Analysis The skill directs users to fork, build, and execute code from the mutable external repository `plagtech/spraay-shopify`. It does not pin the repository to an audited commit SHA, signed release, or immutable container digest. The audited project contains no copy of the referenced source code, Dockerfile, Railway configuration, package lockfile, or smart-contract implementation. As a result, the effective executable payload may change after this skill has been reviewed. Railway automatically builds the remote Dockerfile and runs its startup commands. After environment variables are configured, that application receives access to sensitive deployment data, including the Shopify client secret and PostgreSQL connection strings. This is best classified as remote payload retrieval and execution rather than a confirmed malicious dependency: no malicious package was identified, but the instructions ...[truncated 2079 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Pin the deployment source to a fully reviewed Git commit SHA rather than a mutable branch: ```text https://github.com/plagtech/spraay-shopify/tree/<audited-commit-sha> ``` 2. Prefer an immutable container image identified by a verified digest, such as `image@sha256:...`, instead of building the latest remote Dockerfile. 3. Vendor the reviewed application source, deployment configuration, and package lockfile into the audited package when licensing and distribution constraints permit. 4. Require verification of signed commits or releases and publish expected checksums for all deployable artifacts. 5. Audit the referenced `Dockerfile`, `railway.json`, package scripts, lockfile, Prisma migration scripts, OAuth implementation, wallet transaction construction, and network request destinations before production deployment. 6. Pin third-party dependencies through a committed lockfile and use reproducible installation commands such as `npm ci`. 7. Review and verify the deployed smart contract's source code, runtime bytecode, fee recipient, authorization behavior, and chain address independently before processing real funds. 8. Initially deploy with test or minimally privileged credentials. Use a dedicated database role limited to the required `shopify` schema instead of a broadly privileged database account. 9. Test the complete transaction flow on a test network or with negligible-value transactions before approving production payouts. 10. Apply outbound network restrictions and secret-access controls where supported, and rotate Shopify and database credentials immediately if an unverified revision has already been deployed. ]]>