Summary
datamodel-code-generator vulnerable to code execution on import via x-python-type JSON-Schema extension in datamodel-code-generator
datamodel-code-generator honours a custom x-python-type JSON-Schema extension that lets a schema author override the generated Python type for a field. The value is forwarded verbatim into the generated Python source as the field annotation, with a single sanitisation pass that is trivial to bypass. An attacker who controls a JSON Schema fed to datamodel-codegen can therefore embed an arbitrary Python statement in the generated module, which executes at class-definition time the moment the developer imports the file. No --extra-template-data and no special flags are required; the vulnerable code is reachable with default settings.
Details
Sink: src/datamodel_code_generator/parser/jsonschema.py, _get_python_type_override (lines 2055–2096, at tag 0.60.1 / commit a321547e):
def _get_python_type_override(self, obj: JsonSchemaObject) -> DataType | None:
x_python_type = obj.extras.get("x-python-type")
if not x_python_type or not isinstance(x_python_type, str):
return None
schema_type = obj.type if isinstance(obj.type, str) else None
if self._is_compatible_python_type(schema_type, x_python_type):
return None
base_type = self._get_python_type_base(x_python_type)
import_ = self._resolve_type_import(base_type)
type_str = x_python_type
prefix = x_python_type.split("[", maxsplit=1)[0]
if "." in prefix: # only sanitiser
type_str = base_type + x_python_type[len(prefix):]
...
...
result = self.data_type(type=type_str, import_=import_)
...
return result
DataType.type flows unescaped into {{ field.type_hint }} in every model template
(model/template/pydantic_v2/BaseModel.jinja2,model/template/dataclass.jinja2,model/template/TypedDictClass.jinja2,model/template/msgspec.jinja2, …).
The only sanitiser, the dot-rewrite at the marked line, fires only when . is in the substring before the first [ in the value. Placing [ early (e.g. X[1]; <payload>) keeps prefix == "X" so the rewrite is skipped and the whole value lands in the generated annotation.
from __future__ import annotations (emitted by default) makes the X[1] portion a lazy string, so X does not need to resolve at runtime. Everything after ; is parsed as a real statement in the class body and is executed when the class is constructed during import.
Output-model types confirmed vulnerable in testing: pydantic_v2.BaseModel, dataclasses.dataclass, typing.TypedDict. msgspec.Struct emits structurally identical code.
PoC
A self-contained PoC is available at: https://gist.github.com/thegr1ffyn/1a7ff2561a581074c49785230b2c5700
Resolution
The fix validates x-python-type before constructing the generated type annotation. The value is parsed with ast.parse(..., mode="eval") and accepted only when the AST is shaped like a Python type annotation, including names, attributes, subscripts, tuple/list annotation arguments, | unions, and safe literal values where annotation syntax allows them. Statements, calls, and other executable expressions are rejected before code generation. The validator is cached to avoid repeated AST parsing for repeated values.
Submitted by: Hamza Haroon (thegr1ffyn)
Impact
Arbitrary code execution in the developer's interpreter / CI runner as soon as the generated module is imported. Reachable from any workflow that ingests an untrusted JSON Schema:
- OpenAPI / JSON-Schema documents fetched from third-party services or public registries.
- Customer-supplied schemas in B2B platforms that auto-generate client SDKs from user input.
- Schema files added by a malicious commit in a polyglot repository that triggers CI code generation.
The compromise is silent: the schema is valid JSON, the generator emits syntactically clean Python (the trojan statement is a single indented line in the class body), and only the use of the generated file triggers the payload.
Anyone running datamodel-codegen against an attacker-supplied schema is impacted. CI runners and developer workstations are the primary blast radius.
Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.
CVE-2026-54655 has a CVSS score of 7.8 (High). The vector is requires local access, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.60.2); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Upgrade to datamodel-code-generator 0.60.2 or later.
This issue affects datamodel-code-generator versions >= 0.51.0, <= 0.60.1 and is fixed in 0.60.2.
Frequently Asked Questions
- What is CVE-2026-54655? CVE-2026-54655 is a high-severity code injection vulnerability in datamodel-code-generator (pip), affecting versions >= 0.51.0, <= 0.60.1. It is fixed in 0.60.2. Untrusted input is evaluated as executable code within the application's runtime environment.
- How severe is CVE-2026-54655? CVE-2026-54655 has a CVSS score of 7.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of datamodel-code-generator are affected by CVE-2026-54655? datamodel-code-generator (pip) versions >= 0.51.0, <= 0.60.1 is affected.
- Is there a fix for CVE-2026-54655? Yes. CVE-2026-54655 is fixed in 0.60.2. Upgrade to this version or later.
- Is CVE-2026-54655 exploitable, and should I be worried? Whether CVE-2026-54655 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54655 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54655? Upgrade
datamodel-code-generatorto 0.60.2 or later.