Jinja2 loop.index0 blocked by RestrictedSandboxedEnvironment when using template_format="jinja2"

[sagewe]

Checked other resources

• This is a bug, not a usage question.
• I added a clear and descriptive title that summarizes this issue.
• I used the GitHub search to find a similar question and didn't find it.
• I am sure that this is a bug in LangChain rather than my code.
• The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).
• This is not related to the langchain-community package.
• I posted a self-contained, minimal, reproducible example. A maintainer can copy it and run it AS IS.

Package (Required)

• langchain
• langchain-openai
• langchain-anthropic
• langchain-classic
• langchain-core
• langchain-cli
• langchain-model-profiles
• langchain-tests
• langchain-text-splitters
• langchain-chroma
• langchain-deepseek
• langchain-exa
• langchain-fireworks
• langchain-groq
• langchain-huggingface
• langchain-mistralai
• langchain-nomic
• langchain-ollama
• langchain-perplexity
• langchain-prompty
• langchain-qdrant
• langchain-xai
• Other / not sure / general

Example Code (Python)

from langchain_core.prompts.chat import ChatPromptTemplate

prompt = "{% for it in items %} {{ loop.index0 }}{% endfor %}"
items = [1, 2, 3]

message = ChatPromptTemplate.from_messages(
    messages=[("system", prompt)],
    template_format="jinja2",
).format_messages(
    items=items
)

print(message[0].content)

Error Message and Stack Trace (if applicable)

jinja2.exceptions.SecurityError: Access to attributes is not allowed in templates. Attempted to access 'index0' on LoopContext. Use only simple variable names like {{variable}} without dots or methods.

Description

Description

When using ChatPromptTemplate with template_format="jinja2", a simple Jinja2 template
that uses the built-in loop.index0 works correctly with plain Jinja2, but fails with
a jinja2.exceptions.SecurityError in LangChain.

I understand this is related to the security hardening described in the advisory
GHSA-6qv9-48xg-fc7f
where attribute access in templates is restricted. However, this also blocks standard
Jinja2 loop helpers such as loop.index0, which makes many existing Jinja2 templates
no longer usable with template_format="jinja2".

Relation to Security Advisory

According to the advisory GHSA-6qv9-48xg-fc7f, LangChain now uses a restricted/sandboxed
Jinja environment that forbids all attribute access (foo.bar) to prevent template
injection and data exfiltration.

In this case, loop.index0 is implemented as an attribute on LoopContext, so it is
also blocked by this rule. This means that:

• All standard Jinja2 loop helpers like loop.index0, loop.index, loop.length, etc.
  are unusable.
• Any template that relies on obj.field style access (even for harmless data models)
  will fail with SecurityError.

While this is understandable from a security perspective, it significantly changes the
behavior of template_format="jinja2" compared to plain Jinja2 and breaks many existing
templates.

Questions / Suggestions

• Is this strict “no attribute access at all” behavior for Jinja2 templates intended as
  the long-term design, or only a temporary hardening step?
  • Would it be possible to:
  • Provide a documented way to opt into a less restricted Jinja environment for
    trusted templates only, or
  • Clearly document that template_format="jinja2" does not support any a.b
    access (including loop.index0) so users know about this limitation up front?

Even a separate, explicitly “unsafe / trusted” mode (e.g., for applications that fully
control the template strings) would be very helpful.

System Info

System Information

OS: Darwin
OS Version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:28:30 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6030
Python Version: 3.11.11 (main, Mar 17 2025, 21:33:08) [Clang 20.1.0 ]

Package Information

langchain_core: 0.3.80
langchain: 0.3.27
langsmith: 0.4.15
langchain_text_splitters: 0.3.9
langgraph_sdk: 0.2.2

Optional packages not installed

langserve

Other Dependencies

