golang-spf13-viper

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 7:34 AM UTC
• Version: 1.1.0

Overview

This is a coherent Go/Viper guidance skill with some hardening notes, but no evidence of hidden, destructive, or deceptive behavior.

Installers should treat this as normal Go configuration guidance. Pin the Viper dependency version instead of copying @latest for production work, review any file edits the agent proposes, and avoid printing or committing sensitive environment-derived configuration such as credential paths or secret values.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Note

• Location: SKILL.md:37
• Finding: Unpinned Go Dependency Uses a Mutable Latest Version## Vulnerability Details **File Location**: `SKILL.md`, line 37 **Vulnerability Type**: Supply-chain risk caused by non-reproducible dependency resolution **Risk Level**: Low ### Vulnerable Code ```bash go get github.com/spf13/viper@latest ``` ### Technical Analysis The installation example instructs the agent or user to resolve `github.com/spf13/viper` using the mutable `@latest` selector. Although this is the official Viper module path and no malicious dependency was identified during the audit, the command does not constrain installation to a reviewed version. The effective dependency can therefore change after the Skill has been audited. Repeating the command at different times may install different source code and transitive dependency graphs. This weakens build reproducibility and makes it difficult to ensure that the installed release is the one that underwent security and compatibility review. This is a supply-chain hardening issue rather than evidence that the current Viper package is malicious. ### Attack Path 1. A user invokes the Skill while adding Viper to a Go project. 2. The agent follows the documented `go get ...@latest` command. 3. The Go toolchain queries the configured module infrastructure and resolves whichever version is considered latest at that time. 4. A newly released, compromised, or insufficiently reviewed version is downloaded. 5. The selected package and its transitive dependencies become part of the target project's dependency graph. 6. The dependency code executes when the resulting application or its tests are built and run. Successful exploitation would require compromise of the upstream release process, module-delivery infrastructure, configured Go proxy, or a future release containing a vulnerability. ### Impact Assessment The impact is limited to projects whose users or agents execute the example. A compromised dependency could obtain the privileges of the build, test, or application process. Depending on where t ...[truncated 261 chars]
• Remediation: ## Remediation Suggestions Replace the mutable selector with a specific, reviewed release: ```bash go get github.com/spf13/viper@vX.Y.Z ``` Additional hardening should include: 1. Select and document a tested Viper version. 2. Commit `go.mod` and `go.sum` so dependency resolution can be verified. 3. Review transitive dependency changes before upgrading. 4. Use automated vulnerability scanning, such as `govulncheck`, in CI. 5. Apply dependency updates through an explicit review process rather than resolving `@latest` during routine Skill use. 6. If the documentation intentionally allows users to select a version, use a placeholder such as `@<reviewed-version>` and explain the review requirement.

T05 · Unauthorized Access and Privilege Escalation

Note

• Location: SKILL.md:18
• Finding: Skill Declares Tools Beyond the Minimum Required for Viper Guidance## Vulnerability Details **File Location**: `SKILL.md`, line 18 **Vulnerability Type**: Excessive agent capabilities and failure to enforce least privilege **Risk Level**: Low ### Vulnerable Code ```yaml allowed-tools: Read Edit Write Glob Grep Bash(go:*) Bash(golangci-lint:*) Bash(git:*) Agent WebFetch mcp__context7__resolve-library-id mcp__context7__query-docs Bash(godig:*) Bash(gopls:*) LSP mcp__gopls__* ``` ### Technical Analysis The Skill permits unrestricted agent delegation through `Agent`, remote retrieval through `WebFetch`, repository operations through `Bash(git:*)`, and file modification through `Edit` and `Write`. Some source-editing and Go-analysis capabilities are reasonable for an integration Skill, but the full set is broader than necessary for its principal purpose of explaining and applying Viper configuration patterns. In particular, the documented workflow does not require unrestricted remote fetching, sub-agent delegation, or every Git subcommand. Broad capability declarations increase the consequences of a future malicious edit, prompt injection in an untrusted repository, or unsafe instructions obtained from remote content. No instruction in the audited files directs these tools toward malicious activity. This finding concerns the available privilege boundary, not confirmed abuse of those privileges. ### Attack Path 1. The Skill is activated with its declared tool permissions. 2. The agent processes attacker-controlled repository text, configuration, or remotely retrieved documentation. 3. That content attempts to redirect the agent into performing actions unrelated to Viper integration. 4. Because the Skill exposes `WebFetch`, `Agent`, Git execution, and file-writing capabilities, the manipulated agent has more avenues to retrieve content, delegate operations, modify files, or alter repository state than a read-only documentation Skill would have. 5. Any resulting access remains constrained by the host harness, sandbox, user app ...[truncated 759 chars]
• Remediation: ## Remediation Suggestions Apply least privilege to the `allowed-tools` declaration: 1. Remove `Agent` unless sub-agent delegation is required by a documented workflow. 2. Remove `WebFetch` or restrict network access to explicitly trusted documentation domains such as `pkg.go.dev` and the official Viper repository. 3. Remove `Bash(git:*)` if repository operations are not essential. If Git is required, permit only specific read-only commands. 4. Keep `Edit` and `Write` only when the Skill is intended to modify a user's Go project; otherwise, use read-only tools. 5. Restrict Go commands to the exact operations needed for dependency inspection, formatting, compilation, and tests. 6. Separate optional research or modification workflows into narrowly scoped Skills so users do not grant all capabilities for simple documentation questions. 7. Preserve host-level approval prompts for network access, file writes, and command execution.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (2)

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The prompt explicitly discusses reading GOOGLE_APPLICATION_CREDENTIALS from the environment and exposing it through Viper, which involves handling a credential-related environment variable. In this JSON/manifest content, there is no warning about sensitivity, credential handling, or avoiding accidental disclosure of secret paths and related configuration.

Vague Triggers

Medium

• Confidence: 78% confidence
• Finding: This JSON eval entry describes a prompt for shipping a default config inside a binary using broad language like "work out of the box" and "sensible defaults" without any limiting context about when this skill should or should not be invoked. In a manifest-like file, such open-ended phrasing can contribute to ambiguous trigger scope because it lacks explicit invocation boundaries or negative examples.

Static analysis

No suspicious patterns detected.