Summary
datamodel-code-generator improperly resolves JSON Schema $ref values, allowing schema references to access arbitrary local files outside the intended input directory.
When an attacker can influence or provide OpenAPI/JSON Schema inputs, they may abuse $ref resolution to read sensitive files from the generator's filesystem, even when remote references are supposedly disabled.
datamodel-code-generator improperly resolves JSON Schema $ref values, allowing schema references to access arbitrary local files outside the intended input directory.
When an attacker can influence or provide OpenAPI/JSON Schema inputs, they may abuse $ref resolution to read sensitive files from the generator's filesystem, even when remote references are supposedly disabled.
Affected context
This vulnerability arises when datamodel-code-generator is used to generate models (Pydantic v2, dataclasses, TypedDict, msgspec.Struct) from untrusted or partially trusted specifications such as OpenAPI or JSON Schema.
It affects workflows where $ref resolution is performed against user-supplied schemas, especially in CI pipelines, web-based generators, or shared tooling environments that run with access to sensitive files on the host.
This vulnerability arises when datamodel-code-generator is used to generate models (Pydantic v2, dataclasses, TypedDict, msgspec.Struct) from untrusted or partially trusted specifications such as OpenAPI or JSON Schema.
It affects workflows where $ref resolution is performed against user-supplied schemas, especially in CI pipelines, web-based generators, or shared tooling environments that run with access to sensitive files on the host.
Exploit preconditions
- Attack surface: JSON Schema/OpenAPI/other spec inputs consumed by datamodel-code-generator.
- Required access: Ability to submit, upload, or modify schemas that the tool processes (e.g., via a web service, automation pipeline, or shared repo).
- Trigger point: During
$refresolution inparser/jsonschema.py, whenis_urland_get_ref_bodyprocess references without restrictingfile://schemes or../traversal. - Why exploitation is possible: The resolver trusts
$reftargets and fails to constrain them to the intended input directory or configuration flags, enabling references to arbitrary local paths.
- Attack surface: JSON Schema/OpenAPI/other spec inputs consumed by datamodel-code-generator.
- Required access: Ability to submit, upload, or modify schemas that the tool processes (e.g., via a web service, automation pipeline, or shared repo).
- Trigger point: During
$refresolution inparser/jsonschema.py, whenis_urland_get_ref_bodyprocess references without restrictingfile://schemes or../traversal. - Why exploitation is possible: The resolver trusts
$reftargets and fails to constrain them to the intended input directory or configuration flags, enabling references to arbitrary local paths.
Why this happens
The core issue is insufficient validation and restriction of external entity references in JSON Schema resolution logic.
The $ref handling code uses helpers like is_url and _get_ref_body to fetch referenced content but does not enforce a strict root directory, sanitize traversal sequences, or reject local file:// references when remote refs should be disabled.
This aligns with:
- CWE-22 (Improper Limitation of a Pathname to a Restricted Directory):
$refpaths can escape the intended schema directory via traversal or local URI schemes. - CWE-610 (ExternaI Control of File Name or Path): Attackers control the
$refvalues that drive file selection. - Resulting in CWE-200 (Information Exposure): Local files not meant to be part of the schema processing can be read and surfaced as part of model generation.
The core issue is insufficient validation and restriction of external entity references in JSON Schema resolution logic.
The $ref handling code uses helpers like is_url and _get_ref_body to fetch referenced content but does not enforce a strict root directory, sanitize traversal sequences, or reject local file:// references when remote refs should be disabled.
This aligns with:
- CWE-22 (Improper Limitation of a Pathname to a Restricted Directory):
$refpaths can escape the intended schema directory via traversal or local URI schemes. - CWE-610 (ExternaI Control of File Name or Path): Attackers control the
$refvalues that drive file selection. - Resulting in CWE-200 (Information Exposure): Local files not meant to be part of the schema processing can be read and surfaced as part of model generation.
Potential impact
- Attackers may read sensitive configuration files from the host system.
- Schema processing could expose credentials, API keys, or access tokens stored in local files.
- Internal source code or proprietary schemas may be disclosed through generated outputs.
- Local environment details (paths, structure, internal documentation) can be inferred or leaked, supporting further attacks.
- Attackers may read sensitive configuration files from the host system.
- Schema processing could expose credentials, API keys, or access tokens stored in local files.
- Internal source code or proprietary schemas may be disclosed through generated outputs.
- Local environment details (paths, structure, internal documentation) can be inferred or leaked, supporting further attacks.
General mitigation guidance
Effective mitigation focuses on constraining reference resolution and reducing trust in external schema inputs.
Common defensive patterns include:
- Enforcing a strict root directory for all
$refresolution and rejecting paths that attempt traversal outside this boundary. - Disallowing
file://and similar local URI schemes in user-controlled$refvalues unless explicitly whitelisted. - Treating schema files as untrusted input, applying validation and normalization to reference paths before resolution.
- Running generators with least-privilege file system access so that sensitive directories are not readable even if traversal is attempted.
- Providing configuration options that default to safe behavior, such as disabling remote or out-of-tree references unless explicitly opted in.
Effective mitigation focuses on constraining reference resolution and reducing trust in external schema inputs.
Common defensive patterns include:
- Enforcing a strict root directory for all
$refresolution and rejecting paths that attempt traversal outside this boundary. - Disallowing
file://and similar local URI schemes in user-controlled$refvalues unless explicitly whitelisted. - Treating schema files as untrusted input, applying validation and normalization to reference paths before resolution.
- Running generators with least-privilege file system access so that sensitive directories are not readable even if traversal is attempted.
- Providing configuration options that default to safe behavior, such as disabling remote or out-of-tree references unless explicitly opted in.
How teams detect issues like this
Detection typically combines code-level analysis and operational monitoring:
- Use static analysis or manual code review to identify file resolution logic that accepts user-controlled
$refor path values without normalization or boundary checks. - Flag usages of
open(), URL/URI handlers, or custom loaders in schema parsers where path constraints are missing or optional. - Implement security-focused tests that submit crafted schemas with
../segments orfile://URIs to verify they are rejected or safely handled. - Apply policy enforcement in CI/CD to restrict introduction of new schema resolution mechanisms that do not honor secure defaults.
- Complement code controls with host-level monitoring for unexpected file access patterns from tooling processes that handle untrusted input.
Detection typically combines code-level analysis and operational monitoring:
- Use static analysis or manual code review to identify file resolution logic that accepts user-controlled
$refor path values without normalization or boundary checks. - Flag usages of
open(), URL/URI handlers, or custom loaders in schema parsers where path constraints are missing or optional. - Implement security-focused tests that submit crafted schemas with
../segments orfile://URIs to verify they are rejected or safely handled. - Apply policy enforcement in CI/CD to restrict introduction of new schema resolution mechanisms that do not honor secure defaults.
- Complement code controls with host-level monitoring for unexpected file access patterns from tooling processes that handle untrusted input.
