Back to skill

Security audit

moss

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only Moss semantic search skill whose capabilities are disclosed and aligned with its stated purpose, with some operational cautions users should apply.

Install only in an environment where you are comfortable giving Moss SDK code access to the documents, queries, and Moss project credentials involved. Pin package versions, keep project keys in a secret manager or protected environment variables, review any automatic per-message retrieval for privacy implications, and confirm backups or retention requirements before using delete operations.

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
skills.md:140
Finding
Unpinned Third-Party Dependencies Create a Supply-Chain Risk<![CDATA[ ## Vulnerability Details **File Location**: `skills.md`, lines 140–144 **Vulnerability Type**: Unpinned third-party package installation **Risk Level**: Medium ### Vulnerable Code ```markdown | Language | Package | Install Command | | --------------------- | ----------------- | ----------------------------- | | JavaScript/TypeScript | `@inferedge/moss` | `npm install @inferedge/moss` | | Python | `inferedge-moss` | `pip install inferedge-moss` | | Pipecat Integration | `pipecat-moss` | `pip install pipecat-moss` | ``` ### Technical Analysis The Skill instructs users or agents to install third-party packages without specifying reviewed versions, cryptographic hashes, or lockfiles. Consequently, package resolution depends on the latest version available from the configured npm or Python package registry at installation time. This creates a supply-chain risk because the package content can change after the Skill has been audited. If a package publisher account, registry entry, dependency, or future release is compromised, installation may introduce attacker-controlled code. Package installation can also execute package-controlled lifecycle or build hooks. Imported package code subsequently runs with the privileges of the process using the SDK. There is no evidence in the audited file that the named packages are currently malicious. The vulnerability is the absence of controls that bind installation to a reviewed and reproducible package artifact. ### Attack Path 1. An agent or user follows the installation instructions in `skills.md`. 2. The package manager resolves an unpinned package to the latest available release. 3. An attacker compromises the package, one of its transitive dependencies, its publisher account, or the relevant registry entry. 4. The compromised release is downloaded instead of the version originally reviewed. 5. Malicious code executes through installation hooks or ...[truncated 917 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to an exact, reviewed version rather than allowing installation of the latest release: ```bash npm install --save-exact @inferedge/moss@REVIEWED_VERSION pip install inferedge-moss==REVIEWED_VERSION pip install pipecat-moss==REVIEWED_VERSION ``` 2. Commit and enforce ecosystem lockfiles, such as `package-lock.json` for npm and a hash-locked requirements file generated by `pip-tools` or an equivalent tool for Python. 3. Require integrity verification: - Use npm lockfile integrity metadata and reproducible installation with `npm ci`. - Use Python requirements containing `--hash` entries and install with `pip install --require-hashes`. 4. Review direct and transitive dependencies before updating pinned versions. Verify package publisher identities, official repositories, release signatures where available, and registry provenance. 5. Automate dependency vulnerability and provenance checks in CI, while requiring manual approval before lockfile updates reach production. 6. Perform package installation and execution in a sandboxed, non-privileged environment. Expose only the minimum required files, credentials, and network destinations. 7. Avoid exposing project keys during dependency installation. Supply credentials only to the runtime component that requires them, and rotate credentials if dependency compromise is suspected. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • 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
Findings (4)

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The markdown describes deleting an index and all associated data, but does not include any caution, confirmation note, or warning about irreversible data loss. Because this skill documentation covers operations that can remove stored data, users should be explicitly warned before using them.

Missing User Warnings

Medium
Confidence
86% confidence
Finding
The skill advertises `Delete Documents` as a supported operation, but the description does not warn that stored documents may be permanently removed. For markdown skill descriptions, destructive data-affecting behaviors should be disclosed so users understand the risk.

Missing User Warnings

Medium
Confidence
84% confidence
Finding
The workflow recommends automatically sending each user message to a retrieval system and injecting results into LLM context without any privacy, consent, minimization, or sensitive-data handling guidance. In conversational systems, user messages frequently contain personal, confidential, or regulated data, so this pattern can lead to unnecessary collection, broader data exposure, and cross-context leakage if implemented naively.

Missing User Warnings

Low
Confidence
80% confidence
Finding
The documentation instructs users to set `MOSS_PROJECT_KEY` and send `x-project-key` headers, but does not warn that these are sensitive credentials that must not be logged, committed, or exposed client-side. Since the markdown describes handling access keys, a basic user warning about secret management is warranted.

Static analysis

No suspicious patterns detected.