Safe By Default or Vulnerable By Design? Golang Server Side Template Injection

What is Server-Side Templating?

Templating is the process of generating dynamic text output on the server by combining static templates with runtime data. For example, applications leverage server-side templating to generate dynamic HTML responses on the backend, by combining templates with data before sending it to a user’s browser. The approach keeps sensitive logic server-side, while improving performance, simplifying frontend complexity, and enables cleaner separation between presentation and business logic. 

Server‑Side Template Injection (SSTI) 

Server‑Side Template Injection occurs when untrusted user input is fed directly into a server‑side templating engine or via insufficiently filtered parameters. Through this, attackers gain the ability to evaluate arbitrary expressions inside the template’s execution context, which can lead to a variety of attack scenarios like:

• Remote Code Execution (RCE) 
• Arbitrary file‑system read/write
• Disclosure of application secrets and internal structures
• XSS, logic‑bypass (for example authentication bypass) or mass assignment
• Denial‑of‑Service

SSTI in Golang: An Attack Surface in the Shadows

Go’s built-in templating engines allow developers to create flexible, data-driven responses while keeping logic and rendering on the server-side. 

Go’s standard libraries (text/template & html/template) are often described as “safe by default,” yet real‑world usage patterns regularly pierce those guarantees:

1. Context‑unaware execution – Developers concatenate user‑controlled strings or call Execute/ExecuteTemplate on templates built from HTTP parameters.
2. Logic helper functions – Go templates allow callers to register arbitrary Go functions (template.FuncMap). If a function ends up referencing os/exec, io/ioutil, or reflection helpers, the path to RCE is short. Attackers can use the helpers for execution.
3. Error channel leaks – During parsing/execution, template errors can disclose Go types, package paths and even fragments of source code.

A key challenge with SSTI vulnerabilities is that many of them are shadow vulnerabilities, meaning they do not carry a CVE identifier. Effectively, the template engine is “vulnerable by design”, and behaves as designed, but packages, third, and first party code expose its primitives to user input.

The risk is very much real, just underreported. So why don’t we see a flood of Golang SSTI CVEs?

• Smaller ecosystem of template libraries compared to Python/Java.
• Limited security research attention (most bug hunters target Jinja2, Freemarker, Handlebars, etc.).
• Exploitation requires Go‑specific primitives and context, so existing fuzzers may miss those cases.

Why Traditional Defenses Miss Golang SSTI Exploitations

Conventional security layers, such as EDRs and CWPPs, watch operating-system events, but the layer where Golang SSTI starts lies outside their line of sight. Lacking applicative context, they register only the downstream symptoms - subprocesses, file access, or outbound calls.
By the time an alert fires, the injection has already succeeded, and defenders are left chasing payloads instead of blocking the exploit’s entry point.

In addition, existing WAF signature-based detections are typically handcrafted for well-known payloads and patterns seen in Java and Python template engines. Those rules rarely map to Go’s template syntax, and attackers can sidestep them with a small change in variable names, whitespace, or encoding. The result: real Golang SSTI traffic slips through unnoticed, while harmless activity can still trigger noise.

Oligo closes this blind spot by observing execution as the template is rendered, identifying malicious behavior at its origin and preventing it from propagating further.

Oligo’s Solution: Detection and Prevention of Golang SSTI exploitation

Powered by Deep Application Inspection (DAI), Oligo provides visibility into how different application components behave in runtime, delivering:

• Applicative Execution Context – Oligo’s sensor provides high-resolution data regarding the applicative components that are responsible for operation execution. When a template is rendered and executed by a template engine, the executed operations are visible with full context.
• Template‑aware syscall map – Oligo maintains a profile of safe operations (string concatenations, HTML escaping). Any deviation, such as spawning a process, opening an unexpected file handle, or network operation, triggers an alert.
• Rich Context - Oligo stitches the applicative call‑stack, executed payload, and process metadata, showing exactly which template ran what code and where.
• Zero‑day coverage – Because detection is driven by runtime behavior (and the effect of injection), Oligo protects even when the underlying vulnerability is undiscovered (Shadow vulnerability).

In short, Oligo closes the observability gap that makes Golang SSTI so sneaky: it surfaces template‑context operations in real time, blocks malicious executions, and gives the users a forensics trail to not only identify, but fix the root cause.

Video Demonstration

The following proof-of-concept video demonstrates a Golang server built on the Echo web framework that is vulnerable to Server-Side Template Injection (SSTI). By exploiting this vulnerability, an attacker can retrieve sensitive values, such as stored passwords, and execute arbitrary operating-system commands. In our demo, we invoke the command to list directory contents. Throughout the exploit, Oligo seamlessly detects the attack in real time and uncovers the unnoticed “shadow” vulnerability, showcasing its ability to alert on initial access and reveal hidden security gaps.

‍

‍