async-timeout<5.0.0,>=4.0.0;: Installed. No version info available.
httpx<1,>=0.23.0: Installed. No version info available.
httpx>=0.25.2: Installed. No version info available.
jsonpatch<2.0.0,>=1.33.0: Installed. No version info available.
langchain-anthropic;: Installed. No version info available.
langchain-aws;: Installed. No version info available.
langchain-azure-ai;: Installed. No version info available.
langchain-cohere;: Installed. No version info available.
langchain-community;: Installed. No version info available.
langchain-core<1.0.0,>=0.3.72: Installed. No version info available.
langchain-deepseek;: Installed. No version info available.
langchain-fireworks;: Installed. No version info available.
langchain-google-genai;: Installed. No version info available.
langchain-google-vertexai;: Installed. No version info available.
langchain-groq;: Installed. No version info available.
langchain-huggingface;: Installed. No version info available.
langchain-mistralai;: Installed. No version info available.
langchain-ollama;: Installed. No version info available.
langchain-openai;: Installed. No version info available.
langchain-perplexity;: Installed. No version info available.
langchain-text-splitters<1.0.0,>=0.3.9: Installed. No version info available.
langchain-together;: Installed. No version info available.
langchain-xai;: Installed. No version info available.
langsmith-pyo3>=0.1.0rc2;: Installed. No version info available.
langsmith<1.0.0,>=0.3.45: Installed. No version info available.
langsmith>=0.1.17: Installed. No version info available.
openai-agents>=0.0.3;: Installed. No version info available.
opentelemetry-api>=1.30.0;: Installed. No version info available.
opentelemetry-exporter-otlp-proto-http>=1.30.0;: Installed. No version info available.
opentelemetry-sdk>=1.30.0;: Installed. No version info available.
orjson>=3.10.1: Installed. No version info available.
orjson>=3.9.14;: Installed. No version info available.
packaging<26.0.0,>=23.2.0: Installed. No version info available.
packaging>=23.2: Installed. No version info available.
pydantic<3,>=1: Installed. No version info available.
pydantic<3.0.0,>=2.7.4: Installed. No version info available.
pytest>=7.0.0;: Installed. No version info available.
PyYAML<7.0.0,>=5.3.0: Installed. No version info available.
PyYAML>=5.3: Installed. No version info available.
requests-toolbelt>=1.0.0: Installed. No version info available.
requests<3,>=2: Installed. No version info available.
requests>=2.0.0: Installed. No version info available.
rich>=13.9.4;: Installed. No version info available.
SQLAlchemy<3,>=1.4: Installed. No version info available.
tenacity!=8.4.0,<10.0.0,>=8.1.0: Installed. No version info available.
typing-extensions<5.0.0,>=4.7.0: Installed. No version info available.
vcrpy>=7.0.0;: Installed. No version info available.
zstandard>=0.23.0: Installed. No version info available.

[eyurtsev]

Thanks for the report! @sagewe

I'll consider reverting or lifting some of the restrictions, just need to figure out how to balance security concerns vs. functionality concerns for jinja2.

Even a separate, explicitly “unsafe / trusted” mode (e.g., for applications that fully
control the template strings) would be very helpful.

This could also be reasonable, but I'd prefer to see whether we're OK relaxing some aspects of jinja2 templating etc

---

Looking for feedback from the community:

• If you're relying on jinja2 templates, could you provide an example code snippet so we can see which functionality is neeeded?
• Are you aware that jinja2 templates should not be accepted from untrusted sources?

[keenborder786]

@eyurtsev see my approach, I think so we need to provide optional support?

[Jarv1s10]

@eyurtsev a small piece of feedback - my org uses jinja2 templates extensively for transformations of many internal pydantic schemas of domain entities into LLM-friendly format. This sudden break of such an important framework functionality is a bit surprising and frankly frustrating, even if I understand the reasoning behind it - especially because it was introduced in a patch release.
For now we will just pin langchain_core to 1.0.6 in our projects, but we would really appreciate some sort of opt-in "unsafe" mode to utilize full power of jinja2 templates. Thanks in advance!

[mikevoets]

@eyurtsev We love this package and this tool. But this is a breaking change for us. I wouldn't have expected this change to be a introduced in a patch version.

[eyurtsev]

@Jarv1s10 and @mikevoets could you provide an example of functionality you're relying on with jinja2 templates. (i.e., a few concrete code snippets)

@mikevoets could you confirm whether your jinja2 templates are from trusted vs. untrusted sources?

[mikevoets]

@eyurtsev

This is a snippet of where it failed for us:

{% if context_text and context_text.strip() %}
Retrieved Context:
{{ context_text }}
{% endif %}

jinja2.exceptions.SecurityError: Access to attributes is not allowed in templates. Attempted to access 'strip' on str. Use only simple variable names like {{variable}} without dots or methods.

The template is from a trusted source. The input context_text is also trusted.

[eyurtsev]

@mikevoets do you call methods on more complex types ever?

[mikevoets]

@mikevoets do you call methods on more complex types ever?

We primarily do things like:

context_text.strip()
eu.content[:140] ~ '...'
messages[-2].type.title()
for msg in ((messages[:-1])[-5:] | reverse)
"%.2f"|format(quality_gate.get('max_score', 0.0))

[Jarv1s10]

@Jarv1s10 and @mikevoets could you provide an example of functionality you're relying on with jinja2 templates. (i.e., a few concrete code snippets)

As an example of our usage, we have an email processing chain that utilizes the following email representation template

{% macro render_person(person) %}
    {% if person.name %}{{ person.name }} {% endif %}<{{ person.email_address }}>
{% endmacro %}

{% macro render_people(people) %}
    {% for person in people %}
        {{ render_person(person) }}{% if not loop.last %}; {% endif %}
    {% endfor %}
{% endmacro %}

Email was sent on {{ email.created_date.strftime("%A, %B %d, %Y, %H:%M") }}
Subject: {{ email.subject or "No Subject" }}
{% if email.From %}From: {{ render_people(email.From) }}
{% endif %}
{% if email.To %}To: {{ render_people(email.To) }}
{% endif %}
{% if email.CC %}CC: {{ render_people(email.CC) }}
{% endif %}
{% if email.BCC %}BCC: {{ render_people(email.BCC) }}
{% endif %}
Body:
{{ email.body.strip() }}

[eyurtsev]

OK I'll discuss with the team about reverting changes to jinja2 next week. Use cases look valid, and the restrictions to jinja2 seem to just make it unusable for templating for internal use cases.