T08 · Insecure Dependencies
- Location
references/runtime.md:28- Finding
Externally Hosted Runtime Executes Code Outside the Audited Package
- Content
View full analysis
Vulnerability Details
File Location:
references/runtime.md:28-52
Vulnerability Type: Externally sourced executable dependency
Risk Level: MediumThe skill is documentation-only and directs the agent to clone and execute a separately hosted Python runtime that was not included in the audited artifact.
bash git clone --depth 1 --branch openclaw-v0.1.6 \ https://github.com/bzSega/financial-experts-said.git "$FES_ROOT"bash # must output exactly: openclaw-v0.1.6 git -C "$FES_ROOT" describe --exact-match --tags HEAD # must equal the pinned SHA from the table above if [ "$(git -C "$FES_ROOT" rev-parse HEAD)" != "419cafe0a833d470867d3bd0e1c77773c6ff1095" ]; then echo "pin mismatch" >&2 exit 1 fibash python3 "$FES_ROOT/pipeline/init_db.py" --db "$FES_WORKSPACE/fti.db" python3 "$FES_ROOT/pipeline/seed_demo.py" --db "$FES_WORKSPACE/fti.db" # demo dataTechnical Analysis
The package delegates its core functionality to executable files obtained from an external GitHub repository. Those files are outside this artifact and therefore could not be examined during this audit. Running them gives the external runtime the same operating-system privileges and data access as the invoking agent or user.
The exact Git tag and commit verification significantly reduce the risk of silently receiving a different revision. Consequently, this is best categorized as an insecure external dependency boundary rather than an unpinned remote-payload mechanism. However, hash pinning verifies identity, not safety: it does not establish that the pinned Python code is benign.
The affected runtime includes database initialization and demo-data scripts, while other project instructions also direct the agent to invoke ingestion, synchronization, search, and chart scripts from the same external runtime.
Attack Path
- A user asks the agent to set up or use the skill.
- The agent f ...[truncated 1392 chars]
- Remediation
View remediation
Remediation Suggestions
- Include the complete reviewed runtime source in the distributed package so that the instructions and executable implementation can be audited together.
- Alternatively, publish a signed, immutable release archive and verify both its cryptographic signature and a documented SHA-256 digest before extraction or execution.
- Retain the exact commit verification, but treat it as an integrity control rather than proof that the runtime is safe.
- Subject the pinned runtime commit to a separate code audit covering file access, subprocess execution, network behavior, SQLite handling, HTML generation, and source-text processing.
- Require explicit user approval before cloning the runtime and separate approval before its first execution.
- Execute the runtime with least privilege, restricted filesystem access, and outbound network controls appropriate to the selected operation.
- Document the files, network endpoints, and subprocesses each runtime command is expected to access so unexpected behavior can be blocked or detected.
