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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.