T08 · Insecure Dependencies
Warning
- Location
- collect_briefing_data.py:44
- Finding
- Unpinned Third-Party CLI Package Is Retrieved and Executed## Vulnerability Details **File Location**: `collect_briefing_data.py:44-53`; related invocation guidance appears in `SKILL.md:41`, `SKILL.md:52`, `SKILL.md:269-272`, and `README.md:18` **Vulnerability Type**: T08: Insecure Dependencies **Risk Level**: Medium ### Vulnerable Code ```python def run_fulcra_json(*args: str) -> Any: command = os.environ.get("FULCRA_CLI_COMMAND", "uv tool run fulcra-api").split() result = subprocess.run( [*command, *args], capture_output=True, text=True, timeout=60, check=False, ) if result.returncode != 0: message = (result.stderr or result.stdout or "Fulcra CLI command failed").strip() raise RuntimeError(message) return parse_json_output(result.stdout) ``` Related documented commands include: ```bash uv tool run fulcra-api auth login ``` ```bash uv tool run fulcra-api --help uv tool run fulcra-api auth login --help uv tool run fulcra-api data-updates "14 hours" uv tool run fulcra-api calendar-events --help ``` ### Technical Analysis The default command uses `uv tool run fulcra-api` without an exact package version, lockfile, or integrity verification. Depending on the local `uv` cache and resolution behavior, this can retrieve and execute the currently available package release when the collector or authentication flow runs. The Skill legitimately needs a Fulcra client, but resolving a mutable package at execution time is not the minimum-risk way to provide that dependency. Authentication and all sensitive data queries consequently depend on package contents that can change after the Skill itself has been reviewed. This is a supply-chain weakness rather than evidence that the current Fulcra package is malicious. The audited project contains no embedded malicious payload and does not itself read `~/.config/fulcra/credentials.json`. Nevertheless, code executed as part of the CLI runs wi ...[truncated 1365 chars]
- Remediation
- ## Remediation Suggestions 1. Pin `fulcra-api` to a reviewed exact version rather than resolving an unconstrained release: ```bash uv tool run fulcra-api==REVIEWED_VERSION ``` 2. Prefer installing the dependency once in a dedicated virtual environment and invoking its fixed executable path. 3. Commit a lockfile with cryptographic hashes when the packaging workflow supports it. 4. Verify package provenance, publisher identity, and release signatures or hashes before upgrades. 5. Test and review each dependency update before changing the pinned version. 6. Run the collector as an unprivileged, dedicated user with access only to the data and directories required for the briefing. 7. Document the supported version so authentication and data-query behavior cannot silently change between runs.