golang-uber-fx

• Outcome: Review
• Latest audit: Sep 16, 2026 · 7:35 AM UTC
• Version: 1.2.0

Overview

The skill is a coherent Go fx guidance skill, but it requests broader agent powers than its purpose needs.

Review the requested tool permissions before installing. This skill appears useful for Go fx work, but it should be run in environments that restrict remote Git actions, outbound fetching, and delegated agents unless explicitly needed. Pin and review any go.uber.org/fx dependency changes in go.mod and go.sum.

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)

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:18
• Finding: Overbroad Tool Permissions Violate Least Privilege## Vulnerability Details **File Location**: `SKILL.md`, line 18 **Vulnerability Type**: Excessive agent tool authorization **Risk Level**: Medium ### 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 primarily provides architectural guidance for applications using `go.uber.org/fx`. Most of that functionality requires reading and editing Go files, searching source code, and optionally running narrowly scoped Go analysis or test commands. The authorization of unrestricted `Bash(git:*)`, `WebFetch`, and `Agent` capabilities exceeds these minimum requirements: - `Bash(git:*)` permits mutating Git operations, including changing remotes, modifying repository configuration, committing changes, and potentially pushing data if credentials are available. - `WebFetch` introduces an outbound network channel that could disclose information through attacker-controlled URLs or retrieve untrusted content. - `Agent` permits delegation to other agents, expanding the effective execution and information-access scope. - Broad write access may allow changes outside the narrow set of Go source files declared under `paths`. The Skill does not contain instructions that actively exploit these permissions. Nevertheless, granting them increases the consequences of prompt injection originating from an untrusted repository or externally retrieved documentation. The pre-scan warning concerning sensitive network transmission was also reviewed. No explicit credential exfiltration was found. The API-key example in `references/recipes.md` only reads and injects a key into an API client; it does not transmit or log it. ### Attack Path 1. A repository being analyzed contains attacker-controlled comments, documentation, generated files, or ...[truncated 1162 chars]
• Remediation: ## Remediation Suggestions Apply least-privilege controls to the Skill declaration: 1. Remove `Agent` unless delegated execution is demonstrably required. 2. Remove `WebFetch` for ordinary source work. If documentation retrieval is necessary, restrict it to an allowlist of official domains such as `pkg.go.dev`, `go.uber.org`, `uber-go.github.io`, and the verified upstream GitHub repository. 3. Replace `Bash(git:*)` with narrowly scoped, read-only operations such as status, diff, log, and show. Explicitly prohibit push, remote mutation, hooks, configuration changes, and credential-related operations. 4. Restrict write operations to files needed for the user-requested Go change and require confirmation before modifying dependency manifests or repository metadata. 5. Treat repository content and fetched documentation as untrusted data rather than agent instructions. 6. Require explicit user approval before any outbound network operation or Git operation that affects a remote.

T08 · Insecure Dependencies

Note

• Location: SKILL.md:37
• Finding: Dependency Installation Instruction Does Not Pin a Reviewed Version## Vulnerability Details **File Location**: `SKILL.md`, lines 37-39 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Low ### Vulnerable Code ```bash go get go.uber.org/fx ``` ### Technical Analysis The installation example requests `go.uber.org/fx` without specifying a version. When the dependency is not already constrained by the project, the Go toolchain may resolve a currently available release rather than a release reviewed when the Skill was published. The resulting behavior can therefore change over time. The package path is consistent with the official uber-go/fx project; no typosquatting or known malicious dependency was identified. The issue is the absence of version pinning and an explicit verification workflow, which weakens reproducibility and increases exposure to an upstream compromise or an incompatible future release. Although Go records resolved versions and checksums in `go.mod` and `go.sum`, those protections occur after resolution and do not establish that the selected version was reviewed or approved for the project. ### Attack Path 1. A user follows the documented `go get go.uber.org/fx` command in a project without an existing version constraint. 2. The Go toolchain resolves a release available at execution time. 3. An unexpected, compromised, or incompatible upstream release is downloaded through the configured Go module proxy or source origin. 4. The dependency is compiled into the application and may execute with the application's runtime privileges. 5. The risk persists if the generated `go.mod` and `go.sum` changes are accepted without dependency review. ### Impact Assessment A compromised dependency could execute as part of builds, tests, or the resulting application and would inherit the associated process privileges. Potential effects include source or credential access, network communication, application compromise, and build-output tampering. N ...[truncated 180 chars]
• Remediation: ## Remediation Suggestions 1. Replace the floating installation example with a reviewed, explicit release: ```bash go get go.uber.org/fx@vX.Y.Z ``` 2. Select a currently supported version after reviewing the official release notes and security advisories. 3. Commit and review the resulting `go.mod` and `go.sum` changes. 4. Run `go mod verify` in CI and use a trusted Go module proxy or controlled internal proxy. 5. Add dependency-vulnerability scanning, such as `govulncheck`, to CI. 6. Update pinned versions through a controlled dependency-review process rather than resolving an unconstrained release during routine Skill use.

SkillSpector

Vulnerability Patterns

• System Prompt Leakage: Direct Leakage, Indirect Extraction, Tool-Based Exfiltration
• 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

Findings (1)

Direct Prompt Extraction

High

• Category: System Prompt Leakage

Content

1. Keep `main()` thin — providers, modules, and a single `Run()`. Push real work into modules so each can be tested in isolation.
2. Use lifecycle hooks instead of `init()` or goroutines launched from constructors — Start/Stop ordering depends on graph topology, but `init()` goroutines do not, which leads to races and leaks.
3. OnStart must return promptly — long work goes in a goroutine inside the hook. A blocking OnStart hangs the rest of the boot.
4. Respect `ctx.Done()` in hooks — a hook that ignores cancellation is reported as a timeout failure but its goroutine continues, leaking resources.
5. Group by module, not by layer — a module owns the providers, lifecycle, and decorators for one concern (HTTP, DB, metrics).
6. Use `fx.Annotate` for tags rather than wrapping a constructor in an `fx.Out` struct — keeps the constructor reusable outside fx.

• Confidence: 85% confidence
• Finding: Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.

Static analysis

No suspicious patterns detected.