T08 · Insecure Dependencies
- Location
SKILL.md:7- Finding
Unpinned Remote Package Resolution and Execution
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:7-12,README.md:7-13, andpyproject.toml:1-3
Vulnerability Type: Software supply-chain risk caused by unpinned remote packages
Risk Level: MediumVulnerable Code
SKILL.md:7-12:bash ## Usetext uvx rtc-work jobs # list open jobs uvx rtc-work watch --skills code,research # poll for matches uvx rtc-work claim <job_id> # reserve a job uvx rtc-work deliver <job_id> --summary "done"README.md:7-13:bash uvx rtc-work jobs # list open jobs uvx rtc-work watch --skills code,research # poll for matches (report-only) uvx rtc-work claim <job_id> # reserve a job uvx rtc-work deliver <job_id> --url https://… --summary "done" uvx rtc-work rep # your on-chain reputationpyproject.toml:1-3:toml [build-system] requires = ["setuptools>=61"] build-backend = "setuptools.build_meta"Technical Analysis
The documented
uvx rtc-workcommands resolve and execute a package from the configured Python package index without specifying an exact version or verifying a package hash. This means that the code executed by users can differ from the source reviewed in this audit.The build-system dependency also specifies only a minimum version of
setuptools, with no upper bound, lock file, or integrity hash. During an isolated build, a later compatible release may therefore be downloaded and executed as part of the build process.This is not evidence that the currently reviewed package contains malicious code. It is a supply-chain weakness: trust is transferred to future package releases, package-index accounts, index configuration, and dependency resolution performed at execution or build time.
Attack Path
- An attacker compromises the publishing account for
rtc-work, com ...[truncated 1118 chars]
- An attacker compromises the publishing account for
- Remediation
View remediation
Remediation Suggestions
- Pin the application version in all execution examples, such as
uvx rtc-work==0.1.1 .... - Prefer installation or execution from a reviewed, versioned release artifact rather than an implicitly selected latest release.
- Publish and verify cryptographic hashes or signed provenance for release artifacts.
- Pin build dependencies to reviewed versions and maintain them through a controlled update process.
- Use a lock file or constraints file with hashes in reproducible build and release workflows.
- Configure CI to build in a restricted environment and verify that resolved package versions match the approved dependency set.
- Document the expected package index and warn users against untrusted index overrides.
- Pin the application version in all execution examples, such as
