gerritaction

• Outcome: Review
• Latest audit: Sep 12, 2026 · 5:41 AM UTC
• Version: 0.1.0

Overview

This Gerrit automation skill is mostly transparent, but it combines high-impact Gerrit actions with an unpinned external package install and plaintext password-style configuration.

Review this before installing. Use a pinned, reviewed `gerritaction` version in an isolated environment, avoid storing real Gerrit passwords in the skill directory or version control, use HTTPS for non-local Gerrit servers, and run query-only checks before any approve, submit, or delete action.

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

Error

• Location: SKILL.md:38
• Finding: Unpinned Third-Party Package Installation## Vulnerability Details **File Location**: `SKILL.md:38` (installation command repeated at lines 54, 62, 70, 78, 97, and 115) **Vulnerability Type**: Unpinned dependency installation from a mutable package registry **Risk Level**: High **Vulnerable Code Snippet**: ```markdown - Install the package with `pip install gerritaction` before running commands. ``` The documented examples repeat the same installation pattern: ```bash pip install gerritaction ``` ### Technical Analysis The Skill instructs the agent to install `gerritaction` from the default Python package index without specifying a version, cryptographic hash, trusted repository, or reviewed artifact. Consequently, the installed code is determined by the package registry at invocation time rather than by the audited Skill content. Python package installation can execute package-controlled build and installation logic. A compromised maintainer account, malicious future release, registry compromise, or dependency-chain compromise could therefore result in arbitrary code execution. The package would execute in the same security context as the user or agent running the Skill and could access the Gerrit configuration supplied to subsequent commands. No evidence establishes that the current package is malicious. The vulnerability is the Skill's unsafe, mutable dependency acquisition procedure. ### Attack Path 1. An attacker compromises the `gerritaction` package, one of its transitive dependencies, or its package-registry publishing account. 2. The attacker publishes a malicious release that is selected by an unversioned `pip install gerritaction`. 3. An agent follows the Skill instructions and installs the package from the default package index. 4. Malicious installation or runtime code executes with the invoking user's privileges. 5. The payload reads accessible files or Gerrit credentials, alters commands, or sends unauthorized Gerrit API requests. 6. B ...[truncated 637 chars]
• Remediation: ## Remediation Suggestions - Pin `gerritaction` to a specifically reviewed version rather than installing the latest available release. - Require cryptographic hashes, for example through a locked requirements file installed with `pip install --require-hashes`. - Pin and review all transitive dependencies. - Identify the authoritative source repository and verify release provenance or package signatures where supported. - Prefer an internally mirrored, access-controlled package repository containing approved artifacts. - Install and execute the package in an isolated virtual environment or restricted container under a non-privileged account. - Separate dependency installation from normal Skill invocation so package changes undergo security review before deployment. - Replace every unpinned installation example in `SKILL.md` with the same verified, reproducible installation procedure.

T09 · Insecure Skill Coding Practices

Warning

• Location: config.yml:7
• Finding: Plaintext Gerrit Credentials and Unencrypted HTTP Configuration## Vulnerability Details **File Location**: `config.yml:7-10` **Vulnerability Type**: Plaintext credential storage and insecure transport configuration **Risk Level**: Medium **Vulnerable Code Snippet**: ```yaml host: http://127.0.0.1/ port: 8080 user: user pass: pass ``` ### Technical Analysis The Gerrit username and password are represented directly in the project configuration, while the configured endpoint uses unencrypted HTTP. The supplied values appear to be generic placeholders rather than confirmed production credentials, but the documented configuration pattern encourages users to replace them with real credentials stored in plaintext. A plaintext password can be exposed through repository commits, local file access, backups, support bundles, artifact publication, or overly permissive file permissions. HTTP provides neither transport confidentiality nor server authentication. Although the current loopback endpoint reduces ordinary network exposure, traffic could still be observed or redirected by a sufficiently privileged local process. The risk becomes substantially greater if users change the host to a remote Gerrit server while retaining the documented HTTP scheme. ### Attack Path **Configuration disclosure path:** 1. A user replaces the placeholder username and password with valid Gerrit credentials. 2. The configuration file is committed, copied into an artifact, backed up, logged, or left readable to another local user or process. 3. An attacker obtains the plaintext credentials. 4. The attacker authenticates to Gerrit as the affected account. 5. The attacker performs any operation permitted to that account, potentially including reviewer changes, approvals, submissions, or deletion of changes. **Transport interception path:** 1. A user configures a real Gerrit account and retains the `http://` endpoint, particularly when changing it to a non-loopback host. 2. An attacker with access to the ...[truncated 834 chars]
• Remediation: ## Remediation Suggestions - Require HTTPS for Gerrit connections and validate the server's TLS certificate. - Reject plain HTTP for non-loopback endpoints; ideally require TLS for loopback endpoints as well. - Remove the password from the tracked configuration file. - Load credentials from a protected secret manager, operating-system credential store, or narrowly scoped environment-variable reference. - If a credential file is unavoidable, store it outside the project, restrict permissions to the owning user, and exclude it from version control and generated artifacts. - Clearly label bundled values as non-production placeholders and provide a sanitized example file such as `config.example.yml`. - Use a dedicated Gerrit service account with the minimum permissions required for the requested operation. - Prefer short-lived tokens over reusable passwords where Gerrit deployment capabilities permit. - Add secret scanning and repository checks to prevent real credentials from being committed. - Rotate any real credentials that may previously have been stored in or transmitted using this configuration pattern.

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

Static analysis

Detected: suspicious.install_untrusted_source

Install source points to URL shortener or raw IP.

Warn

• Code: suspicious.install_untrusted_source
• Location: config.yml:7