Summary
datamodel-code-generator improperly renders attacker-controlled comment data into Python source files without neutralizing line breaks.
If an attacker can influence the --extra-template-data comment field, they can inject arbitrary Python code into generated models that executes when those modules are imported.
datamodel-code-generator improperly renders attacker-controlled comment data into Python source files without neutralizing line breaks.
If an attacker can influence the --extra-template-data comment field, they can inject arbitrary Python code into generated models that executes when those modules are imported.
Affected context
The vulnerability appears in workflows that use datamodel-code-generator (versions 0.14.1 through 0.60.2) to produce Python models from schemas while passing untrusted or partially trusted values into the --extra-template-data comment field.
The affected Jinja2 templates include multiple model types (TypeAliasAnnotation, TypedDict, dataclass, msgspec.Struct, and Pydantic BaseModel variants), all of which embed this comment into #-style Python comments.
When the comment value contains carriage returns or newlines, it can prematurely terminate the comment and inject additional Python code into the generated file.
The vulnerability appears in workflows that use datamodel-code-generator (versions 0.14.1 through 0.60.2) to produce Python models from schemas while passing untrusted or partially trusted values into the --extra-template-data comment field.
The affected Jinja2 templates include multiple model types (TypeAliasAnnotation, TypedDict, dataclass, msgspec.Struct, and Pydantic BaseModel variants), all of which embed this comment into #-style Python comments.
When the comment value contains carriage returns or newlines, it can prematurely terminate the comment and inject additional Python code into the generated file.
Exploit preconditions
- Attack surface: The model generation pipeline that invokes datamodel-code-generator, particularly its template rendering layer.
- Required access: Ability to control or significantly influence the
--extra-template-datacomment field (direct CLI use, CI/CD configuration, upstream schema-to-template mapping, or template data injection). - Trigger point: Generation of Python models and subsequent import or execution of the generated modules in any runtime (development, CI, or production).
- Why exploitation is possible: The generator writes user-supplied comment text directly inside Python
#comments without sanitizing carriage returns or newlines. This allows the comment to break out of the comment context, turning the remainder of the input into executable Python code in the generated file.
- Attack surface: The model generation pipeline that invokes datamodel-code-generator, particularly its template rendering layer.
- Required access: Ability to control or significantly influence the
--extra-template-datacomment field (direct CLI use, CI/CD configuration, upstream schema-to-template mapping, or template data injection). - Trigger point: Generation of Python models and subsequent import or execution of the generated modules in any runtime (development, CI, or production).
- Why exploitation is possible: The generator writes user-supplied comment text directly inside Python
#comments without sanitizing carriage returns or newlines. This allows the comment to break out of the comment context, turning the remainder of the input into executable Python code in the generated file.
Why this happens
The root cause is untrusted data being injected into code templates without appropriate context-aware encoding or validation.
In the Jinja2 templates, the comment field from --extra-template-data is rendered inside Python line comments (using #) as if it were harmless metadata. However, Python treats line comments as ending at the first newline, so any embedded carriage return or newline in the comment value effectively closes the comment early.
This behavior turns what should be passive documentation into an execution vector: the remainder of the attacker-controlled input appears as active Python statements below the comment, mapping directly to CWE-94: Improper Control of Generation of Code.
Additionally, it relates to templating misuse patterns such as CWE-1336, where template engines combine control and data channels without enforcing output encoding rules for generated source code.
The root cause is untrusted data being injected into code templates without appropriate context-aware encoding or validation.
In the Jinja2 templates, the comment field from --extra-template-data is rendered inside Python line comments (using #) as if it were harmless metadata. However, Python treats line comments as ending at the first newline, so any embedded carriage return or newline in the comment value effectively closes the comment early.
This behavior turns what should be passive documentation into an execution vector: the remainder of the attacker-controlled input appears as active Python statements below the comment, mapping directly to CWE-94: Improper Control of Generation of Code.
Additionally, it relates to templating misuse patterns such as CWE-1336, where template engines combine control and data channels without enforcing output encoding rules for generated source code.
Potential impact
- Execution of arbitrary Python code whenever the generated model modules are imported.
- Compromise of applications or services that rely on the generated models as a core dependency.
- Theft or tampering of data processed by the application, including modification of business logic or validation rules.
- Installation of backdoors or persistence mechanisms inside generated model packages or downstream environments.
- Lateral movement within CI/CD pipelines or developer environments that automatically build and test generated models.
- Execution of arbitrary Python code whenever the generated model modules are imported.
- Compromise of applications or services that rely on the generated models as a core dependency.
- Theft or tampering of data processed by the application, including modification of business logic or validation rules.
- Installation of backdoors or persistence mechanisms inside generated model packages or downstream environments.
- Lateral movement within CI/CD pipelines or developer environments that automatically build and test generated models.
General mitigation guidance
Effective mitigation focuses on treating template data as untrusted and enforcing strict encoding for code-generation contexts.
Recommended defensive patterns include:
- Sanitizing or normalizing the
comment(and similar metadata fields) before rendering, removing or escaping newline and carriage-return characters when embedding into single-line comments. - Using context-aware templating helpers that automatically escape or encode user data for the specific output context (e.g., Python comment, string literal, identifier).
- Restricting the sources of
--extra-template-datato trusted configuration files and disallowing direct end-user input from flowing into template metadata. - Applying the principle of least privilege to generated code usage: avoid importing generated modules at high-privilege bootstrap points when possible, and segregate their execution environment.
- Establishing review or approval gates around changes to code-generation configuration, templates, and extra template data.
Effective mitigation focuses on treating template data as untrusted and enforcing strict encoding for code-generation contexts.
Recommended defensive patterns include:
- Sanitizing or normalizing the
comment(and similar metadata fields) before rendering, removing or escaping newline and carriage-return characters when embedding into single-line comments. - Using context-aware templating helpers that automatically escape or encode user data for the specific output context (e.g., Python comment, string literal, identifier).
- Restricting the sources of
--extra-template-datato trusted configuration files and disallowing direct end-user input from flowing into template metadata. - Applying the principle of least privilege to generated code usage: avoid importing generated modules at high-privilege bootstrap points when possible, and segregate their execution environment.
- Establishing review or approval gates around changes to code-generation configuration, templates, and extra template data.
How teams detect issues like this
Detection can rely on both static analysis of generated artifacts and review of the code-generation pipeline:
- Scan generated Python files for suspicious patterns where comments are immediately followed by unexpected executable code derived from template metadata.
- Implement static analysis rules that flag the use of raw, unvalidated template variables inserted into code comments, code blocks, or string literals in generator templates.
- During code review, require scrutiny of Jinja2 templates and configuration options such as
--extra-template-datato ensure that all user-controllable fields are safely encoded for their output context. - Use automated security review tools or linters in CI to analyze both the generator's templates and the resulting generated code for common code injection signatures.
Detection can rely on both static analysis of generated artifacts and review of the code-generation pipeline:
- Scan generated Python files for suspicious patterns where comments are immediately followed by unexpected executable code derived from template metadata.
- Implement static analysis rules that flag the use of raw, unvalidated template variables inserted into code comments, code blocks, or string literals in generator templates.
- During code review, require scrutiny of Jinja2 templates and configuration options such as
--extra-template-datato ensure that all user-controllable fields are safely encoded for their output context. - Use automated security review tools or linters in CI to analyze both the generator's templates and the resulting generated code for common code injection signatures.
