Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
13 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When processing an attacker-controlled Protobuf schema, vulnerable versions of datamodel-code-generator could write a generated weak-import stub outside the intended weakimports temporary directory. Absolute import paths and relative paths containing .. could escape this directory. An attacker could create directories and new files at locations writable by the process. Relative path traversal could also overwrite existing writable files because the existence check and the stub write used different base directories. An existing absolute target was skipped by the existence check. Written content was limited to a generated Protobuf syntax declaration, syntax = "proto2"; or syntax = "proto3";, followed by a newline. This issue did not provide fully attacker-controlled file contents, and direct arbitrary code execution has not been demonstrated. These filesystem side effects occurred before protoc ran. A subsequent compilation error did not undo them. A user or CI job must process…
Recommended action: Upgrade to 0.81.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/datamodelcodegenerator/model/template/TypeAliasAnnotation.jinja2:12 and :19 - src/datamodelcodegenerator/model/template/TypeAliasType.jinja2:12 and :19 - src/datamodelcodegenerator/model/template/TypeStatement.jinja2:12 and :19 -…
Recommended action: Upgrade to 0.60.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 isurl() classifies file:// as a URL (reference.py:1249): The remote-ref gate then explicitly exempts file://, so --no-allow-remote-refs never applies to it (parser/jsonschema.py, getrefbody): Both local-file…
Recommended action: Upgrade to 0.62.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
datamodel-code-generator is vulnerable to code injection when generating Python models from an attacker-controlled JSON Schema, OpenAPI, YAML, JSON, Avro, Protobuf, or XSD schema. When a property carries a "defaultfactory" key, its value is interpolated verbatim — as a raw Python expression — into the generated Field(defaultfactory=...) / field(defaultfactory=...) call. Because this assignment is evaluated at class-definition time (i.e. on import of the generated module), an attacker who controls the schema controls a Python expression that runs in the consumer's process. No special CLI flags are required. Details The vulnerable chain spans the JSON-Schema-shaped parser and three sink locations (Pydantic v2, dataclass, msgspec): Source — schema → extras: - src/datamodelcodegenerator/parser/jsonschema.py:600-614 — DEFAULTFIELDKEYS includes the literal string "defaultfactory". - src/datamodelcodegenerator/parser/jsonschema.py:457-459 — JsonSchemaObject.init stores any…
Recommended action: Upgrade to 0.60.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 allowprivatenetwork=False. This is a server-side request forgery reachable when the tool fetches an attacker-influenced URL (remote $ref, or --url). Details In src/datamodelcodegenerator/http.py, getbody() calls validateurlforfetch(), which resolves the host via getipsfromhost() (socket.getaddrinfo) and rejects non-global addresses: It then connects with a separate, independent resolution: Nothing ties the connection to the IP that passed validation. Between the two resolutions a low-TTL attacker-controlled record…
Recommended action: Upgrade to 0.63.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the Pydantic v2 output mode is in use, datamodel-code-generator reads a validators array from each model entry in the --extra-template-data file and synthesises a Pydantic @fieldvalidator(...) decorator from each entry. The field names and the validator mode are interpolated into the decorator call wrapped in unescaped single quotes. A value containing ' breaks out of the string literal, letting an attacker emit an arbitrary positional Python expression into the decorator. The expression is evaluated at class-definition time, i.e. the moment the developer imports the generated module. This is the same trust model as the recently-published GHSA-wjv6-jcfj-mf9r (extras-file comment injection) but the impact is full RCE rather than a docstring leak. Details Sink: src/datamodelcodegenerator/model/pydanticv2/basemodel.py, processvalidators (lines 405–449, at tag 0.60.1 / commit a321547e): The strings from (A) and (B) flow verbatim into…
Recommended action: Upgrade to 0.60.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/datamodelcodegenerator/parser/jsonschema.py, getrefbody (lines 4776–4793, at tag 0.60.1 / commit a321547e): - (A) emits a deprecation warning when allowremoterefs is its default (None); execution falls through…
Recommended action: Upgrade to 0.61.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, defaultfactory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path. Details The sink is Import.fromfullpath and Imports.createline: - src/datamodelcodegenerator/imports.py:35 — fromfullpath() only does classpath.split(".") and preserves every other…
Recommended action: Upgrade to 0.64.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
datamodel-code-generator is vulnerable to code injection when generating Python models from an attacker-controlled GraphQL schema. A description on a Union type, written in the regular-string form ("...") with a literal \r escape, is rendered into a Python comment by a Jinja2 filter that handles only \n. Python's tokenizer treats a bare CR as a physical-line terminator, so the comment ends at the \r and the text after it is parsed as module-level Python. The injected code executes at import time of the generated .py, in the context of any consumer that imports the model. No special CLI flags are required. This affects versions =0.25.0, <0.60.1 and is fixed in 0.60.1. Details The vulnerable output was generated by the GraphQL Union templates: - src/datamodelcodegenerator/model/template/UnionTypeStatement.jinja2 - src/datamodelcodegenerator/model/template/UnionTypeAliasAnnotation.jinja2 - src/datamodelcodegenerator/model/template/UnionTypeAliasType.jinja2 Before 0.60.1, Union…
Recommended action: Upgrade to 0.60.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
datamodel-code-generator honours a custom x-python-type JSON-Schema extension that lets a schema author override the generated Python type for a field. The value is forwarded verbatim into the generated Python source as the field annotation, with a single sanitisation pass that is trivial to bypass. An attacker who controls a JSON Schema fed to datamodel-codegen can therefore embed an arbitrary Python statement in the generated module, which executes at class-definition time the moment the developer imports the file. No --extra-template-data and no special flags are required; the vulnerable code is reachable with default settings. Details Sink: src/datamodelcodegenerator/parser/jsonschema.py, getpythontypeoverride (lines 2055–2096, at tag 0.60.1 / commit a321547e): DataType.type flows unescaped into {{ field.typehint }} in every model template (model/template/pydanticv2/BaseModel.jinja2, model/template/dataclass.jinja2, model/template/TypedDictClass.jinja2,…
Recommended action: Upgrade to 0.60.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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/datamodelcodegenerator/http.py, getbody() follows redirects manually and re-issues each hop with the same headers argument, with no check that the origin is unchanged: 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:…
Recommended action: Upgrade to 0.63.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
datamodel-code-generator's built-in HTTP fetcher (http.getbody) 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 followredirects=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/datamodelcodegenerator/http.py, getbody (lines 31–61, at tag 0.60.1 / commit a321547e): - (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,…
Recommended action: Upgrade to 0.61.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 allowremoterefs 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 isfile() check (src/datamodelcodegenerator/parser/xmlschema.py): schemalocation is attacker-controlled and readxmltext does path.readbytes(). Because…
Recommended action: Upgrade to 0.62.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.