Back to skill

Security audit

Quantum Lab Runner

Security checks for vulnerabilities and agentic risk

Overview

This skill is a small Quantum Lab runner, but its helper can run arbitrary local commands and install dependencies from a configurable external repo path.

Review and trust the configured quantum_lab repository and qiskit virtual environment before installing. Use this only where arbitrary local command execution is acceptable, and prefer fixed, reviewed commands plus pinned dependency files instead of allowing free-form qexec usage.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
Findings (3)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
scripts/qexec.sh:17
Finding
Unrestricted Command Execution Through the Quantum Lab Helper## Vulnerability Details **File Location**: `scripts/qexec.sh`, lines 17-28 **Vulnerability Type**: Unrestricted command execution **Risk Level**: High ### Vulnerable Code ```bash if [[ $# -eq 0 ]]; then echo "Usage: qexec <command> [args...]" >&2 echo "Example: qexec python quantum_app.py self-tests" >&2 exit 2 fi # shellcheck disable=SC1090 source "$VENV/bin/activate" cd "$ROOT" exec "$@" ``` ### Technical Analysis The helper is presented as a runner for approved Quantum Lab Python scripts, but it passes all supplied arguments directly to `exec` without validating the executable or its arguments. Consequently, it is not restricted to Python, the documented project scripts, or the documented subcommands. The use of `"$@"` correctly preserves argument boundaries and prevents ordinary shell metacharacter expansion at this point. However, it does not prevent a caller from directly selecting an unrestricted executable such as a shell, network utility, file-management utility, or another locally installed program. ### Attack Path 1. An attacker or untrusted user supplies a request that causes the Agent to invoke `qexec.sh`. 2. The request specifies an executable and arguments outside the documented Quantum Lab command set. 3. The helper activates the configured virtual environment and changes into the repository. 4. `exec "$@"` starts the attacker-selected executable with the Agent process's privileges. 5. The selected program can read, modify, or transmit resources available to that operating-system account. ### Impact Assessment Successful exploitation provides general command execution under the identity and permissions of the Agent process. The attacker could access files readable by that account, modify writable project or user files, invoke local network clients, or run additional programs. The script does not itself elevate to root, so the maximum scope remains bounded by ...[truncated 65 chars]
Remediation
## Remediation Suggestions Replace unrestricted `exec "$@"` behavior with an explicit allowlist of supported operations. Map fixed subcommand names to fixed scripts rather than accepting arbitrary executable names. Recommended controls include: - Permit only the documented Python entry points and recognized subcommands. - Invoke the virtual environment's Python interpreter by an approved canonical path. - Reject absolute executable paths, path traversal, shell interpreters, and undocumented programs. - Validate notebook paths after canonicalization and require them to remain inside the repository. - Add `--` where supported to prevent user-controlled values from being interpreted as options. - Run the helper in a sandbox with minimal filesystem and network permissions. - Log the selected approved operation without recording sensitive arguments.

T09 · Insecure Skill Coding Practices

