Summary
datamodel-code-generator's HTTP client logic allows user-controlled URLs and redirect targets to be fetched without validating the destination host or IP address.
In environments where the tool can reach internal networks, an attacker can abuse this behavior to perform server-side request forgery (SSRF) against loopback, private, or metadata services.
datamodel-code-generator's HTTP client logic allows user-controlled URLs and redirect targets to be fetched without validating the destination host or IP address.
In environments where the tool can reach internal networks, an attacker can abuse this behavior to perform server-side request forgery (SSRF) against loopback, private, or metadata services.
Affected context
This vulnerability appears when datamodel-code-generator is used with the --url option or similar functionality that pulls schemas over HTTP/S.
The affected code path (http.get_body) follows redirects and issues requests without validating whether the final host or IP belongs to internal or otherwise sensitive address ranges.
Risk is elevated in environments where the machine running datamodel-code-generator has network visibility into loopback-only services, cloud metadata endpoints, internal APIs, or restricted management interfaces.
This vulnerability appears when datamodel-code-generator is used with the --url option or similar functionality that pulls schemas over HTTP/S.
The affected code path (http.get_body) follows redirects and issues requests without validating whether the final host or IP belongs to internal or otherwise sensitive address ranges.
Risk is elevated in environments where the machine running datamodel-code-generator has network visibility into loopback-only services, cloud metadata endpoints, internal APIs, or restricted management interfaces.
Exploit preconditions
- Attack surface: Command-line or API interfaces that accept user-influenced URLs for datamodel-code-generator to fetch schemas or related content.
- Required access: Ability to supply or influence the
--urlargument or equivalent configuration; this can be via CI/CD configuration, build scripts, web frontends wrapping the tool, or shared automation. - Trigger point: Invocation of datamodel-code-generator such that
http.get_bodyis called on an attacker-controlled URL, including any redirects that the remote endpoint returns. - Why exploitation is possible: The HTTP client does not enforce host/IP allowlists or blocklists, and it follows redirects blindly, enabling requests to arbitrary internal addresses (loopback, RFC1918, link-local, or metadata) from a more privileged network position than the attacker has directly.
- Attack surface: Command-line or API interfaces that accept user-influenced URLs for datamodel-code-generator to fetch schemas or related content.
- Required access: Ability to supply or influence the
--urlargument or equivalent configuration; this can be via CI/CD configuration, build scripts, web frontends wrapping the tool, or shared automation. - Trigger point: Invocation of datamodel-code-generator such that
http.get_bodyis called on an attacker-controlled URL, including any redirects that the remote endpoint returns. - Why exploitation is possible: The HTTP client does not enforce host/IP allowlists or blocklists, and it follows redirects blindly, enabling requests to arbitrary internal addresses (loopback, RFC1918, link-local, or metadata) from a more privileged network position than the attacker has directly.
Why this happens
The core issue is a lack of outbound request destination validation when fetching schemas from URLs.
The HTTP helper accepts arbitrary user-specified URLs and redirect locations, and treats them as trusted targets without checking whether the resolved host/IP belongs to internal, loopback, or otherwise sensitive network ranges.
This maps to CWE-918: Server-Side Request Forgery (SSRF), where a server-side component initiates network requests based on untrusted input and can be coerced into reaching resources that an external attacker cannot access directly.
Conceptually, the bug stems from treating user-controlled URLs as harmless data fetches, rather than as potential pivots into the application's private network perimeter.
The core issue is a lack of outbound request destination validation when fetching schemas from URLs.
The HTTP helper accepts arbitrary user-specified URLs and redirect locations, and treats them as trusted targets without checking whether the resolved host/IP belongs to internal, loopback, or otherwise sensitive network ranges.
This maps to CWE-918: Server-Side Request Forgery (SSRF), where a server-side component initiates network requests based on untrusted input and can be coerced into reaching resources that an external attacker cannot access directly.
Conceptually, the bug stems from treating user-controlled URLs as harmless data fetches, rather than as potential pivots into the application's private network perimeter.
Potential impact
- Access to internal HTTP services not directly reachable by the attacker (e.g., internal APIs, databases with HTTP interfaces, or admin panels).
- Interaction with cloud provider metadata services, which may expose credentials or instance configuration data.
- Enumeration of internal network structure (open ports, available services, and basic service fingerprints) by observing response behavior.
- Potential write or state-changing operations on internal services if they expose non-idempotent HTTP endpoints.
- Chaining of SSRF with other weaknesses (e.g., misconfigured internal admin interfaces) to escalate to remote code execution or broader system compromise.
- Access to internal HTTP services not directly reachable by the attacker (e.g., internal APIs, databases with HTTP interfaces, or admin panels).
- Interaction with cloud provider metadata services, which may expose credentials or instance configuration data.
- Enumeration of internal network structure (open ports, available services, and basic service fingerprints) by observing response behavior.
- Potential write or state-changing operations on internal services if they expose non-idempotent HTTP endpoints.
- Chaining of SSRF with other weaknesses (e.g., misconfigured internal admin interfaces) to escalate to remote code execution or broader system compromise.
General mitigation guidance
Effective mitigation focuses on constraining where the HTTP client is allowed to connect and minimizing trust in user-supplied URLs:
- Introduce strict allowlists for outbound HTTP destinations, limiting schema fetching to known, trusted domains or repository hosts.
- Explicitly block loopback, link-local, private RFC1918 ranges, and well-known cloud metadata addresses at the application layer before issuing network requests.
- Treat redirect targets with the same scrutiny as the original URL, re-validating on each hop and rejecting redirects that cross security boundaries.
- Run tooling like datamodel-code-generator in isolated network segments or containers that have no access to sensitive internal services or metadata endpoints.
- Apply the principle of least privilege to network egress rules, such as using firewall rules, proxy policies, or service meshes to restrict outbound traffic from build or tooling environments.
Effective mitigation focuses on constraining where the HTTP client is allowed to connect and minimizing trust in user-supplied URLs:
- Introduce strict allowlists for outbound HTTP destinations, limiting schema fetching to known, trusted domains or repository hosts.
- Explicitly block loopback, link-local, private RFC1918 ranges, and well-known cloud metadata addresses at the application layer before issuing network requests.
- Treat redirect targets with the same scrutiny as the original URL, re-validating on each hop and rejecting redirects that cross security boundaries.
- Run tooling like datamodel-code-generator in isolated network segments or containers that have no access to sensitive internal services or metadata endpoints.
- Apply the principle of least privilege to network egress rules, such as using firewall rules, proxy policies, or service meshes to restrict outbound traffic from build or tooling environments.
How teams detect issues like this
Detection involves both code-centric and environment-centric strategies:
- Static analysis: Search for HTTP client usages that accept user-controlled URLs without host/IP filtering, especially around tooling or build-time fetchers; flag redirect-following logic that lacks destination validation.
- Code review: Pay attention to features that "fetch schemas," "import definitions from URL," or similar, ensuring reviewers ask where those URLs come from and whether destinations are constrained.
- Runtime monitoring: Use network telemetry from build agents or developer tooling hosts to identify unusual outbound requests to internal ranges or metadata endpoints initiated by tooling processes.
- Policy enforcement: Enforce security policies in CI/CD (e.g., via pre-merge checks or security gateways) that restrict or require approval for new code paths that perform outbound HTTP requests based on untrusted configuration.
Detection involves both code-centric and environment-centric strategies:
- Static analysis: Search for HTTP client usages that accept user-controlled URLs without host/IP filtering, especially around tooling or build-time fetchers; flag redirect-following logic that lacks destination validation.
- Code review: Pay attention to features that "fetch schemas," "import definitions from URL," or similar, ensuring reviewers ask where those URLs come from and whether destinations are constrained.
- Runtime monitoring: Use network telemetry from build agents or developer tooling hosts to identify unusual outbound requests to internal ranges or metadata endpoints initiated by tooling processes.
- Policy enforcement: Enforce security policies in CI/CD (e.g., via pre-merge checks or security gateways) that restrict or require approval for new code paths that perform outbound HTTP requests based on untrusted configuration.
