Back to skill

Security audit

Posthog CLI

Security checks for vulnerabilities and agentic risk

Overview

This PostHog CLI skill is not clearly malicious, but it gives agents broad write and delete authority over analytics resources with weak guardrails.

Review this skill before installing. Use it only with narrowly scoped PostHog credentials, prefer read-only operations unless you explicitly intend to change production resources, avoid copying --yes delete commands into agent workflows, and verify any self-hosted PostHog hostname before authenticating.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (2)

T08 · Insecure Dependencies

Error
Location
SKILL.md:15
Finding
Unpinned Third-Party CLI Installation Creates a Supply-Chain Risk<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 15-19; dependency context at line 6 **Vulnerability Type**: Unpinned third-party dependency installation from a mutable package repository **Risk Level**: High ### Vulnerable Code ```markdown compatibility: Requires Python 3.10+ and pip. The CLI command is `posthog` (installed via `pip install phog-cli`). ``` ```bash pip install phog-cli ``` ### Technical Analysis The Skill instructs users or agents to install `phog-cli` from the default Python package index without specifying an audited version, verifying cryptographic hashes, or locking transitive dependencies. The package is community-maintained and is subsequently trusted to process PostHog API credentials and sensitive analytics data. Because the package reference is mutable, future invocations may install a different release from the one reviewed when this Skill was published. The repository URL in the metadata does not cause `pip` to verify that the downloaded package was built from that repository or from a particular source revision. This is a supply-chain weakness rather than evidence that the current package is malicious. Exploitation requires compromise of the package publisher, package-index distribution path, or one of the package's unresolved dependencies. ### Attack Path 1. An attacker compromises the package publisher account, package release process, or an unpinned transitive dependency. 2. The attacker publishes a malicious release that still resolves under the name `phog-cli`. 3. A user or agent follows the Skill and runs `pip install phog-cli`. 4. The package manager resolves and installs the attacker-controlled release. 5. Malicious installation or runtime code executes with the privileges of the account running `pip` or the CLI. 6. When the CLI is used, the malicious code may access `POSTHOG_API_KEY`, configuration files, analytics responses, and other data available to the process. ### Impact Assessment Suc ...[truncated 657 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin the package to a specifically reviewed version, for example: ```bash python -m pip install "phog-cli==<reviewed-version>" ``` - Publish a lock file or requirements file that pins all transitive dependencies. - Provide cryptographic hashes and require hash verification: ```bash python -m pip install --require-hashes -r requirements.txt ``` - Verify that the package artifact is produced from the stated source repository using signed tags, attestations, or trusted build provenance. - Re-audit the dependency whenever the pinned version changes. - Recommend installation into an isolated virtual environment rather than the system Python environment. - Avoid elevated installation privileges and grant the PostHog API key only the minimum permissions required for the intended operation. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
references/commands.md:31
Finding
Authentication Example Uses an Inconsistent External Hostname<![CDATA[ ## Vulnerability Details **File Location**: `references/commands.md`, lines 31-36 **Vulnerability Type**: Unsafe authentication endpoint example **Risk Level**: Medium ### Vulnerable Code ```bash posthog auth login # auto-detect US/EU cloud posthog auth login --host https://posthog.co.com # self-hosted posthog auth status # show current auth posthog auth logout # remove credentials ``` ### Technical Analysis The self-hosted authentication example uses the concrete hostname `posthog.co.com`. This conflicts with the clearly illustrative hostname `https://posthog.company.com` in `SKILL.md` and with the documented PostHog cloud regions `us.posthog.com` and `eu.posthog.com`. A self-hosted example should use a reserved example domain or an explicit placeholder. Providing an unrelated-looking concrete hostname may cause a user or automated agent to direct authentication activity toward an endpoint that the user does not own or control. The repository contains no implementation of the external CLI's login flow, so the audit cannot establish exactly which credentials or tokens the command transmits. Nevertheless, using an unverified endpoint for authentication creates a credible risk of credential disclosure or authentication-flow interception. ### Attack Path 1. A user or agent copies the documented self-hosted login command without replacing the hostname. 2. The external `posthog` CLI connects to `https://posthog.co.com`. 3. If the CLI accepts the endpoint, authentication proceeds against an unintended service. 4. Depending on the CLI's authentication protocol, authentication data, tokens, or other sensitive request content may be disclosed to or influenced by that endpoint. 5. Any exposed PostHog credential could then be used within its assigned organization, project, and API permission scope. ### Impact Assessment Potential impact includes disclosure of aut ...[truncated 558 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Replace the concrete hostname with an unambiguous reserved example domain: ```bash posthog auth login --host https://posthog.example.com ``` - Explicitly instruct users to replace the hostname with the HTTPS origin of their own verified PostHog deployment. - Add a warning not to authenticate against copied or unverified domains. - Keep official cloud examples limited to documented PostHog endpoints such as `https://us.posthog.com` and `https://eu.posthog.com`. - Recommend validating the TLS certificate and organizational ownership of a self-hosted endpoint before entering credentials. - Use narrowly scoped API credentials so that exposure of one credential does not grant unnecessary administrative or cross-project access. ]]>
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Rogue AgentSelf-Modification, Session Persistence
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (13)

Tool Parameter Abuse

High
Category
Tool Misuse
Content
posthog api get /path/
posthog api post /path/ --data '{"key": "value"}'
posthog api patch /path/ --data '{"key": "value"}'
posthog api delete /path/
```

## Error Handling
Confidence
96% confidence
Finding
The raw API escape hatch allows arbitrary endpoint access, including delete operations with user-supplied paths and data. In an agent environment, this creates a powerful parameter-abuse surface where prompt-driven input could be turned into unintended destructive API calls against PostHog resources.

Context-Inappropriate Capability

High
Confidence
98% confidence
Finding
The raw API escape hatch allows arbitrary project-scoped GET/POST/PATCH/DELETE requests, effectively bypassing any safety boundaries implied by higher-level commands. In an agent context, this is particularly dangerous because it enables unbounded mutation of analytics configuration and data-adjacent resources with minimal guardrails, making misuse or prompt-induced abuse much easier.

Missing User Warnings

High
Confidence
97% confidence
Finding
The raw API delete example is especially risky because it combines arbitrary endpoint targeting with a `--yes` destructive pattern and no safety messaging. This materially increases the chance of severe unintended changes or deletions across project resources, especially when used by an autonomous or semi-autonomous agent.

Vague Triggers

Medium
Confidence
92% confidence
Finding
The skill description is broad enough to trigger on generic analytics or product-health questions, which can cause the agent to invoke a terminal-integrated skill when the user did not explicitly ask to use PostHog or a CLI. That increases the chance of unnecessary access to analytics data or execution of commands in contexts where a safer, non-tool response would suffice.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
Use with ANY command:

- `--json` / `-j` — Machine-readable JSON output. **Always use this when parsing output programmatically.**
- `--yes` / `-y` — Skip confirmation prompts. **Always use this for non-interactive automation.**
- `--help` — Show help for any command.

## Quick Reference
Confidence
94% confidence
Finding
The instruction to 'Always use' --yes for non-interactive automation encourages bypassing confirmation prompts across all commands, including destructive or high-impact ones. In an autonomous agent context, this removes an important safety barrier and makes accidental or unauthorized changes significantly easier.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The documentation prominently includes create, update, patch, and delete-style operations without adjacent warnings that these commands change production analytics configuration and project state. In an agent setting, examples can be treated as acceptable actions, increasing the risk that the agent performs impactful changes without clear user confirmation.

Session Persistence

Medium
Category
Rogue Agent
Content
### Feature Flag Rollout

```bash
posthog flag create --key new-feature --name "New Feature" --rollout-percentage 10
posthog flag update <id> --rollout-percentage 50
posthog flag update <id> --rollout-percentage 100
```
Confidence
60% confidence
Finding
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Description-Behavior Mismatch

Medium
Confidence
96% confidence
Finding
The command reference exposes broad state-changing capabilities including create, update, launch, stop, and delete operations across flags, experiments, surveys, dashboards, insights, and raw API calls, which exceeds a narrowly analytics/read-oriented skill framing. This increases the chance an agent will take destructive or configuration-changing actions under the guise of analytics assistance, especially because the documentation presents these commands as normal usage without narrowing conditions or approval requirements.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The documented `posthog --yes flag delete <flag-id>` example demonstrates irreversible deletion while also bypassing confirmation, yet provides no warning to the operator. In an agent-driven workflow, this raises the risk of accidental or induced deletion of feature flags that can affect product behavior and rollout controls.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The experiment deletion example presents a destructive action without warning about permanence or operational consequences. Deleting experiment records can remove important historical context and can be triggered too easily by an agent or user following examples verbatim.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The survey deletion example uses `--yes` to bypass confirmation and lacks any caution about permanent removal. Because surveys may be customer-facing artifacts and associated reporting may be operationally important, an agent could cause unintended loss with a single command copied from the reference.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The dashboard deletion command is shown as a routine example without warning that the action is irreversible. In practice, dashboards often represent curated operational views, so deleting them can disrupt analytics workflows and shared visibility across teams.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The insight deletion example lacks a safety warning despite being a destructive action that may remove saved analytical work. In an agent setting, terse examples can be treated as endorsed actions, increasing the likelihood of accidental deletion of valuable queries or reports.

Static analysis

No suspicious patterns detected.