CVE-2026-63720: datamodel-code-generator Code Injection
TL;DR -
datamodel-code-generatorbefore 0.70.0 can emit attacker-controlled Python into generated imports. - Teams processing untrusted schemas and importing generated modules are at risk. - Upgrade to 0.70.0+ and treat generated code as untrusted until reviewed.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-63720 |
| CVSS | 7.5 High |
| Attack vector | Schema input to code-generation workflow; execution occurs when generated Python module is imported |
| Privileges required | Unknown from published scoring details; practically, attacker must control or influence input schema content |
| Patch available | Yes. Upgrade to datamodel-code-generator 0.70.0 or later |
This vulnerability affects datamodel-code-generator, the Python project maintained under koxudaxi/datamodel-code-generator. According to the NVD description, versions prior to 0.70.0 are vulnerable to code injection because a malicious schema can provide a crafted customBasePath value that is written directly into generated Python import statements.
For defenders, the important nuance is that exploitation is not just about feeding bad input into the generator. The dangerous step is the follow-on import of the generated module. If your pipeline automatically generates Python models from external or tenant-controlled schemas and then imports those files in CI, test, build, or production workflows, this becomes a remote code execution problem in practice.
What Is This Vulnerability?
At its core, CVE-2026-63720 is an input validation failure in code generation logic. The NVD states that attacker-controlled schema input can supply a malicious customBasePath value containing embedded newlines and a dot-free Python expression. That value is then emitted verbatim into a generated from ... import ... statement without proper identifier validation.
That matters because Python import statements are executable syntax, not inert text. If untrusted input is written directly into generated source code, the resulting file can contain attacker-chosen code. In this case, the vulnerable path does not require the original generator process to immediately execute attacker payloads. Instead, the payload is embedded into the generated module and runs when that module is later imported by Python.
In operational terms, this is a code generation supply-chain issue. The vulnerable component may sit in a build pipeline, an internal developer tool, or a service that converts OpenAPI or JSON Schema definitions into Python models. If an attacker can influence schema content and knows the generated code will later be imported automatically, they may be able to pivot from schema submission to code execution inside the environment performing the import.
Technical Notes
A simplified representation of the risky behavior described by NVD looks like this:
# conceptual example only
custom_base_path = attacker_controlled_value
generated_line = f"from {custom_base_path} import BaseModel"
If the application fails to validate that custom_base_path is a safe Python identifier path, malicious content can break expected syntax boundaries and alter the generated module.
Defenders should treat any workflow that converts untrusted schema fields into source code as high risk, especially where generated files are imported automatically:
# common risky pattern in CI or tooling
datamodel-codegen --input schema.json --output models.py
python -c "import models"
Who Is Affected?
The published affected range is clear: datamodel-code-generator versions prior to 0.70.0 are vulnerable. The fixed version is 0.70.0, and organizations should treat all earlier releases as affected unless they have independently backported the upstream fix and verified that change.
The impact depends less on package presence alone and more on how the package is used. Teams are most exposed if they process untrusted or externally sourced schemas, such as OpenAPI definitions, JSON Schema documents, or similar inputs, and then import the generated Python code. This includes SaaS platforms accepting customer schemas, internal tooling that syncs partner APIs into models, CI/CD jobs generating models from repositories outside the trust boundary, and developer automation that treats generated code as immediately safe.
If your environment uses datamodel-code-generator only with tightly controlled internal schemas and does not automatically import the output without review, risk is lower but not zero. Build systems drift over time, and what starts as trusted internal input often expands to partner, marketplace, or customer-provided content. In the absence of a strict trust model, defenders should assume attacker-controlled schema input is plausible.
Technical Notes
You can quickly identify installed versions in Python environments with:
python -m pip show datamodel-code-generator
Or enumerate across multiple environments:
python -m pip freeze | grep -i datamodel-code-generator
If you use Poetry or Pipenv, check lockfiles for pinned vulnerable versions:
grep -R "datamodel-code-generator" poetry.lock Pipfile.lock requirements*.txt
CVSS Score Breakdown
The published base score is 7.5, which places this issue in the High severity range. The NVD snapshot in the provided research did not include the full CVSS vector string, so some component-level scoring details are not available from the source material used here. That means defenders should avoid assuming exact values for attack complexity, privileges required, user interaction, or scope unless they verify the current NVD entry directly.
Even without the vector string, the 7.5 score aligns with the practical impact: arbitrary code execution in environments that import generated modules. The exploit path does depend on a workflow condition, namely attacker influence over schema input and a later import of the generated file. But once those conditions exist, the blast radius can be serious because code runs in the security context of the importing process, which may be a CI worker, developer workstation, container build job, or internal application runtime.
For prioritization, this should generally rank above routine library bugs because it affects build and automation trust boundaries. If your organization ingests schemas from outside your direct control, the score likely understates business risk. Generated code execution in CI or shared build systems can expose secrets, tamper with artifacts, or provide a pivot deeper into your software supply chain.
Exploitation Status
At the time of the referenced research, there was no CISA KEV listing for CVE-2026-63720. That means there is no CISA-confirmed evidence of active exploitation in the wild reflected in KEV. The most accurate operational statement is that active exploitation is not confirmed from the available primary sources.
Likewise, the provided research did not confirm a dedicated public proof-of-concept repository. However, the NVD description is detailed enough that a PoC may be straightforward for a capable researcher to create. That matters because exploit development effort appears modest compared to memory corruption vulnerabilities or bugs requiring precise environmental conditions.
Defenders should not equate “not in KEV” with “safe to defer.” For supply-chain and developer-tooling vulnerabilities, exploitation can remain underreported, especially when abuse occurs inside private CI/CD systems or internal automation. In the absence of confirmed exploitation data, the prudent assumption is that organizations with exposed workflows should patch on an accelerated timeline.
How to Detect It
Detection starts with inventory and workflow mapping. Find where datamodel-code-generator is installed, then identify pipelines that process externally influenced schema files and automatically import generated Python modules. Logs from build systems, developer tools, or application runtimes may reveal generation followed by immediate import or execution of freshly created model files.
Because the root issue involves malicious content in generated source, defenders should inspect generated Python for suspicious import statements, unexpected newlines, or malformed from ... import ... patterns. This is especially important if schema inputs originate from pull requests, external repositories, customer uploads, or API-driven onboarding flows.
Technical Notes
A basic file-content hunt for suspicious generated imports:
grep -REn '^from .*(
|\n)|^from [^ ]*[()]|^from .*;|^from .*__import__' /path/to/generated/code
A simpler review pattern for generated model files:
grep -REn '^from ' /path/to/generated/code
If you collect process execution telemetry, look for generation followed closely by Python import or script execution touching newly created files. A generic Linux process correlation pattern might include:
Parent process: datamodel-codegen
Child or subsequent process: python / python3
File of interest: newly written models.py or equivalent generated module
For SIEM hunting, a generic query approach is:
SELECT timestamp, host, user, process_name, command_line, file_path
FROM process_events
WHERE command_line LIKE '%datamodel-codegen%'
OR command_line LIKE '%datamodel_code_generator%'
OR file_path LIKE '%models.py%';
If you monitor source or artifact repositories, look for suspicious schema fields referencing customBasePath. The exact logging field name depends on your application, but a text-search pattern can still help:
grep -RIn '"customBasePath"' /path/to/schemas /path/to/uploads /path/to/repos
In the absence of application-specific logs, assume visibility is incomplete and prioritize remediation over perfect detection.
Mitigation and Patching
The primary remediation is to upgrade to datamodel-code-generator version 0.70.0 or later. The NVD description explicitly states that versions prior to 0.70.0 are affected, and the upstream fix is associated with commit 545a96c5. If you package this dependency internally, verify your artifact repositories and lockfiles have actually moved to the fixed release.
Beyond patching, harden the workflow around schema ingestion and generated code. Do not treat generated Python from untrusted schemas as safe by default. Generate code in isolated, low-privilege environments; block automatic imports where practical; and require review or static checks before generated modules are executed. If you cannot upgrade immediately, reducing trust in schema sources and removing auto-import behavior materially lowers exploitability.
Technical Notes
Upgrade with pip:
python -m pip install --upgrade "datamodel-code-generator>=0.70.0"
If you pin exact versions in requirements files:
echo 'datamodel-code-generator==0.70.0' >> requirements.txt
python -m pip install -r requirements.txt
For Poetry:
poetry add datamodel-code-generator@^0.70.0
Short-term workaround if patching must wait: stop automatically importing generated modules from untrusted schemas. For example, split generation and execution steps so output is reviewed first:
datamodel-codegen --input untrusted-schema.json --output generated_models.py
python -m py_compile generated_models.py
# review file contents before any import in CI or runtime
You can also isolate generation in a sandboxed container with minimal privileges and no secret access:
docker run --rm --network none --read-only
-v "$PWD:/work" -w /work python:3.12-slim \
sh -c 'pip install "datamodel-code-generator>=0.70.0" && datamodel-codegen --input schema.json --output models.py'
If no upgrade path is immediately available in a managed environment, defenders should assume any externally controlled schema is unsafe and disable that intake path until remediation is complete.
References
The primary source for the vulnerability description and affected range is the NVD record for CVE-2026-63720. That record states the issue affects datamodel-code-generator prior to version 0.70.0 and describes the injection path through customBasePath into generated Python imports.
Upstream references also matter for change validation and remediation tracking. The project repository and linked patch commit indicate the issue was addressed upstream before or as part of the 0.70.0 release line. CISA KEV status was not listed in the provided research, so there is no KEV-confirmed exploitation at the time of writing.
- NVD CVE record for CVE-2026-63720
- Upstream project:
https://github.com/koxudaxi/datamodel-code-generator - Upstream patch commit:
https://github.com/koxudaxi/datamodel-code-generator/commit/545a96c5 - VulnCheck advisory:
https://www.vulncheck.com/advisories/datamodel-code-generator-code-injection-via-unvalidated-custombasepath-schema-field
For defenders, the practical takeaway is straightforward: if datamodel-code-generator is in your toolchain and untrusted schemas can reach it, upgrade to 0.70.0 or later and review any workflow that automatically imports generated Python.
For more information on schema security, check our article on why SMBs are abandoning traditional SIEMs. Additionally, you can learn about specific vulnerabilities like CVE-2026-56274 for further context on security risks.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.