Malicious Go init() Function Spawning a Process via a Code-Generation Tool
An attacker submits Go source code to an AI-powered code-generation tool. The code contains a func init() that spawns a process — a Go feature that runs automatically the instant the package loads, no user interaction needed. When the tool later builds or restarts using that source, the attacker's command executes.
How the attack works
The attacker gets access to a code-generation feature in an AI development tool and submits Go source containing a func init() body. Inside that init() they place a call like os.StartProcess, exec.Command, or syscall.Exec. The attacker then triggers a build, rebuild, or service restart on that tool. Because init() runs the moment the compiled package loads, the process-spawning call executes immediately with no further action needed. This was first documented in gin-vue-admin, where an authenticated user injected code via one API endpoint and triggered a rebuild via another, causing calc.exe to launch, but the underlying pattern applies to any tool that compiles or loads attacker-supplied Go source without reviewing it.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 4deaa057-5625-4e4d-8230-5c5b152d7016
- Severity
- Critical
- CVEs
- CVE-2026-48787
Why it matters
An attacker who can submit code to an AI code-generation feature gains arbitrary command execution on the server or environment that builds and runs that code, effectively turning a development convenience feature into a remote code execution path.
What you can do
- →Require human review of any AI-generated or AI-submitted Go source before it is compiled or deployed, especially init() functions.
- →Restrict who can access code-generation and build/restart endpoints in internal developer tools; treat them as privileged actions.
- →Run code-generation build/compile steps in an isolated, sandboxed environment with no access to sensitive systems.
- →Scan generated source for process-spawning calls (os.StartProcess, exec.Command, syscall.Exec) inside init() before allowing a build to proceed.
Known benign look-alikes
- A legitimate CLI wrapper's init() that re-execs itself under a different UID or namespace -- rare but real; still worth a human check given how uncommon and high-impact process-spawning init() functions are
- Discussion/documentation showing this exact code pattern as a security example, without it being submitted to an actual code-generation/build tool