Back to skill

Security audit

etix-fpx

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed Etix lookup helper that reads public event data, with ordinary but real dependency-install and browser-bridge cautions.

Install only if you are comfortable letting fpx issue Etix-domain fetches through your browser extension after pairing. Prefer pinned package versions, do not run npm install with sudo, and remember that the pairing persists until you remove it.

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 (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:31
Finding
Unpinned Global Installation of FetchProxy CLI<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 31 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ```sh npm install -g @fetchproxy/cli # provides `fpx` ``` ### Technical Analysis The setup instructions install `@fetchproxy/cli` globally without specifying a reviewed version or package integrity constraint. Consequently, the command resolves to whichever release and dependency graph the npm registry serves at installation time. An npm installation can execute package lifecycle scripts and installs executable entry points. If the package, one of its transitive dependencies, its maintainer account, or the relevant registry distribution channel is compromised, following this instruction could execute attacker-controlled code. The global installation also places executable files in a shared npm prefix rather than isolating them to this Skill. This finding does not establish that the current `@fetchproxy/cli` package is malicious. The risk arises because the effective code is mutable after the Skill has been reviewed and the documentation does not pin or verify it. ### Attack Path 1. An attacker compromises the npm package, a maintainer account, or a transitive dependency, or publishes a malicious future release through the legitimate package name. 2. A user follows the Skill's one-time setup instructions after that release becomes the registry's default version. 3. npm downloads the mutable release and its dependency graph. 4. Malicious lifecycle code may execute during installation, or malicious behavior may run when the user later invokes `fpx`. 5. The payload operates with the permissions of the account running npm and can access resources available to that account. The path requires compromise of the package supply chain or publication of an unsafe release. The audited files contain no evidence that such a compromise has already occurred. ### Impact Assessment Successful exploitation could ...[truncated 416 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin `@fetchproxy/cli` to a specifically reviewed version instead of resolving the latest release: ```sh npm install -g @fetchproxy/cli@<reviewed-version> ``` 2. Document the expected package digest, provenance, and reviewed release date so users can verify the artifact. 3. Prefer a project-local installation with a committed lockfile over a global installation, then invoke the pinned binary through a controlled script. 4. Use npm provenance/signature verification where supported and install only from the expected registry. 5. Consider `--ignore-scripts` if the reviewed package does not require lifecycle scripts. 6. Document that users should not run the installation with `sudo` or another privileged account. 7. Periodically review and deliberately update the pinned version rather than accepting changes automatically. ]]>

T08 · Insecure Dependencies

Warning
Location
references/etix-endpoints.md:126
Finding
Unpinned Runtime Installation of HTML Parser Dependency<![CDATA[ ## Vulnerability Details **File Location**: `references/etix-endpoints.md`, line 126 **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ```sh mkdir -p /tmp/etix-parse && cd /tmp/etix-parse && npm install --no-save node-html-parser >/dev/null 2>&1 ``` ### Technical Analysis The documented parsing recipe installs `node-html-parser` without a version pin, lockfile, integrity check, or disabled lifecycle scripts. It therefore retrieves a mutable current package and dependency graph at the time the command is run. The command also redirects both standard output and standard error to `/dev/null`. This can hide package warnings, registry errors, lifecycle-script output, audit notices, and other information that could alert the user to unexpected installation behavior. Using a directory under `/tmp` does not sandbox package installation or lifecycle execution. Installed code still executes with the invoking user's permissions. The fixed `/tmp/etix-parse` path may also be shared or preexisting, although the recorded audit did not establish a concrete local path-manipulation exploit. This finding does not assert that the current `node-html-parser` release is malicious. It identifies an unsafe dependency-acquisition pattern whose effective code can change after review. ### Attack Path 1. An attacker compromises `node-html-parser`, its maintainer account, a transitive dependency, or the relevant npm distribution channel. 2. The compromised package becomes the version selected by an unqualified `npm install node-html-parser`. 3. A user runs the documented venue-parsing recipe. 4. npm retrieves the compromised package and may execute malicious lifecycle code during installation. 5. Installation output and warnings are suppressed by `>/dev/null 2>&1`, reducing the chance that the user notices unexpected behavior. 6. The payload executes with the user's permissions and may continue to run when the parser is imported by the subsequent N ...[truncated 634 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin `node-html-parser` to a reviewed version: ```sh npm install --no-save --ignore-scripts node-html-parser@<reviewed-version> ``` Use `--ignore-scripts` only after confirming that the package functions correctly without lifecycle scripts. 2. Prefer a maintained project manifest and committed lockfile with integrity metadata over an ad hoc runtime installation. 3. Verify npm provenance and install from an explicitly trusted registry. 4. Do not suppress installation output. Preserve warnings and errors so users can identify unexpected package behavior. 5. Use a uniquely created working directory, such as one produced by `mktemp -d`, and clean it after parsing. 6. Document the expected package version, integrity value, and update-review procedure. 7. Where practical, use the repository's dependency-free extraction approach or built-in platform functionality to avoid acquiring executable dependencies during task execution. ]]>
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.