Back to skill

Security audit

Go安全缺陷检测

Security checks for vulnerabilities and agentic risk

Overview

This Go vulnerability skill has a legitimate purpose, but it gives broad command-execution and dependency-changing guidance without enough scoping or user-control safeguards.

Install only if you intend to use it on authorized local Go projects. Run scan-only steps first, pin govulncheck and dependency versions where possible, review go.mod and go.sum diffs carefully, and require explicit approval before any dependency update or replace directive is applied.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:80
Finding

Unpinned Installation of an Executable Go Security Tool

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 80
Vulnerability Type: Unpinned executable dependency
Risk Level: Medium

Vulnerable Code:

bash
go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

The same unpinned installation instruction is repeated at line 188.

Technical Analysis

The skill instructs the agent to install govulncheck using the mutable @latest version selector. This downloads and compiles whichever version the Go module infrastructure resolves at execution time. The installed executable is subsequently run with the permissions of the agent's operating-system account.

Because no reviewed version is pinned, the effective code can change after the skill has been audited. A compromised upstream repository, maintainer account, release process, or dependency could therefore cause unexpected code to be installed and executed. The lack of version pinning also makes audit results and automated workflows non-reproducible.

Go checksum-database validation can help detect inconsistent module content, but it does not establish that a newly published version is trustworthy or appropriate for this workflow.

Attack Path

  1. An attacker compromises the upstream project, a maintainer account, its release process, or a dependency included by a future release.
  2. A compromised version becomes the version selected by @latest.
  3. An agent follows the skill and executes go install golang.org/x/vuln/cmd/govulncheck@latest.
  4. Go downloads and compiles the attacker-influenced source and installs the resulting executable.
  5. The agent runs govulncheck ./..., executing the installed code under the agent user's security context.

Impact Assessment

Successful exploitation could execute arbitrary code with the privileges of the user running the agent. Depending on that user's permissions and environment, the affected scope could include project source files ...[truncated 333 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace @latest with a reviewed, fixed release, for example:

    bash
    go install golang.org/x/vuln/cmd/govulncheck@vX.Y.Z
    
  • Record the approved version in the skill and update it through a controlled review process.

  • Review upstream release notes and dependency changes before upgrading.

  • Retain Go module checksum verification and use trusted Go proxy and checksum-database settings.

  • Install and execute the tool in an isolated, least-privileged environment without unnecessary credentials.

  • Apply the same correction to the repeated installation instruction at line 188.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:119
Finding

Unbounded Upgrade of a Project Dependency

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 119
Vulnerability Type: Unreviewed mutable dependency upgrade
Risk Level: Medium

Vulnerable Code:

bash
go get -u golang-jwt/jwt@latest
go mod tidy

The document also recommends general use of go get -u at lines 182 and 191.

Technical Analysis

The remediation command combines the broad -u upgrade option with the mutable @latest selector. This can introduce a newer dependency version than the minimum version required to address a vulnerability and can alter related dependency selections recorded in go.mod and go.sum.

The resulting dependency graph may contain code that was not reviewed during preparation of the skill. In addition to supply-chain risk, broad upgrades can introduce incompatible API or behavioral changes. Subsequent build and test commands may compile or execute initialization code and test code from the newly selected dependency graph.

Although the skill later recommends running builds and tests, testing alone does not establish the security or provenance of newly introduced dependency code.

Attack Path

  1. An attacker compromises a future release of the named module, its publication process, or a dependency selected during the upgrade.
  2. The compromised release becomes the version resolved by @latest, or broad upgrade behavior selects attacker-influenced dependency code.
  3. An agent runs go get -u golang-jwt/jwt@latest.
  4. The project's go.mod and go.sum are modified to reference the newly resolved dependency graph.
  5. The agent runs go build ./... or go test ./..., causing the selected code to be compiled and potentially executed.
  6. The modified dependency declarations may be committed or distributed, extending exposure to CI systems and other developers.

Impact Assessment

Exploitation could affect the audited project, its build environment, CI workers, and downstream users who con ...[truncated 447 chars]

Remediation
View remediation

Remediation Suggestions

  • Replace broad latest-version upgrades with the minimum reviewed version known to contain the security fix:

    bash
    go get golang-jwt/jwt@vX.Y.Z
    go mod tidy
    
  • Avoid -u unless upgrading the broader dependency graph is an explicit and reviewed objective.

  • Confirm the correct module path and supported release branch before applying a version.

  • Review all changes to go.mod and go.sum, including indirect dependency changes.

  • Run govulncheck, compilation, tests, and security-sensitive integration tests in an isolated environment.

  • Use dependency-review automation and require approval for unexpected modules or version changes.

  • Update the general recommendations at lines 182 and 191 so they favor pinned, minimum-fixed versions rather than unrestricted upgrades.

Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (4)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
94% confidence
Finding

The activation language is overly broad for a skill that has exec capability, inviting use for generic 'security detection', 'compliance audit', and even 'encryption protection' tasks beyond Go vulnerability scanning. In an agent environment, ambiguous routing can cause this skill to be selected for unrelated requests and execute system/package-management commands in the wrong repository or context.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The skill instructs the agent to run commands like go get -u, go mod tidy, and go mod edit -replace, which modify go.mod, go.sum, and potentially the dependency graph, without an upfront warning that repository files will change. In an autonomous agent setting, this can cause unintended source-control diffs, break builds, or introduce risky dependency substitutions without explicit user consent.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

Lines L262-L265 explicitly claim to show the skill's core implementation logic, but the code shown is only echo "implementation_ready" and performs no Go vulnerability scanning, assessment, or remediation. This is an active contradiction between the inline documentation and the demonstrated code behavior, not merely an omission.

Content

No source excerpt is available for this finding.

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
91% confidence
Finding

The listed scenarios include broad domains like data synchronization, intelligent analysis, ETL pipelines, and operations automation, which are not specific to Go vulnerability analysis. Because the skill exposes exec, this overbroad positioning increases the chance an agent invokes it in inappropriate contexts, leading to unnecessary command execution or project changes outside its intended security-audit purpose.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.