Error
Location
scripts/qexec.sh:4
Finding
Attacker-Selectable Activation File Is Executed as Shell Code## Vulnerability Details **File Location**: `scripts/qexec.sh`, lines 4-24 **Vulnerability Type**: Unsafe sourcing of a configurable shell file **Risk Level**: High ### Vulnerable Code ```bash ROOT="${QUANTUM_LAB_ROOT:-$HOME/work/quantum_lab}" VENV="${VENV_PATH:-$HOME/.venvs/qiskit}" if [[ ! -d "$VENV" ]]; then echo "Venv not found: $VENV" >&2 echo "Set VENV_PATH or create the venv first." >&2 exit 1 fi if [[ ! -d "$ROOT" ]]; then echo "Repo not found: $ROOT" >&2 exit 1 fi if [[ $# -eq 0 ]]; then echo "Usage: qexec <command> [args...]" >&2 echo "Example: qexec python quantum_app.py self-tests" >&2 exit 2 fi # shellcheck disable=SC1090 source "$VENV/bin/activate" ``` ### Technical Analysis `VENV_PATH` is accepted from the process environment and used to construct the path of a file loaded with Bash's `source` command. Sourcing a file executes its contents in the current shell process; it is not merely a configuration-file read. The implementation verifies only that the selected virtual-environment directory exists. It does not canonicalize the path, restrict it to an approved directory, confirm the ownership or permissions of `bin/activate`, or verify the file's integrity. Therefore, an attacker who can set `VENV_PATH` and create files at the selected location can execute arbitrary shell statements before the requested command begins. ### Attack Path 1. The attacker creates a directory containing a malicious `bin/activate` file. 2. The attacker arranges for `VENV_PATH` to reference that directory, such as through a controllable Agent environment or invocation configuration. 3. The helper confirms only that the directory exists. 4. `source "$VENV/bin/activate"` executes the malicious file in the helper's shell. 5. The payload runs with the Agent process's permissions and can also alter environment variables or shell state before the ...[truncated 580 chars]
Remediation
## Remediation Suggestions Avoid sourcing an activation script. Invoke the intended interpreter directly, for example through a pinned canonical path under a trusted virtual environment. If configurability is required: - Canonicalize the configured path with a reliable path-resolution mechanism. - Require the resulting path to be inside an administrator-approved parent directory. - Verify that the environment directory and activation file are owned by the expected account. - Reject activation files or parent directories writable by untrusted users. - Verify the activation file against an approved digest where practical. - Clear or tightly control `VENV_PATH` when the helper is launched across a trust boundary. - Prefer a fixed configuration file protected by filesystem permissions over an inherited environment variable.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:41
Finding
Dependency Installation Is Recommended From an Unverified Configurable Repository## Vulnerability Details **File Location**: `SKILL.md`, line 41 **Vulnerability Type**: Unverified third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```markdown - If dependencies are missing: `bash <SKILL_DIR>/scripts/qexec.sh pip install -r requirements.txt`. ``` Related configurable repository selection in `scripts/qexec.sh`, line 4: ```bash ROOT="${QUANTUM_LAB_ROOT:-$HOME/work/quantum_lab}" ``` ### Technical Analysis The skill recommends running `pip install` against `requirements.txt` from the current Quantum Lab repository. That repository is external to the audited skill package and can be redirected through `QUANTUM_LAB_ROOT`. The audited project does not contain the referenced requirements file, so package names, versions, hashes, indexes, source archives, and build behavior cannot be verified from this artifact. Python dependency installation can execute package build backends or installation logic. If the configurable repository or its requirements file is replaced or compromised, following this instruction could install malicious, substituted, or unexpectedly updated packages. ### Attack Path 1. An attacker compromises the configured Quantum Lab repository or prepares another repository containing a malicious `requirements.txt`. 2. The attacker causes `QUANTUM_LAB_ROOT` to select that repository, or modifies the requirements file at the normal repository path. 3. Dependencies appear to be missing, prompting use of the documented installation command. 4. `qexec.sh` changes into the selected repository. 5. `pip install -r requirements.txt` resolves and installs the attacker-selected dependencies. 6. Malicious package installation or build behavior executes with the invoking account's permissions, or malicious code remains in the virtual environment for later execution. ### Impact Assessment The immediate impact can include arbitrary code execution during package ...[truncated 312 chars]
Remediation
## Remediation Suggestions - Maintain a reviewed, version-pinned dependency lock file under trusted source control. - Require cryptographic hashes for downloaded artifacts, such as with pip's `--require-hashes`. - Restrict package resolution to approved indexes and explicitly configured trusted repositories. - Do not install dependencies from an arbitrary path selected by `QUANTUM_LAB_ROOT`. - Review transitive dependencies and package build requirements. - Prefer prebuilt, verified environments or immutable container images. - Perform installation in an isolated, minimally privileged environment without unnecessary credentials or network access.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.