Summary
datamodel-code-generator between versions 0.17.0 and 0.60.2 preserves attacker-controlled default_factory values when generating Python models from schemas.
If an attacker can influence the input schema, they can cause arbitrary Python expressions to be emitted into Field(default_factory=...) or field(default_factory=...), leading to code execution when the generated models are imported.
datamodel-code-generator between versions 0.17.0 and 0.60.2 preserves attacker-controlled default_factory values when generating Python models from schemas.
If an attacker can influence the input schema, they can cause arbitrary Python expressions to be emitted into Field(default_factory=...) or field(default_factory=...), leading to code execution when the generated models are imported.
Affected context
This vulnerability arises in workflows where Python models are automatically generated from external specifications such as OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, or raw JSON/YAML/CSV.
It is most relevant when:
- Schemas are partially or fully controlled by external parties (e.g., partners, tenants, or untrusted input sources)
- Generated models are committed to source control or imported in application code without manual review
- default_factory metadata from the schema is trusted and directly translated into Python expressions
This vulnerability arises in workflows where Python models are automatically generated from external specifications such as OpenAPI, JSON Schema, GraphQL, Avro, Protobuf, or raw JSON/YAML/CSV.
It is most relevant when:
- Schemas are partially or fully controlled by external parties (e.g., partners, tenants, or untrusted input sources)
- Generated models are committed to source control or imported in application code without manual review
- default_factory metadata from the schema is trusted and directly translated into Python expressions
Exploit preconditions
- Attack surface: The schema input consumed by datamodel-code-generator (JSON Schema, OpenAPI, etc.)
- Required access: Ability to modify or supply a schema that will be processed by datamodel-code-generator
- Trigger point: Importing or executing the generated Python models containing malicious default_factory expressions
- Why exploitation is possible: The generator passes attacker-controlled default_factory values through JsonSchemaObject.init and get_field_extras into Field(default_factory=...) or field(default_factory=...) without validation or sanitization, treating them as executable Python callables.
- Attack surface: The schema input consumed by datamodel-code-generator (JSON Schema, OpenAPI, etc.)
- Required access: Ability to modify or supply a schema that will be processed by datamodel-code-generator
- Trigger point: Importing or executing the generated Python models containing malicious default_factory expressions
- Why exploitation is possible: The generator passes attacker-controlled default_factory values through JsonSchemaObject.init and get_field_extras into Field(default_factory=...) or field(default_factory=...) without validation or sanitization, treating them as executable Python callables.
Why this happens
The core issue maps to CWE-94: Improper Control of Generation of Code and is closely related to CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine.
datamodel-code-generator treats schema-supplied default_factory values as trusted configuration and directly embeds them into generated Python source code.
Because these values are emitted into Field(default_factory=...) or field(default_factory=...) constructs, an attacker can craft schema metadata that becomes arbitrary Python expressions.
When the generated modules are imported, Python evaluates these expressions, effectively turning data-driven configuration into executable code without enforcing clear trust boundaries or sanitizing template inputs.
The core issue maps to CWE-94: Improper Control of Generation of Code and is closely related to CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine.
datamodel-code-generator treats schema-supplied default_factory values as trusted configuration and directly embeds them into generated Python source code.
Because these values are emitted into Field(default_factory=...) or field(default_factory=...) constructs, an attacker can craft schema metadata that becomes arbitrary Python expressions.
When the generated modules are imported, Python evaluates these expressions, effectively turning data-driven configuration into executable code without enforcing clear trust boundaries or sanitizing template inputs.
Potential impact
- Arbitrary Python code execution during import of generated models
- Compromise of development tools, build pipelines, or code generation servers
- Theft or corruption of sensitive data processed by applications using the generated models
- Lateral movement from code generation environments into broader infrastructure
- Introduction of persistent backdoors via malicious logic embedded in generated source files
- Arbitrary Python code execution during import of generated models
- Compromise of development tools, build pipelines, or code generation servers
- Theft or corruption of sensitive data processed by applications using the generated models
- Lateral movement from code generation environments into broader infrastructure
- Introduction of persistent backdoors via malicious logic embedded in generated source files
General mitigation guidance
Effective mitigation focuses on reducing trust in schema-driven code generation and constraining how dynamic values are translated into executable Python.
Pattern-based defensive approaches include:
- Treating schema metadata, especially default_factory and similar hooks, as untrusted input and blocking or strictly validating it before incorporating into generated code
- Restricting generators to use only a fixed set of safe default factories (e.g., built-in collection constructors) rather than arbitrary expressions
- Separating data description from execution logic: avoid emitting callables or code paths derived directly from external schema content
- Running code generation tools in isolated, least-privilege environments to limit blast radius if malicious code is produced
- Encouraging manual or automated review of generated source files, especially any dynamic constructs, before they are imported by production applications
Effective mitigation focuses on reducing trust in schema-driven code generation and constraining how dynamic values are translated into executable Python.
Pattern-based defensive approaches include:
- Treating schema metadata, especially default_factory and similar hooks, as untrusted input and blocking or strictly validating it before incorporating into generated code
- Restricting generators to use only a fixed set of safe default factories (e.g., built-in collection constructors) rather than arbitrary expressions
- Separating data description from execution logic: avoid emitting callables or code paths derived directly from external schema content
- Running code generation tools in isolated, least-privilege environments to limit blast radius if malicious code is produced
- Encouraging manual or automated review of generated source files, especially any dynamic constructs, before they are imported by production applications
How teams detect issues like this
Detection generally centers on inspecting both generator behavior and the resulting source code:
- Static analysis rules that flag generated code where default_factory or similar parameters reference non-whitelisted callables or suspicious expressions
- Code review checklists highlighting generated models as high-risk artifacts, with special attention to Field(default_factory=...) and field(default_factory=...) usage
- Template and generator security policies that forbid direct embedding of externally supplied expressions into code, enforced via CI hooks or pre-commit checks
- Periodic scans of repositories for patterns indicative of schema-driven injection (e.g., unusual lambdas, eval-like constructs, or imports appearing only in generated files)
- Use of automated code review tools to monitor code generation outputs for dangerous constructs, while keeping tool configuration focused on pattern detection rather than specific versions
Detection generally centers on inspecting both generator behavior and the resulting source code:
- Static analysis rules that flag generated code where default_factory or similar parameters reference non-whitelisted callables or suspicious expressions
- Code review checklists highlighting generated models as high-risk artifacts, with special attention to Field(default_factory=...) and field(default_factory=...) usage
- Template and generator security policies that forbid direct embedding of externally supplied expressions into code, enforced via CI hooks or pre-commit checks
- Periodic scans of repositories for patterns indicative of schema-driven injection (e.g., unusual lambdas, eval-like constructs, or imports appearing only in generated files)
- Use of automated code review tools to monitor code generation outputs for dangerous constructs, while keeping tool configuration focused on pattern detection rather than specific versions
