Back to skill

Security audit

Go Production Engineering

Security checks for vulnerabilities and agentic risk

Overview

This is a disclosed Go production-guidance skill with some copy-paste security cautions, but no hidden execution, persistence, credential access, or exfiltration behavior in the artifacts.

Installers should treat this as a Go guidance/reference skill. Before using generated code in production, bind pprof/debug endpoints to localhost or protected admin networks, pin tool versions in CI, and avoid logging direct identifiers unless they are explicitly required and protected by your logging policy.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • 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
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:1167
Finding
Unauthenticated Go pprof Server Exposed on All Network Interfaces## Vulnerability Details **File Location**: `SKILL.md`, lines 1167-1175 **Vulnerability Type**: Unauthenticated diagnostic endpoint exposure **Risk Level**: Medium ```go import _ "net/http/pprof" // In main.go (debug server on separate port) go func() { log.Println(http.ListenAndServe(":6060", nil)) }() // Then: go tool pprof http://localhost:6060/debug/pprof/heap // Or: go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 ``` ### Technical Analysis The example imports `net/http/pprof`, which registers profiling handlers on Go's default HTTP multiplexer. It then starts an HTTP server using `http.ListenAndServe(":6060", nil)`. The empty host in `:6060` causes the service to listen on all available network interfaces, while the `nil` handler selects the default multiplexer containing the pprof endpoints. No authentication, authorization, request throttling, network restriction, or configuration gate protects the profiling interface. If an agent incorporates this example into a service deployed without restrictive firewall rules, remote clients may access endpoints such as heap, goroutine, allocation, and CPU profiles. This exposure is not required for normal production service operation and exceeds minimum privilege by making an internal diagnostic facility network-accessible by default. ### Attack Path 1. A service is generated or modified using the documented profiling example. 2. The service starts a listener on `0.0.0.0:6060` and potentially `[::]:6060`. 3. Deployment networking, a container port mapping, or permissive firewall rules makes port 6060 reachable by an untrusted client. 4. The client requests endpoints such as `/debug/pprof/heap`, `/debug/pprof/goroutine`, or `/debug/pprof/profile?seconds=30`. 5. The client collects runtime diagnostic information or repeatedly requests expensive profiles to consume CPU and other service resources. ### Impact Assessment An attacker does ...[truncated 576 chars]
Remediation
## Remediation Suggestions - Disable profiling by default and require an explicit development or diagnostics configuration flag before starting it. - Bind the listener to a loopback address, such as `127.0.0.1:6060`, rather than all interfaces. - Use a dedicated `http.ServeMux` and explicitly register only the diagnostic handlers that are required. - Place the endpoint behind authenticated administrative access, a service mesh policy, VPN, SSH tunnel, or equivalent network control. - Do not publish the profiling port through container, Kubernetes Service, ingress, or public firewall configuration. - Apply timeouts and rate limits to reduce resource-exhaustion risk. - Ensure production deployment checks detect publicly reachable debug and profiling endpoints.

T08 · Insecure Dependencies

Note
Location
SKILL.md:1257
Finding
Unpinned Installation of a Compiler-Executed Security Tool## Vulnerability Details **File Location**: `SKILL.md`, lines 1257-1262 **Vulnerability Type**: Mutable third-party dependency installation **Risk Level**: Low ```bash # Install go install golang.org/x/vuln/cmd/govulncheck@latest # Scan govulncheck ./... ``` ### Technical Analysis The installation command uses the mutable `@latest` version selector. Consequently, the downloaded source and resulting executable can change over time without any corresponding modification to this Skill. `go install` retrieves and compiles third-party source before producing an executable, and the following command runs that executable against the project. Although the referenced Go vulnerability scanner is a legitimate tool and no malicious package was identified during this audit, relying on an unpinned future release weakens reproducibility and supply-chain review. The behavior is related to the declared security-scanning functionality, but fetching an unspecified future version exceeds the minimum trust necessary. A fixed, reviewed release can provide the same functionality with a more predictable dependency boundary. ### Attack Path 1. A developer or CI job follows the documented installation instruction. 2. The Go toolchain resolves `@latest` at execution time rather than using a previously reviewed version. 3. A newly published, compromised, or unexpectedly changed upstream release is downloaded and compiled. 4. The resulting binary is executed through `govulncheck ./...`. 5. The unreviewed version runs with the permissions and environment of the developer or CI account. This is a conditional supply-chain path; the audit found no evidence that the currently referenced upstream project is malicious. ### Impact Assessment If the resolved dependency were compromised, code could execute with the privileges of the account running the installation or scan. In a developer environment, that could expose accessible source code and ...[truncated 318 chars]
Remediation
## Remediation Suggestions - Replace `@latest` with a specific reviewed release, for example `govulncheck@vX.Y.Z`. - Record and review version updates through normal dependency-management and code-review processes. - Preserve module checksum verification and investigate unexpected `go.sum` or download changes. - Pin the CI environment and toolchain versions to improve reproducibility. - Run the scanner with minimum permissions, without unnecessary secrets, write access, or unrestricted network credentials. - Consider building the pinned tool in a controlled image and referencing that immutable image by digest.
Vulnerability Patterns
  • 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
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (4)

Vague Triggers

Medium
Confidence
91% confidence
Finding
The README advertises very generic trigger phrases such as 'Set up a new Go service' and 'Review this Go code,' which can easily overlap with normal user requests in unrelated contexts. In agent systems that auto-activate skills based on prompt matching, this broad phrasing can cause unintended invocation, expanding the skill's influence beyond explicit user intent and potentially steering code generation or review behavior unexpectedly.

Intent-Code Divergence

Medium
Confidence
91% confidence
Finding
The skill’s stated guidance says not to log PII, but multiple logging examples include user-linked identifiers and email-associated fields, which normalizes unsafe telemetry practices in a production-engineering context. In real deployments, such logs can leak personal data into centralized logging systems, broaden insider access to sensitive information, and increase breach/reporting exposure.

Vague Triggers

Medium
Confidence
91% confidence
Finding
The natural-language triggers are extremely broad (for example, generic requests like 'Review this Go code' or 'Set up CI'), which creates ambiguous activation scope and increases the chance the skill is invoked unintentionally or over-applies high-impact changes. In an agent setting, that can cause unsafe automation, unexpected file generation, or security-sensitive modifications without sufficiently explicit user intent.

Intent-Code Divergence

Low
Confidence
86% confidence
Finding
The profiling example launches a debug HTTP server in a goroutine without any shutdown or access-control pattern, contradicting the skill’s own lifecycle guidance. While presented as a profiling snippet, readers may copy it into services unchanged, leaving a long-lived diagnostics endpoint exposed and unmanaged.

Static analysis

No suspicious patterns detected.