Summary
XML Schema parsing in datamodel-code-generator follows schemaLocation references outside the intended base path, enabling unauthorized local file reads during model generation.
When attackers can influence XML Schema inputs or referenced locations, they may exfiltrate local file contents into the generated Python models.
XML Schema parsing in datamodel-code-generator follows schemaLocation references outside the intended base path, enabling unauthorized local file reads during model generation.
When attackers can influence XML Schema inputs or referenced locations, they may exfiltrate local file contents into the generated Python models.
Affected context
This vulnerability affects projects that use datamodel-code-generator with --input-file-type xmlschema to generate Python models from XML Schema definitions.
Risk arises when the tool processes schemas containing xs:include, xs:import, xs:redefine, or xs:override with attacker-controlled or untrusted schemaLocation values.
The issue appears in environments where the generator runs on machines that store sensitive files accessible via the same filesystem, and where generated models can be inspected or exfiltrated.
This vulnerability affects projects that use datamodel-code-generator with --input-file-type xmlschema to generate Python models from XML Schema definitions.
Risk arises when the tool processes schemas containing xs:include, xs:import, xs:redefine, or xs:override with attacker-controlled or untrusted schemaLocation values.
The issue appears in environments where the generator runs on machines that store sensitive files accessible via the same filesystem, and where generated models can be inspected or exfiltrated.
Exploit preconditions
- Attack surface: The XML Schema input and any referenced XSDs used by datamodel-code-generator.
- Required access: Ability to supply or modify an XML Schema, or to influence
schemaLocationvalues in referenced schema files. - Trigger point: Running datamodel-code-generator with
--input-file-type xmlschemaso that the parser resolvesxs:include,xs:import,xs:redefine, orxs:override. - Why exploitation is possible: The XML Schema parser resolves
schemaLocationpaths without constraining them to the original input base directory, enabling traversal to arbitrary readable files whose contents can be reflected into the generated code.
- Attack surface: The XML Schema input and any referenced XSDs used by datamodel-code-generator.
- Required access: Ability to supply or modify an XML Schema, or to influence
schemaLocationvalues in referenced schema files. - Trigger point: Running datamodel-code-generator with
--input-file-type xmlschemaso that the parser resolvesxs:include,xs:import,xs:redefine, orxs:override. - Why exploitation is possible: The XML Schema parser resolves
schemaLocationpaths without constraining them to the original input base directory, enabling traversal to arbitrary readable files whose contents can be reflected into the generated code.
Why this happens
The root cause is insufficient validation and restriction of filesystem paths when resolving XML Schema schemaLocation references.
Instead of enforcing a strict base directory or whitelist, the parser in xmlschema.py allows xs:include, xs:import, xs:redefine, and xs:override to point to locations outside the input base path.
This behavior aligns with CWE-22 (Path Traversal) and CWE-610 (Externally Controlled Reference to a Resource in Another Sphere), as untrusted schema inputs control which local resources are loaded, leading to CWE-200 (Information Exposure) when file contents are echoed into generated models.
The root cause is insufficient validation and restriction of filesystem paths when resolving XML Schema schemaLocation references.
Instead of enforcing a strict base directory or whitelist, the parser in xmlschema.py allows xs:include, xs:import, xs:redefine, and xs:override to point to locations outside the input base path.
This behavior aligns with CWE-22 (Path Traversal) and CWE-610 (Externally Controlled Reference to a Resource in Another Sphere), as untrusted schema inputs control which local resources are loaded, leading to CWE-200 (Information Exposure) when file contents are echoed into generated models.
Potential impact
- Local filesystem disclosure of readable files accessible to the code generation process
- Exposure of configuration files, API keys, or secrets embedded in local resources
- Leakage of proprietary schemas, internal libraries, or business logic via generated models
- Contamination of generated code with unexpected or maliciously crafted structures derived from sensitive files
- Local filesystem disclosure of readable files accessible to the code generation process
- Exposure of configuration files, API keys, or secrets embedded in local resources
- Leakage of proprietary schemas, internal libraries, or business logic via generated models
- Contamination of generated code with unexpected or maliciously crafted structures derived from sensitive files
General mitigation guidance
Effective mitigation focuses on tightening trust boundaries around XML Schema resolution and file access during code generation.
Recommended high-level patterns include:
- Restricting schema resolution to a fixed, whitelisted base directory or virtualized schema store.
- Normalizing and validating all
schemaLocationpaths before use, rejecting paths that escape the allowed root. - Treating XML Schema inputs as untrusted and avoiding running the generator on attacker-controlled schemas in sensitive environments.
- Running datamodel-code-generator with least-privilege filesystem access, limiting read permissions to only the directories required for code generation.
- Applying defense-in-depth by separating build infrastructure from systems that store high-value secrets or configuration files.
Effective mitigation focuses on tightening trust boundaries around XML Schema resolution and file access during code generation.
Recommended high-level patterns include:
- Restricting schema resolution to a fixed, whitelisted base directory or virtualized schema store.
- Normalizing and validating all
schemaLocationpaths before use, rejecting paths that escape the allowed root. - Treating XML Schema inputs as untrusted and avoiding running the generator on attacker-controlled schemas in sensitive environments.
- Running datamodel-code-generator with least-privilege filesystem access, limiting read permissions to only the directories required for code generation.
- Applying defense-in-depth by separating build infrastructure from systems that store high-value secrets or configuration files.
How teams detect issues like this
Detection can focus on both code-level patterns and build-time behavior:
- Static analysis and code review:
- Look for XML Schema parsing code that directly resolves
schemaLocationvalues to the local filesystem without base-path checks. - Flag uses of generic file-loading logic in schema resolvers that lack canonicalization and path validation.
- Policy and pipeline enforcement:
- Enforce CI/CD policies that disallow running code generators against untrusted or user-supplied XML Schemas.
- Add checks that ensure schema directories and resolution roots are explicitly configured and reviewed.
- Runtime and operational monitoring:
- Monitor build agents for unusual file access patterns during code generation, such as reads from system directories or secret paths.
- Use file access auditing on build hosts to detect generators reading outside expected schema directories.
Automated SAST or build security tools can be configured to highlight unrestricted resource resolution patterns in code generation utilities.
Detection can focus on both code-level patterns and build-time behavior:
- Static analysis and code review:
- Look for XML Schema parsing code that directly resolves
schemaLocationvalues to the local filesystem without base-path checks. - Flag uses of generic file-loading logic in schema resolvers that lack canonicalization and path validation.
- Policy and pipeline enforcement:
- Enforce CI/CD policies that disallow running code generators against untrusted or user-supplied XML Schemas.
- Add checks that ensure schema directories and resolution roots are explicitly configured and reviewed.
- Runtime and operational monitoring:
- Monitor build agents for unusual file access patterns during code generation, such as reads from system directories or secret paths.
- Use file access auditing on build hosts to detect generators reading outside expected schema directories.
Automated SAST or build security tools can be configured to highlight unrestricted resource resolution patterns in code generation utilities.
