Openhook Cli

• Outcome: Pass
• Latest audit: Sep 12, 2026 · 7:43 AM UTC
• Version: 1.0.2

Overview

This is a coherent OpenHook CLI guide, but users should be careful with the external install, API key handling, webhook payloads, and optional daemon.

Install only if you trust OpenHook and its Homebrew tap. Prefer a test or least-privilege API key, avoid placing live keys in command history, scripts, logs, or screenshots, verify the CLI source/version where possible, and stop the daemon when it is not needed. Treat webhook payloads and channel messages as external-service data.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:24
• Finding: Unpinned Installation from a Third-Party Homebrew Tap<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 24 **Vulnerability Type**: Supply-chain risk from an unpinned third-party dependency **Risk Level**: Medium ### Vulnerable Code ```bash brew tap openhook-dev/openhook && brew install openhook ``` ### Technical Analysis The installation instructions add the third-party `openhook-dev/openhook` Homebrew tap and install the current version of its `openhook` formula without pinning a reviewed version, commit, artifact digest, or cryptographic signature. Consequently, the effective code installed by this command can change after the Skill has been audited. If the tap repository, maintainer account, formula, release infrastructure, or referenced artifacts are compromised, following the documented command could install attacker-controlled code. The project does not itself demonstrate that the dependency is malicious; the vulnerability is the absence of controls that bind installation to a previously reviewed artifact. ### Attack Path 1. An attacker compromises the third-party Homebrew tap, a maintainer account, or the upstream release distribution mechanism. 2. The attacker modifies the formula or replaces an artifact referenced by it with a malicious version. 3. A user follows the Skill's installation command. 4. Homebrew retrieves and processes the modified formula or artifact. 5. Malicious installation logic or the compromised CLI executes with the privileges available to the Homebrew process. 6. The installed CLI may continue to execute attacker-controlled behavior whenever the user invokes the documented `openhook` commands. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the account running Homebrew. The attacker could access files, environment variables, developer credentials, and network resources available to that account. If the installation is run from a more privileged context, the impact may expand accordingly. The issue does not indep ...[truncated 164 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Specify and test a known-good OpenHook CLI release rather than implicitly installing the latest available release. 2. Pin the Homebrew formula or tap to a reviewed immutable commit where operationally feasible. 3. Verify downloaded release artifacts using a vendor-published cryptographic signature or a trusted SHA-256 digest. 4. Document the expected package version and trusted distribution source. 5. Recommend installation from a minimally privileged user account and avoid elevated execution unless strictly required. 6. Periodically review the pinned release and update it through a controlled dependency-review process. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:37
• Finding: API Key Exposed Through a Command-Line Argument<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 37 **Vulnerability Type**: Sensitive credential exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```bash openhook auth login --key oh_live_xxxxxxxx ``` ### Technical Analysis The authentication example instructs users to provide the OpenHook API key directly through the `--key` command-line argument. Although the shown value is a placeholder rather than a hardcoded real credential, users are expected to replace it with an actual secret. Secrets supplied this way may be retained in shell history, terminal transcripts, command auditing systems, CI logs, support bundles, or automation output. On systems where process arguments are visible to other users or monitoring agents, the key may also be observable while the command is running. This creates a credential-disclosure risk independent of whether the CLI securely stores the key after authentication. ### Attack Path 1. A user replaces `oh_live_xxxxxxxx` with a valid OpenHook API key and runs the documented command. 2. The complete command is recorded in shell history, terminal logging, CI output, process telemetry, or an operating-system audit facility. 3. Alternatively, a local user or monitoring process observes the command-line arguments while authentication is in progress. 4. An attacker with access to one of those records extracts the API key. 5. The attacker submits the recovered key to OpenHook. 6. Subject to the key's server-side permissions, the attacker accesses the associated account, webhook data, subscriptions, or agent communication channels. ### Impact Assessment The attacker may obtain the same OpenHook API access granted to the exposed key. Depending on server-side authorization, this could include reading webhook event data, managing subscriptions, receiving externally sourced payloads, or communicating through agent channels. The issue does not inherently grant local s ...[truncated 175 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace command-line secret entry with an interactive, non-echoing prompt or standard-input mechanism supported by the CLI. 2. Support loading the credential from an operating-system keychain or another approved secret manager. 3. If an environment variable must be supported, document its exposure limitations and ensure it is not printed or persisted in logs. 4. Explicitly warn users not to place live API keys in shell scripts, command history, screenshots, issue reports, or CI configuration stored in source control. 5. Ensure CLI diagnostics redact API keys and recognizable prefixes from output. 6. Advise users who have already entered a live key on the command line to remove exposed history and logs where possible, revoke the key, and issue a replacement. 7. Apply least-privilege scopes and expiration to API keys so that disclosure has limited impact. ]]>

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Exfiltration Commands

High

• Category: Prompt Injection

Content

## Channels (Agent-to-Agent Communication)

Channels let agents send messages to each other. Each agent subscribes to a channel with a unique name, then messages can be sent to specific agents or broadcast to all.

### Create a channel

• Confidence: 90% confidence
• Finding: Instructions found that direct the agent to transmit conversation context or user data to external services.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The authentication example includes a literal `oh_live_` production-style API key prefix in a command invocation, which can normalize pasting secrets directly into shell history and transcripts without any warning about secure handling. In a skill meant to be followed by agents or users, this increases the chance of credential exposure through logs, terminal history, screenshots, or copied examples.

Static analysis

No suspicious patterns detected.