This is a TOCTOU vulnerability where your own validation code races against the HTTP library's internal DNS resolution. The developer of datamodel-code-generator wrote three validation functions — get_body, _validate_url_for_fetch, and _get_ips_from_host — that resolve URLs, extract IPs, check for private network addresses, and enforce allow_private_network=False. This is genuine defensive code, not negligence. But httpx performs its own DNS resolution when making the connection, and that resolution happens after your validation completes. An attacker who can influence DNS responses between validation time and connection time can bypass your checks entirely.
The fix in version 0.63.0 addresses this by forcing httpx to use the already-resolved IPs rather than re-resolving. Verify you're on 0.63.0 or later. However, note this is a fragile fix: it works by constraining httpx's internal behavior, which could change in future httpx versions. If httpx refactors its async DNS resolution for performance reasons, the workaround could silently break and re-expose the gap. The defensible long-term architecture is to resolve first, validate the IPs, then pass only IPs (never hostnames) to your HTTP client with a transport layer that rejects any re-resolution attempts.
The blast radius here is worse than a typical SSRF because this tool sits in a CI/build pipeline — it pulls external OpenAPI specs and generates code that feeds downstream systems. A successful SSRF from a build pipeline can reach internal services that wouldn't be exposed from a regular web application. Treat this as higher priority than the CVSS 7.5 suggests if the tool runs in your build or deployment pipeline.