Back to skill

Security audit

Llmfit

Security checks for vulnerabilities and agentic risk

Overview

This skill is a straightforward guide for installing and using a local hardware-checking LLM model fitter, with normal supply-chain caution for third-party install commands.

Before installing, verify that the Homebrew formula, Python package, or GitHub release really belongs to the intended project, prefer a specific reviewed version, and check release hashes or signatures where available. Expect the tool to inspect local hardware details and contact HuggingFace for model metadata; only provide HuggingFace credentials if you intentionally need gated model access.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:25
Finding
Unpinned and Unverified Third-Party Installation Artifacts## Vulnerability Details **File Location**: `SKILL.md`, lines 25-32 **Vulnerability Type**: Unverified third-party dependencies and release artifacts **Risk Level**: Medium ### Vulnerable Code ```bash # Homebrew (macOS/Linux) brew install llmfit # uv / pip (Python wrapper) uv pip install llmfit # Pre-built binary # Download from releases: https://github.com/AlexsJones/llmfit/releases ``` ### Technical Analysis The installation instructions retrieve mutable third-party artifacts without pinning an audited version or requiring checksum or cryptographic-signature verification. The document also does not establish a verifiable mapping between the named Homebrew/Python packages and the stated GitHub source. Package registries, package formulas, repositories, and release assets are external supply-chain trust boundaries. Because the artifact downloaded when these instructions are followed may change after the Skill has been reviewed, the reviewed document does not fully determine the code that will be installed and executed. This creates exposure to package-account compromise, dependency confusion or namespace impersonation, repository compromise, and malicious or replaced release assets. The finding establishes an insecure installation process; it does not establish that the currently referenced packages or repository are malicious. ### Attack Path 1. An attacker compromises a referenced package registry account, repository, release process, or package formula, or publishes an impersonating package through an applicable namespace-confusion scenario. 2. The attacker distributes a modified package or prebuilt binary under the expected name or download location. 3. A user follows one of the documented installation methods. 4. The package manager or browser retrieves the attacker-controlled artifact without enforcing a project-specified version, digest, or trusted signature. 5. Installation hooks or subsequent execution of `llmfit` runs the injected code with ...[truncated 518 chars]
Remediation
## Remediation Suggestions 1. Pin every installation method to a specific audited release version rather than using an unqualified package name. 2. Link directly to the verified official Homebrew formula, Python package publisher, and exact immutable release. 3. Publish SHA-256 digests for every prebuilt binary and include explicit verification commands before execution. 4. Prefer signed releases and require verification against a documented maintainer signing key or trusted provenance identity. 5. Use lockfiles or equivalent dependency constraints for wrappers and transitive dependencies. 6. Document package ownership and provenance checks so users can confirm that registry packages correspond to the stated source repository. 7. Use reproducible builds and supply-chain attestations, such as SLSA provenance, where available. 8. Advise users to install and execute the tool with least privilege and never use administrator or root access unless independently justified.
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.