T08 · Insecure Dependencies
- Location
SKILL.md:13- Finding
Unpinned and Unspecified Runtime Dependencies
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 13 and 76-79
Vulnerability Type: Supply-chain risk caused by unpinned third-party dependencies
Risk Level: MediumVulnerable Snippets
SKILL.md:13:markdown 1. Install `@tyrpay/seller-skill`, `@tyrpay/seller-sdk`, a storage adapter, and a zkTLS adapter.SKILL.md:76-79:markdown - `ReclaimZkTlsAdapter` needs `@reclaimprotocol/zk-fetch`, `@reclaimprotocol/js-sdk`, credentials, and downloaded zk resources. Install those optional peer dependencies in the runtime that constructs the adapter. Windows runtimes must keep Reclaim TEE mode disabled.Technical Analysis
The installation instructions require executable third-party packages without specifying exact versions, integrity hashes, a lockfile, or a verification procedure. The storage and zkTLS adapter package names are also not fully specified. Consequently, installations performed at different times can resolve to different code, and users may inadvertently select an untrusted or similarly named adapter.
Because these dependencies execute inside the seller runtime, they may inherit access to sensitive application state, including the seller signer, wallet credentials, storage credentials, Reclaim credentials, model API keys, proof material, and blockchain transaction capabilities. The audited artifact contains only documentation and metadata, so the implementation and security properties of the instructed dependencies could not be verified from this package.
Attack Path
- An attacker compromises a referenced package release, publishes a malicious future version, or distributes a similarly named storage or zkTLS adapter.
- A user follows the documented installation instructions without version or integrity constraints.
- The package manager resolves and installs the attacker-controlled dependency.
- Malicious installation or runtime code executes within ...[truncated 918 chars]
- Remediation
View remediation
Remediation Suggestions
- Specify the exact audited package name and version for every SDK, storage adapter, zkTLS adapter, and optional peer dependency.
- Publish and maintain a lockfile that records the complete transitive dependency graph.
- Enforce package integrity through registry checksums, signed provenance, or verified release artifacts.
- Document the trusted package registry and explicitly reject similarly named or unofficial adapters.
- Review package lifecycle scripts before installation and disable them during initial assessment where operationally possible.
- Run dependency vulnerability and provenance scanning in CI, including checks for lockfile changes and newly introduced maintainers or packages.
- Audit each adapter before production deployment, particularly code that can access signers, credentials, proof data, network requests, or transaction submission.
- Isolate third-party adapters using least-privilege processes or containers, and provide only the credentials and network access required for their specific function.
- Rotate wallet, storage, Reclaim, and model-provider credentials if an unverified dependency has already been executed in a privileged seller runtime.
