From Template Injection to Cloud Takeover: A Practical Path to RCE and Metadata Access

TLDR: This research demonstrates how a seemingly minor Server-Side Template Injection (SSTI) vulnerability in a web application can be escalated to full Remote Code Execution (RCE). By abusing template engine features, an attacker can gain access to the underlying cloud environment, specifically targeting the instance metadata service to steal service account tokens. For pentesters, this highlights the critical need to test every user-controlled input field for template injection, even when the application appears to be a simple email or notification service.

Modern web applications often rely on template engines to dynamically generate content, but developers frequently overlook the security implications of allowing user-controlled input within these templates. When an application takes user input and processes it through an engine like Twig or Jinja2, it creates a massive attack surface. If the application fails to properly sanitize this input, an attacker can inject template syntax to execute arbitrary code on the server. This is not just a theoretical risk; it is a direct path to full system compromise.

The Mechanics of SSTI Exploitation

Server-Side Template Injection occurs when an application embeds user input into a template instead of treating it as raw data. The engine interprets the input as code, allowing the attacker to break out of the intended context. In many cases, developers assume that because they are not using dangerous functions like eval() in their own code, they are safe. However, template engines often provide built-in functions or filters that can be abused to access native system capabilities.

For example, when dealing with Twig, an attacker can use filters like map and join to manipulate data and eventually reach PHP functions that allow for system command execution. A common payload involves passing a command through these filters to bypass basic restrictions. Once the template engine processes the payload, it compiles it into executable code that the server then runs.

Consider this payload structure for a Twig-based application:

{{ ['cat /etc/passwd'] | map('passthru') | join }}

In this scenario, the map filter passes the string to the passthru function, which executes the system command. The join filter then concatenates the output. When the server renders the template, it executes the command and returns the contents of the sensitive file. This technique is highly effective because it leverages the engine's own features against itself, making it difficult for traditional signature-based security tools to detect.

Escalating to Cloud Environment Compromise

Achieving RCE is only the first step. In modern cloud-native environments, the real prize is the underlying infrastructure. Most applications running on platforms like GCP, AWS, or Azure are hosted on virtual machines or containers that have access to an Instance Metadata Service. This service is designed to provide the instance with information about its environment, including temporary security credentials.

Once you have RCE, you can query the metadata endpoint to retrieve the access token for the service account attached to the instance. This token often carries significant permissions, allowing you to move laterally within the cloud environment. You can use these credentials to list storage buckets, modify configurations, or even gain access to other services within the project.

To retrieve the token on a GCP instance, you would typically use a command like this:

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

The resulting JSON response contains an access token that you can use to authenticate as the service account. If the developer has assigned overly permissive roles to this account, you effectively inherit those privileges. This is a classic example of how a web-level vulnerability leads to a full-scale cloud breach.

Practical Testing for Pentesters

During a penetration test or bug bounty engagement, you should always look for signs of template injection in any field that reflects user input. This includes email subjects, notification templates, or even custom report generators. If you see an application that allows you to customize messages or templates, treat it as a high-priority target.

Start by testing with simple mathematical expressions. If you input {{ 7*7 }} and the application returns 49, you have confirmed that the input is being evaluated by a template engine. Once you confirm the presence of the vulnerability, you can begin crafting more complex payloads to achieve RCE. If the application is restrictive, look for research on SSTI exploitation to find bypass techniques for specific engines.

Defensive Considerations

The most effective way to prevent SSTI is to never allow users to create or control templates. If you must allow user input, treat it as untrusted data and use the appropriate escaping mechanisms provided by your framework. Additionally, ensure that your application is not running with excessive privileges. If the application is compromised, the service account attached to the instance should have the minimum permissions necessary to perform its job, following the Principle of Least Privilege.

Defenders should also monitor for unusual outbound network traffic from their web servers. An attacker who has achieved RCE will often attempt to establish a reverse shell or reach out to the metadata service. Implementing egress filtering can prevent these connections, effectively neutralizing the impact of an RCE vulnerability even if the initial injection is successful.

Security is not about building a wall that cannot be climbed; it is about ensuring that if an attacker gets over the wall, they have nowhere to go. Keep testing, keep digging, and never assume that a "simple" feature is secure.