T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:21- Finding
Overly Broad Outbound Network Permissions
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This Go performance skill is mostly coherent, but it asks for broad network and code-change authority and includes under-scoped production profiling/build guidance that users should review before installing.
Install only if you are comfortable with the agent reading and editing Go code, running Go performance tools, and having outbound network capability. Use it in a sandbox for untrusted repositories, pin benchstat to a reviewed version, do not expose pprof publicly, and avoid following the production SSH build example outside a controlled CI or staging environment.
SKILL.md:21Overly Broad Outbound Network Permissions
references/cpu.md:196Production SSH Build Guidance Exceeds Least Privilege
SKILL.md:17Mutable Unpinned Benchstat Installation
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
**Rules:**
- Reset state before `Put()` — clear references to avoid retaining large object graphs across GC cycles
- Return copies, not pooled buffers — callers must not hold references to pooled memory
- Don't pool objects >32KB — large allocations bypass the pool's size classes and GC already handles them efficiently
- Don't pool infrequently used objects — pool overhead exceeds benefit when allocations are rare
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"id": 27,
"name": "http-transport-maxidleconnsperhost",
"description": "Tests knowledge that default http.Client MaxIdleConnsPerHost is only 2",
"prompt": "Our Go microservice calls an upstream API with high concurrency (200 goroutines making requests simultaneously). Under load, we see many TCP connections being created and destroyed. Why doesn't connection pooling work?\n\n```go\nvar client = &http.Client{\n Timeout: 30 * time.Second,\n}\n\nfunc CallAPI(ctx context.Context, id string) ([]byte, error) {\n resp, err := client.Get(fmt.Sprintf(\"https://api.example.com/v1/items/%s\", id))\n if err != nil {\n return nil, err\n }\n defer resp.Body.Close()\n return io.ReadAll(resp.Body)\n}\n```",
"trap": "The default http.Transport has MaxIdleConnsPerHost=2. With 200 concurrent goroutines, 198 connections are created and destroyed for each request. The skill specifically calls this out as a common mistake. Without it, the model may suggest connection pool libraries instead of tuning the built-in transport.",
"assertions": [
{"id": "27.1", "text": "Identifies MaxIdleConnsPerHost defaulting to 2 as the root cause"},
The document instructs users to fetch a production CPU profile from /debug/pprof/profile but does not warn that exposing Go's pprof HTTP handlers can leak sensitive runtime and application information or create an attack surface if reachable by untrusted users. In a performance-tuning skill, readers may copy this directly into production workflows, increasing the chance that profiling endpoints remain enabled or insufficiently restricted.
No suspicious patterns detected.