gurkerlcli

• Outcome: Review
• Latest audit: Sep 10, 2026 · 4:39 AM UTC
• Version: 0.1.6

Overview

The skill is a coherent grocery-shopping CLI helper, but it asks users to expose and persist account passwords in unsafe ways.

Review before installing. Prefer interactive login or an OS credential manager, avoid putting the Gurkerl password in shell history, environment variables, or ~/.env.local, and verify the external gurkerlcli package source/version before use. Treat cart and list commands as authenticated account changes.

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:14
• Finding: Unpinned Third-Party CLI Installation Creates a Supply-Chain Risk<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 14-20 **Vulnerability Type**: Unpinned and externally maintained dependencies **Risk Level**: Medium ### Vulnerable Code ```bash # Via Homebrew brew tap pasogott/tap brew install gurkerlcli # Or via pipx pipx install gurkerlcli ``` ### Technical Analysis The installation instructions retrieve and execute `gurkerlcli` from a third-party Homebrew tap or Python package registry without pinning an audited version, package hash, immutable source commit, or cryptographic signature. Because the executable implementation is not included in the audited project, its behavior cannot be verified from `SKILL.md`. The package associated with either installation command can also change after this Skill has been reviewed. This creates a supply-chain trust boundary in which control of the package registry account, Homebrew tap, release artifacts, or upstream repository may allow an attacker to distribute modified code. This finding does not establish that the current package is malicious. It identifies the absence of controls that would prevent a future compromised or replaced package from being installed. ### Attack Path 1. An attacker compromises the package maintainer's account, package registry entry, Homebrew tap, or release infrastructure. 2. The attacker publishes a malicious version under the expected package name. 3. A user or agent follows the Skill's unpinned installation instructions. 4. Homebrew or `pipx` resolves and installs the attacker-controlled release. 5. The malicious package executes during installation or when `gurkerlcli` is invoked. 6. The payload operates with the privileges and data access of the installing user. ### Impact Assessment Successful exploitation could permit arbitrary code execution in the installing user's security context. Depending on that user's environment, the compromised package could access local files, environment variables, browser or application ...[truncated 373 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin installation instructions to a specific audited release rather than resolving the latest available version. - Publish and verify SHA-256 checksums or cryptographic signatures for release artifacts. - For Homebrew, reference a reviewed formula revision and ensure bottle checksums are enforced. - For Python distribution, use a version-pinned command and provide hash-verified installation instructions, for example through a locked requirements file using `--require-hashes`. - Clearly identify the authoritative package registry, repository, maintainer, and expected package identity to reduce dependency-confusion and typosquatting risks. - Re-audit the executable package whenever the pinned release is updated. - Avoid recommending elevated installation privileges. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:27
• Finding: Authentication Instructions Expose Account Passwords Through Unsafe Input and Storage Channels<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 27-42 **Vulnerability Type**: Plaintext credentials in command arguments, environment variables, and persistent environment files **Risk Level**: Medium ### Vulnerable Code ```bash gurkerlcli auth login --email [e-mail] --password xxx gurkerlcli auth whoami # Check login status gurkerlcli auth logout # Clear session ``` Session is stored securely in macOS Keychain. **Alternative: Environment variables** ```bash export GURKERL_EMAIL=[e-mail] export GURKERL_PASSWORD=your-password ``` Or add to `~/.env.local` for persistence. ### Technical Analysis The documentation recommends passing a password directly through the `--password` command-line argument. Depending on the shell and operating system, this can expose the password through shell history, process inspection interfaces, terminal recordings, command auditing, crash reports, or diagnostic tooling. The alternative environment-variable approach keeps the credential in the process environment. Environment variables may be inherited by child processes and can be collected by debugging, telemetry, crash-reporting, or process-inspection tools available to the same user or privileged local actors. Persisting `GURKERL_PASSWORD` in `~/.env.local` may place the password in a plaintext file. The instructions do not require restrictive file permissions, exclusion from version control, or protection from backups and synchronization services. The statement that the resulting session is stored in macOS Keychain does not eliminate exposure of the original password while it is supplied to the login command. ### Attack Path 1. A user follows the documented login example and types the account password as a command-line argument. 2. The command is retained in shell history or exposed temporarily through process metadata, auditing, or terminal logging. 3. Alternatively, the user exports the password into the environm ...[truncated 1165 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the `--password` example and have the CLI request the password interactively using hidden terminal input. - Prefer an operating-system credential manager, such as macOS Keychain, for both credentials and session tokens. - Where supported, use browser-based authentication, OAuth, or short-lived device authorization instead of handling the account password directly. - Avoid recommending persistent password environment variables. - If noninteractive authentication is essential, accept the secret through a protected file descriptor or standard input without echoing it, and ensure it is never logged. - If a credential file must be supported, document restrictive permissions such as owner-only access, require exclusion from version control, and warn about backup and synchronization exposure. - Ensure debug output, crash reports, and error messages redact passwords, authorization headers, and session tokens. - Recommend rotating the Gurkerl password if it has previously been entered into shell history or committed to a file. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• 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 (1)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly recommends storing login credentials in environment variables or a persistent local file (`~/.env.local`) without warning about exposure risks. Environment variables can leak via shell history, process inspection, debug logs, crash reports, or misconfigured tooling, and a persistent dotfile increases the chance of accidental disclosure or insecure file permissions.

Static analysis

No suspicious patterns detected.