Skip to content

Code execution on import via unescaped `validators` entries in --extra-template-data

High
koxudaxi published GHSA-8m8r-38jm-f355 Jun 8, 2026

Package

pip datamodel-code-generator (pip)

Affected versions

>= 0.52.1, <= 0.60.1

Patched versions

0.60.2

Description

Summary

When the Pydantic v2 output mode is in use, datamodel-code-generator reads a validators array from each model entry in the --extra-template-data file and synthesises a Pydantic @field_validator(...) decorator from each entry. The field names and the validator mode are interpolated into the decorator call wrapped in unescaped single quotes. A value containing ' breaks out of the string literal, letting an attacker emit an arbitrary positional Python expression into the decorator. The expression is evaluated at class-definition time, i.e. the moment the developer imports the generated module. This is the same trust model as the recently-published GHSA-wjv6-jcfj-mf9r (extras-file comment injection) but the impact is full RCE rather than a docstring leak.

Details

Sink: src/datamodel_code_generator/model/pydantic_v2/base_model.py, _process_validators (lines 405–449, at tag 0.60.1 / commit a321547e):

def _process_validators(self) -> None:
    validators = self.extra_template_data.get("validators")
    if not validators:
        return
    ...
    for validator in validators:
        fields = validator.get("fields") or [validator.get("field")]
        fields = [f for f in fields if f]
        if not fields:
            continue
        function_path: str = validator["function"]
        function_name = function_path.rsplit(".", 1)[-1]
        mode = validator.get("mode", "after")
        fields_str = ", ".join(f"'{f}'" for f in fields)     # (A) UNESCAPED
        ...
        mode_str = f"mode='{mode}'"                          # (B) UNESCAPED
        prepared_validators.append({
            "fields_str": fields_str,
            "mode_str":   mode_str,
            "method_name": method_name,
            "function_name": function_name,
            "mode": mode,
        })
        self._additional_imports.append(Import.from_full_path(function_path))  # (C)

The strings from (A) and (B) flow verbatim into src/datamodel_code_generator/model/template/pydantic_v2/BaseModel.jinja2:

@field_validator({{ v.fields_str }}, {{ v.mode_str }})

There is no repr() call, no identifier check, and no quote-escaping.

Secondary sink at (C): Import.from_full_path(function_path) splits on the last . and emits from <prefix> import <suffix>. A ; in function_path therefore lands in the generated import line and runs as a statement at module load.

PoC

A self-contained one-file PoC is available here: https://gist.github.com/thegr1ffyn/34d5c647e74487ffb2be27c76dace2aa

Impact

Arbitrary code execution in the developer's interpreter / CI runner the moment the generated module is imported. Anyone who accepts a --extra-template-data file from an untrusted source is impacted:

  • Pull requests adding or modifying project-local *.template-data.json / .codegen.json files consumed by a make codegen rule or pre-commit hook.
  • Configuration snippets pasted from issue templates, READMEs, or third-party guides.
  • Multi-tenant CI systems where one tenant's config file is read by another tenant's build.

Same blast radius as GHSA-wjv6-jcfj-mf9r, but silent RCE rather than a docstring leak — significantly higher impact under the same threat model.

Introduced in 0.52.1 by commit a2b27562 (Add --validators option for Pydantic v2 field validators).

Resolution

The fix validates validators entries with Pydantic models before rendering them. Field names must be valid non-keyword Python identifiers, function must be a dotted Python identifier path, and mode must be one of Pydantic's supported validator modes. The generated decorator arguments now render field names with repr() and mode with !r, so validated values are still emitted as Python string literals.

Remediation

Upgrade to datamodel-code-generator 0.60.2 or later.

This issue affects datamodel-code-generator versions >= 0.52.1, <= 0.60.1 and is fixed in 0.60.2.

Submitted by: Hamza Haroon (thegr1ffyn)

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CVE ID

CVE-2026-54656

Weaknesses

Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. Learn more on MITRE.

Credits