GHSA-926X-3R5X-GFHW: Template Injection and Information Disclosure in LangChain Core

The LangChain framework relies on the langchain-core package to process and format prompt templates for Large Language Models (LLMs). This core library includes multiple template classes designed to construct complex prompts dynamically. A template injection vulnerability exists in this logic, specifically categorized as Improper Neutralization of Special Elements Used in a Template Engine (CWE-1336).

The vulnerability manifests when the application accepts untrusted input and uses it as an f-string template within DictPromptTemplate or ImagePromptTemplate classes. These specific classes lacked the necessary input validation hooks present in standard PromptTemplate objects. Consequently, the framework processes arbitrary f-string expressions without checking for dangerous attribute access or nested evaluation.

Exploitation requires two specific preconditions within the target application. First, the application must accept raw template strings directly from an untrusted user, rather than securely passing user input as variable values. Second, the application must supply "rich" Python objects (objects containing internal state, methods, or sensitive properties) to the template formatting engine.

The maintainers addressed this vulnerability in versions 0.3.84 and 1.2.28. The patch introduces a centralized, strict validation function that parses all f-string templates during instantiation. Applications running prior versions remain exposed to unauthorized data extraction if they meet the required preconditions.

The vulnerability originates from two distinct architectural oversights in the LangChain template processing pipeline. The first issue is incomplete class coverage across the template inheritance hierarchy. While standard PromptTemplate implementations contained safety checks to prevent attribute lookup, sibling classes like DictPromptTemplate and ImagePromptTemplate did not implement these same validation rules.

The second, more subtle oversight involves insufficient parsing of Python f-string format specifiers. Python's built-in f-string evaluation engine permits nested replacement fields within the format specifier segment (the portion following a colon, such as {variable:specifier}). The original validation routines in LangChain only examined the top-level field names to detect malicious attribute access.

By ignoring the format specifier string entirely, the validation logic created a bypass condition. An attacker could embed a malicious attribute lookup inside the specifier portion of the f-string. The incomplete parser would scan the innocuous top-level variable name, mark the template as safe, and pass it to the formatting engine.

When the application subsequently calls .format() on the malicious template, the Python interpreter resolves the entire expression. The evaluation engine processes the nested field, retrieves the internal object attribute, and embeds the sensitive data into the resulting string. This architectural gap fundamentally compromised the intended sandbox around template generation.

Prior to the patch, the DictPromptTemplate and ImagePromptTemplate classes accepted f-string templates directly without verifying the internal structure of the formatting fields. The application relied on standard Python string formatting, which naturally supports object attribute access via dot notation and dictionary lookups via brackets.

The LangChain developers resolved this by introducing a centralized function named validate_f_string_template. This function utilizes Python's string.Formatter().parse() method to extract all literal text, field names, format specifiers, and conversion flags from the template string. This approach ensures complete visibility into the template structure.

# Annotated pseudo-code based on the patched implementation
def validate_f_string_template(template: str) -> None:
    formatter = string.Formatter()
    for literal_text, field_name, format_spec, conversion in formatter.parse(template):
        if field_name is not None:
            # Prevent attribute access (e.g., obj.secret)
            if "." in field_name:
                raise ValueError("Attribute access is not permitted")
            # Prevent indexing (e.g., obj[0])
            if "[" in field_name or "]" in field_name:
                raise ValueError("Indexing is not permitted")
            # Prevent positional arguments (must use named kwargs)
            if field_name.isdigit():
                raise ValueError("Positional arguments are not permitted")
        if format_spec is not None:
            # Prevent nested format specifier evaluation
            if "{" in format_spec or "}" in format_spec:
                raise ValueError("Nested format specifiers are not permitted")

The fix applies these rules rigorously. The commit (6bab0ba3c12328008ddca3e0d54ff5a6151cd27b) integrates this validation directly into the Pydantic model_validator hooks for the affected classes. By enforcing the check at the deserialization and instantiation level, the framework guarantees that no unsafe template object can exist in memory.

An attacker targets this vulnerability by interacting with an application endpoint that accepts user-defined prompt templates. The attack relies on injecting specific syntax designed to exploit Python's string formatting capabilities. The primary goal is to extract internal state from objects passed to the template context.

The most direct attack vector involves passing dictionary templates containing bracket indexing. If the application supplies an object with a dictionary attribute, the attacker can submit a template such as {message.additional_kwargs[secret]}. During processing, the DictPromptTemplate evaluates the expression, extracting the target key.

To bypass legacy validation routines that only check the main field name, the attacker utilizes the nested format specifier technique. The payload {name:{name.__class__.__name__}} places the malicious payload (__class__.__name__) inside the format specifier context. The flawed parser analyzes only name, while the Python runtime evaluates the nested field.

Once the formatting operation completes, the template output contains the extracted application data. Depending on the application's design, this data might be returned directly to the attacker in an HTTP response, appended to a user-visible log, or sent to an LLM whose output the attacker can read. The exploitation requires no specialized tooling beyond standard HTTP clients.

The primary security impact of GHSA-926X-3R5X-GFHW is a breach of confidentiality. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N accurately reflects a network-accessible attack requiring low complexity and zero authentication. The impact is isolated to data extraction and does not directly compromise system integrity or availability.

The scope of the data disclosure depends entirely on the application's runtime context. Attackers can only access attributes of objects explicitly passed to the template engine. If an application developer passes a complex context object containing database credentials, internal API keys, or memory addresses, those precise assets become vulnerable to extraction.

This vulnerability does not facilitate arbitrary Remote Code Execution (RCE). Python's native .format() engine restricts expression evaluation to attribute lookup (via the dot operator) and item indexing (via brackets). It inherently prohibits function invocation or mathematical operations within the formatting context.

Despite the lack of RCE, the risk remains significant for enterprise applications. LLM orchestration frameworks frequently pass rich user sessions, system configurations, or authentication tokens into prompts for context generation. Extracting these objects allows attackers to conduct lateral movement or escalate privileges within the broader application ecosystem.

The definitive resolution requires upgrading the langchain-core dependency. System administrators and developers must update their environments to langchain-core version 0.3.84 or 1.2.28. Upgrading entirely neutralizes the vulnerability by implementing the strict validate_f_string_template parsing logic across all relevant classes.

Organizations unable to immediately apply the patch must implement architectural mitigations. Developers must enforce strict separation between user input and template structure. End-users should only supply variable values that populate developer-controlled templates, rather than defining the template string itself.

When applications absolutely must process rich Python objects within templates, developers must implement aggressive data sanitization. Before passing an object to a prompt template, convert it into a flat dictionary containing only primitive data types (strings, integers, booleans). This practice eliminates the hierarchical structures required for attribute extraction attacks.

Security teams should configure Web Application Firewalls (WAF) to inspect JSON payloads or form data destined for LLM endpoints. Rules should block input containing nested brace structures ({{...}}) or explicit attribute access patterns ({.*.}) in fields expected to contain text. While WAF rules provide defense-in-depth, they do not replace the fundamental requirement to patch the underlying dependency.