T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:50- Finding
Execution of an Unpinned Mutable Remote Installer
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent, but it should be reviewed because it presents an unverified remote installer command that can execute mutable code on the user's machine.
Review the installer workflow before installing. Prefer a versioned or signed package, or at least download and inspect the complete installer before running it. For normal Fabric use, confirm the active workspace before writes, avoid uploading credential or secret-bearing files, and only save persistent memory when you want that information stored remotely.
SKILL.md:50Execution of an Unpinned Mutable Remote Installer
The description presents a general-purpose Fabric.so CLI skill with many operational capabilities, including installing the CLI, logging in, saving content, creating folders, using the AI assistant, and managing tasks/workspaces. The supplied code does not implement those workflows. Its primary purpose is much narrower: a read-only diagnostic utility that checks for the presence of the fabric executable, runs local help/version commands, optionally runs read-only JSON account/workspace/task/subscription checks, and emits a report. Although diagnostics, JSON output, and subscription/workspace checks are mentioned in the description, the overall declared scope substantially overstates what the code can do. This is a material description-behavior mismatch.
The declared description portrays a full-featured Fabric.so CLI operational skill. The supplied code chunk only invokes fabric --help, fabric help <command>, or <command> --help for a predefined or user-specified list of commands, then formats the captured help output with secret redaction and truncation. This is materially narrower than the declared purpose. While the script is related to the Fabric.so CLI domain, its actual function is documentation/help introspection, not executing the advertised workflows. Therefore the description does not accurately represent this code chunk's actual behavior.
The description claims a general-purpose Fabric.so CLI workflow skill with many operational capabilities around the fabric command. The supplied code is much narrower: it only formats and redacts a note payload for potential later use with Fabric persistence, and explicitly states that it does not call the Fabric CLI. While the code aligns with one small slice of the declared description—preparing content for persistent agent memory and optionally producing JSON—it omits nearly all other claimed behaviors and has a materially narrower primary purpose. Therefore the description does not accurately represent what this code chunk actually does.
The declared description presents a broad operational integration with the Fabric.so CLI itself (fabric command workflows such as install/login/search/save/tasks/AI assistant/etc.). The actual code does not invoke or manage the Fabric CLI at all. Instead, it is an authoring/helper validator for a skill package, focused on local file inspection and package QA. While it is related to the Fabric CLI skill ecosystem, its primary purpose is materially different from the declared end-user workflow capabilities. The optional subprocess call to run local Python scripts with --help is also a packaging-validation behavior not reflected in the description.
The skill embeds a curl ... | sh installer pattern that downloads and immediately executes remote code. Even though the surrounding text advises only using it with explicit user approval and suggests safer review first, including a one-line remote execution command in an agent skill materially increases the risk of supply-chain compromise, MITM/TLS-termination abuse, or accidental execution of unreviewed code.
Never run the remote installer unless the user explicitly asked to install Fabric CLI in the current environment. The official installer is:
curl -fsSL https://fabric.so/cli/install.sh | sh
For safer review, download the script to a temporary file, inspect it, then run only with approval.
Piping network output directly into sh is a classic chaining-abuse pattern because it collapses fetch, trust, and execution into one step with no inspection boundary. In an agent context, this is especially risky: a model or operator can accidentally run destructive installer logic, and any compromise of the remote endpoint or script distribution path leads directly to arbitrary command execution.
Never run the remote installer unless the user explicitly asked to install Fabric CLI in the current environment. The official installer is:
curl -fsSL https://fabric.so/cli/install.sh | sh
For safer review, download the script to a temporary file, inspect it, then run only with approval.
The reference includes a classic curl | sh installer pattern that executes remote content directly without prior verification. Even though the surrounding text warns not to run it automatically and provides a safer review-first workflow, an agent or user could still copy the one-liner and execute attacker-controlled or compromised server content immediately.
Official installer:
curl -fsSL https://fabric.so/cli/install.sh | sh
Do not run this automatically unless the user explicitly requested installation in the current environment. For a safer workflow:
The | sh pipe creates a command chain that turns downloaded network data directly into shell execution, eliminating a review boundary and making compromise of the upstream host, transport, or content highly dangerous. In an agent skill context, documenting this exact pattern increases the chance that automation reproduces it unsafely.
Official installer:
curl -fsSL https://fabric.so/cli/install.sh | sh
Do not run this automatically unless the user explicitly requested installation in the current environment. For a safer workflow:
The script recommends curl ... | sh, which streams and executes remote code without integrity verification or review. If the remote server, network path, or installer is compromised, a user following this recommendation could immediately execute arbitrary code on their system.
if fab_path:
report.summary.append("A `fab` executable was found. That is commonly Microsoft Fabric CLI, not Fabric.so CLI.")
report.recommendations.append("Use the Fabric.so CLI executable named `fabric`; do not substitute `fab`.")
report.recommendations.append("Install only with user approval: curl -fsSL https://fabric.so/cli/install.sh | sh")
report.recommendations.append("After installation, restart the shell or update PATH, then rerun this checker.")
return report
Without declared permissions the skill's intent is opaque and cannot be validated.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Did the agent choose Fabric.so rather than the wrong Fabric?
- Did it avoid undocumented syntax unless live help supported it?
- Did it avoid running the installer without consent?
- Did it handle task IDs safely?
- Did it use stdin for long generated notes?
- Did it report workspace and limitations clearly?
The trigger set relies heavily on generic uses of the word 'Fabric' and a small number of negative examples, which may not sufficiently disambiguate Fabric.so CLI from closely related products and homonyms in real user prompts. This can cause the skill to activate on the wrong domain or miss important exclusions, leading to unintended command execution paths or mishandling of user requests in adjacent ecosystems like Microsoft Fabric or other 'fabric' tools.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
Non-interactive environments may need `fabric auth "$FABRIC_API_KEY"`.
Rules: do not ask the user to paste API keys into ordinary chat unless there is no safer route; prefer environment variables, secret stores, or interactive login; never echo a key; never save keys to Fabric memory; redact tokens in command output before summarising.
## Shell quoting and command history
This workflow instructs the agent to upload local files, notes, and URLs into Fabric and even suggests piping long text from a temp file, but it does not explicitly warn that local content will be transmitted to an external service and persisted there. In an agent setting, that omission can cause accidental exfiltration of sensitive local data, especially when users ask to 'save' or 'upload' content without realizing the privacy and persistence implications.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def run_command(name: str, command: Sequence[str], timeout: float, max_output: int) -> CommandResult:
started = time.monotonic()
try:
proc = subprocess.run(list(command), text=True, capture_output=True, timeout=timeout, check=False)
elapsed = int((time.monotonic() - started) * 1000)
return CommandResult(
name=name,
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
def run(cmd: Sequence[str], timeout: float) -> subprocess.CompletedProcess[str] | None:
try:
return subprocess.run(list(cmd), text=True, capture_output=True, timeout=timeout, check=False)
except (subprocess.TimeoutExpired, OSError):
return None
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
add(results, os.access(script, os.X_OK), f"script executable bit set: {script.relative_to(root)}")
if run_script_help:
try:
proc = subprocess.run([sys.executable, str(script), "--help"], capture_output=True, text=True, timeout=8, check=False)
add(results, proc.returncode == 0 and "usage" in proc.stdout.lower(), f"script --help works: {script.relative_to(root)}")
except Exception as exc:
add(results, False, f"script --help works: {script.relative_to(root)}", str(exc))
The temporary workspace-switch workflow describes selecting another workspace and performing operations there, but it does not clearly warn that subsequent writes may land in a different workspace/account context. That can lead to accidental disclosure, misplaced data, or modifications in the wrong tenant if the switch is forgotten or restoration fails.
The validator offers an opt-in mode that runs each discovered script with --help, but the CLI help text does not clearly warn that this executes arbitrary local code from the analyzed skill package. A user may reasonably expect validation to be passive, so running it on an untrusted repository could trigger attacker-controlled code execution under the user's account.