Summary
datamodel-code-generator dereferences attacker-controlled JSON Schema $ref URLs over HTTP/HTTPS, enabling server-side requests from the host running the generator.
When untrusted schemas are processed, this behavior may allow an attacker to trigger server-side request forgery (SSRF) against internal services reachable from the environment where code generation occurs.
datamodel-code-generator dereferences attacker-controlled JSON Schema $ref URLs over HTTP/HTTPS, enabling server-side requests from the host running the generator.
When untrusted schemas are processed, this behavior may allow an attacker to trigger server-side request forgery (SSRF) against internal services reachable from the environment where code generation occurs.
Affected context
This vulnerability appears when datamodel-code-generator processes JSON Schemas that include $ref values pointing to external HTTP or HTTPS URLs.
It is most relevant in environments where schema input can be influenced by external users or supply-chain sources, and where the generator runs with network access to internal or cloud-metadata endpoints.
The risk increases if warnings from options like --allow-remote-refs are not treated as hard failures and if generated code is produced in CI/CD systems or backend services with broad egress permissions.
This vulnerability appears when datamodel-code-generator processes JSON Schemas that include $ref values pointing to external HTTP or HTTPS URLs.
It is most relevant in environments where schema input can be influenced by external users or supply-chain sources, and where the generator runs with network access to internal or cloud-metadata endpoints.
The risk increases if warnings from options like --allow-remote-refs are not treated as hard failures and if generated code is produced in CI/CD systems or backend services with broad egress permissions.
Exploit preconditions
- Attack surface: JSON Schema input consumed by datamodel-code-generator (CLI, build pipelines, or automated tooling).
- Required access: Ability to provide or modify schemas containing crafted
$refURLs, directly or via upstream specification sources. - Trigger point: Execution of the code generation process that dereferences
$reffields over HTTP/HTTPS. - Why exploitation is possible: The generator automatically follows remote
$refURLs and issues outbound HTTP requests without strict origin controls or robust blocking of remote references, enabling an attacker to pivot requests from the generator's network context.
- Attack surface: JSON Schema input consumed by datamodel-code-generator (CLI, build pipelines, or automated tooling).
- Required access: Ability to provide or modify schemas containing crafted
$refURLs, directly or via upstream specification sources. - Trigger point: Execution of the code generation process that dereferences
$reffields over HTTP/HTTPS. - Why exploitation is possible: The generator automatically follows remote
$refURLs and issues outbound HTTP requests without strict origin controls or robust blocking of remote references, enabling an attacker to pivot requests from the generator's network context.
Why this happens
The underlying bug is an over-trusting of remote JSON Schema references within the parsing pipeline.
By design, $ref is used to modularize schemas, but the implementation in jsonschema.py and associated HTTP utilities treats HTTP/HTTPS $ref targets as safe to fetch, even when they originate from potentially untrusted specifications.
This aligns with CWE-918: Server-Side Request Forgery (SSRF), where server-side components make network calls on behalf of user-controlled inputs, lacking adequate validation, allowlisting, or isolation of egress routes.
The underlying bug is an over-trusting of remote JSON Schema references within the parsing pipeline.
By design, $ref is used to modularize schemas, but the implementation in jsonschema.py and associated HTTP utilities treats HTTP/HTTPS $ref targets as safe to fetch, even when they originate from potentially untrusted specifications.
This aligns with CWE-918: Server-Side Request Forgery (SSRF), where server-side components make network calls on behalf of user-controlled inputs, lacking adequate validation, allowlisting, or isolation of egress routes.
Potential impact
- The generator may issue HTTP requests to internal network services that are not directly reachable by an attacker.
- Attackers could probe internal hostnames, ports, or paths for responsiveness via controlled
$refURLs. - Sensitive endpoints (such as cloud metadata services or admin APIs) could be queried, potentially leaking configuration or credential-like data depending on responses.
- Internal service behavior and timing may be observable, enabling further attack planning or lateral movement.
- The generator may issue HTTP requests to internal network services that are not directly reachable by an attacker.
- Attackers could probe internal hostnames, ports, or paths for responsiveness via controlled
$refURLs. - Sensitive endpoints (such as cloud metadata services or admin APIs) could be queried, potentially leaking configuration or credential-like data depending on responses.
- Internal service behavior and timing may be observable, enabling further attack planning or lateral movement.
General mitigation guidance
Mitigation generally focuses on restricting where $ref can point and how remote references are handled during schema processing.
Secure patterns include:
- Treating all externally supplied schemas as untrusted input and enforcing strict policies that disallow or tightly constrain remote
$refURLs. - Implementing allowlists for permitted domains or schemes and rejecting or sandboxing any other outbound requests originating from schema resolution.
- Running code generation in isolated environments with minimal network access, particularly avoiding connectivity to sensitive internal segments or metadata endpoints.
- Using configuration options and internal wrappers that enforce "fail closed" behavior when remote references are encountered, rather than converting them to non-blocking warnings.
Mitigation generally focuses on restricting where $ref can point and how remote references are handled during schema processing.
Secure patterns include:
- Treating all externally supplied schemas as untrusted input and enforcing strict policies that disallow or tightly constrain remote
$refURLs. - Implementing allowlists for permitted domains or schemes and rejecting or sandboxing any other outbound requests originating from schema resolution.
- Running code generation in isolated environments with minimal network access, particularly avoiding connectivity to sensitive internal segments or metadata endpoints.
- Using configuration options and internal wrappers that enforce "fail closed" behavior when remote references are encountered, rather than converting them to non-blocking warnings.
How teams detect issues like this
Detection efforts can focus on both configuration and runtime behavior.
Common approaches include:
- Static review of build scripts, CI/CD pipelines, and generator configurations to identify where datamodel-code-generator processes untrusted or external schemas and whether remote
$refresolution is enabled. - Network monitoring and egress filtering that flags or blocks unexpected outbound HTTP requests sourced from code generation environments, especially targeting internal hostnames or known sensitive endpoints.
- Policy-based checks in repository and pipeline tooling to ensure schema files do not contain remote
$refURLs, or that such references conform to a vetted allowlist. - Use of automated security scanners or linters that detect SSRF-prone patterns in infrastructure code and script-based tooling that orchestrates schema-driven code generation.
Detection efforts can focus on both configuration and runtime behavior.
Common approaches include:
- Static review of build scripts, CI/CD pipelines, and generator configurations to identify where datamodel-code-generator processes untrusted or external schemas and whether remote
$refresolution is enabled. - Network monitoring and egress filtering that flags or blocks unexpected outbound HTTP requests sourced from code generation environments, especially targeting internal hostnames or known sensitive endpoints.
- Policy-based checks in repository and pipeline tooling to ensure schema files do not contain remote
$refURLs, or that such references conform to a vetted allowlist. - Use of automated security scanners or linters that detect SSRF-prone patterns in infrastructure code and script-based tooling that orchestrates schema-driven code generation.
