Summary
A DNS rebinding flaw in datamodel-code-generator allows attackers to bypass URL host validation and reach internal services despite allow_private_network=False.
When the tool fetches remote schemas or documents over HTTP, an attacker-controlled domain can be used to pivot requests from public hosts to private network targets.
A DNS rebinding flaw in datamodel-code-generator allows attackers to bypass URL host validation and reach internal services despite allow_private_network=False.
When the tool fetches remote schemas or documents over HTTP, an attacker-controlled domain can be used to pivot requests from public hosts to private network targets.
Affected context
This vulnerability affects environments where datamodel-code-generator is used to fetch remote inputs (OpenAPI specs, JSON Schema, GraphQL schemas, etc.) over HTTP.
It becomes relevant when:
- The tool is allowed to make outbound HTTP requests to user-specified URLs
- allow_private_network=False is relied upon to block access to internal addresses
- DNS resolution for the target host can be influenced by an attacker (e.g., attacker-controlled domains)
This vulnerability affects environments where datamodel-code-generator is used to fetch remote inputs (OpenAPI specs, JSON Schema, GraphQL schemas, etc.) over HTTP.
It becomes relevant when:
- The tool is allowed to make outbound HTTP requests to user-specified URLs
- allow_private_network=False is relied upon to block access to internal addresses
- DNS resolution for the target host can be influenced by an attacker (e.g., attacker-controlled domains)
Exploit preconditions
- Attack surface: HTTP-based schema/document fetching in datamodel-code-generator.
- Required access: Ability to supply or influence the URL that datamodel-code-generator uses for fetching remote content.
- Trigger point: The HTTP request issued by the internal httpx client after the initial host validation step.
- Why exploitation is possible: The host is validated once using one resolution path, but httpx performs a separate DNS resolution at connection time. An attacker can leverage DNS rebinding to present a benign public IP during validation and then rebind the domain to an internal IP when the actual HTTP request is sent, bypassing allow_private_network=False.
- Attack surface: HTTP-based schema/document fetching in datamodel-code-generator.
- Required access: Ability to supply or influence the URL that datamodel-code-generator uses for fetching remote content.
- Trigger point: The HTTP request issued by the internal httpx client after the initial host validation step.
- Why exploitation is possible: The host is validated once using one resolution path, but httpx performs a separate DNS resolution at connection time. An attacker can leverage DNS rebinding to present a benign public IP during validation and then rebind the domain to an internal IP when the actual HTTP request is sent, bypassing allow_private_network=False.
Why this happens
The underlying bug is a mismatch between the security validation logic and the actual network resolution path.
datamodel-code-generator validates the URL host and checks IPs against private network rules using custom DNS resolution, but later delegates the connection to httpx, which performs its own host resolution.
This separation enables CWE-350: Reliance on DNS for Security and CWE-367: Time-of-check Time-of-use (TOCTOU) conditions, where the trusted result of a prior DNS lookup is no longer valid at the time of use.
The behavior manifests as CWE-918: Server-Side Request Forgery (SSRF) because an attacker can steer the tool into making HTTP requests to internal network services by manipulating DNS responses.
The underlying bug is a mismatch between the security validation logic and the actual network resolution path.
datamodel-code-generator validates the URL host and checks IPs against private network rules using custom DNS resolution, but later delegates the connection to httpx, which performs its own host resolution.
This separation enables CWE-350: Reliance on DNS for Security and CWE-367: Time-of-check Time-of-use (TOCTOU) conditions, where the trusted result of a prior DNS lookup is no longer valid at the time of use.
The behavior manifests as CWE-918: Server-Side Request Forgery (SSRF) because an attacker can steer the tool into making HTTP requests to internal network services by manipulating DNS responses.
Potential impact
- May allow access to internal HTTP services that should not be reachable from the tool.
- Could enable enumeration or probing of internal APIs and metadata endpoints.
- Can expose sensitive configuration or schema data hosted on private services.
- May facilitate further compromise if internal services trust the calling environment or lack authentication.
- May allow access to internal HTTP services that should not be reachable from the tool.
- Could enable enumeration or probing of internal APIs and metadata endpoints.
- Can expose sensitive configuration or schema data hosted on private services.
- May facilitate further compromise if internal services trust the calling environment or lack authentication.
General mitigation guidance
Effective mitigation focuses on aligning host validation with the actual network connections and reducing trust in DNS for enforcing security boundaries.
Common defensive patterns include:
- Ensuring that the same resolved IPs used for security checks are also used for the outbound HTTP connections (e.g., binding connections to pre-resolved addresses).
- Applying strict IP-based allow/deny logic rather than relying solely on hostname checks for private network protection.
- Isolating schema/document fetching into a sandboxed environment with no access to sensitive internal networks.
- Restricting or pre-approving remote URLs that the tool is allowed to access, instead of accepting arbitrary user-supplied endpoints.
- Applying least-privilege principles to network egress for tools that perform automatic HTTP fetches.
Effective mitigation focuses on aligning host validation with the actual network connections and reducing trust in DNS for enforcing security boundaries.
Common defensive patterns include:
- Ensuring that the same resolved IPs used for security checks are also used for the outbound HTTP connections (e.g., binding connections to pre-resolved addresses).
- Applying strict IP-based allow/deny logic rather than relying solely on hostname checks for private network protection.
- Isolating schema/document fetching into a sandboxed environment with no access to sensitive internal networks.
- Restricting or pre-approving remote URLs that the tool is allowed to access, instead of accepting arbitrary user-supplied endpoints.
- Applying least-privilege principles to network egress for tools that perform automatic HTTP fetches.
How teams detect issues like this
Detection typically involves examining how network requests are validated and executed within the codebase.
Helpful strategies include:
- Static analysis rules that flag separate validation and connection resolution paths, especially when different libraries handle each step.
- Code review focused on SSRF patterns: user-controlled URLs, indirect access to internal hosts, and reliance on DNS checks for security decisions.
- Policy-based checks ensuring that tools performing remote fetches do not have unrestricted access to internal network ranges.
- Runtime monitoring that alerts when developer tools or code generators attempt to connect to private IP ranges or sensitive internal endpoints.
Detection typically involves examining how network requests are validated and executed within the codebase.
Helpful strategies include:
- Static analysis rules that flag separate validation and connection resolution paths, especially when different libraries handle each step.
- Code review focused on SSRF patterns: user-controlled URLs, indirect access to internal hosts, and reliance on DNS checks for security decisions.
- Policy-based checks ensuring that tools performing remote fetches do not have unrestricted access to internal network ranges.
- Runtime monitoring that alerts when developer tools or code generators attempt to connect to private IP ranges or sensitive internal endpoints.
