Инструмент преобразует входную схему (JSON Schema, OpenAPI, YAML) в исходный код моделей Python. Некоторые поля схемы попадают непосредственно в генерируемый код, поэтому проект проверяет их как точечные Python-идентификаторы перед использованием — специально для предотвращения инъекций. Поле расширения схемы customBasePath — единственное родственное поле, которое пропускает эту проверку. Его значение попадает без санитизации в оператор from ... import ... в генерируемом выводе. Атакующий, контролирующий входную схему, может внедрить произвольный код Python с помощью переводов строк и выражения без точек; он выполняется в момент импорта сгенерированного модуля, что является обычным следующим шагом после генерации моделей.

Это неполное исправление CVE-2026-55415 (GHSA-5578-w22f-pfx9), которое ужесточило защиту родственных полей customTypePath и x-python-import от именно этого класса атак. То исправление не затронуло customBasePath, который достигает того же стока без проверки и оставался эксплуатируемым вплоть до 0.68.1 и в main до 0.70.0.

Воздействие

Произвольное выполнение кода Python в процессе, который импортирует или запускает сгенерированные модели: на машине разработчика, в CI-раннере или в любом сервисе, который генерирует, а затем загружает модели. Конфиденциальность, целостность и доступность хоста полностью скомпрометированы и ограничены только привилегиями этого процесса.

Серьёзность полностью зависит от того, где выполняется кодогенерация по недоверенным входным данным:

• Локальный процесс разработки. Разработчик генерирует модели из схемы, автором которой он не является (загруженный по сети или сторонний OpenAPI-документ), и импортирует результат. Код выполняется от имени разработчика. Это случай, соответствующий присвоенному базовому баллу.
• CI / сборочный конвейер. Конвейер генерирует модели из сторонних спецификаций и запускает тесты. Код выполняется на CI-раннере с теми учётными данными, которыми тот располагает.
• Сетевой сервис (экологический потолок, до 9.8). Сервис, который принимает схему по HTTP, генерирует модели и загружает их — например, B2B-платформа, автоматически генерирующая SDK из предоставленных клиентами OpenAPI-спецификаций, — выполняет код атакующего на сервере из одного неаутентифицированного запроса без взаимодействия с пользователем. Именно такое развёртывание собственный сопутствующий бюллетень мейнтейнера (GHSA-m34r) называет входящим в область действия.

Кто затронут: Любое использование datamodel-code-generator < 0.70.0, которое (1) генерирует модели из схемы, значение customBasePath в которой подвержено влиянию атакующего, и (2) импортирует или выполняет сгенерированный модуль. Стандартный workflow «сначала кодогенерация, затем импорт» по своей сути удовлетворяет условию (2).

Кто не затронут:

• Все, кто использует 0.70.0 или новее, где customBasePath проверяется.
• Workflow'ы, которые генерируют модели только из полностью доверенных собственных (first-party) схем.
• Workflow'ы, которые генерируют исходный код, но никогда не импортируют и не выполняют его (редкий случай, поскольку генерация моделей для их использования и есть смысл инструмента).

Охват

Технические подробности

Корневая причина

Значение поля схемы customBasePath попадает в генерируемый код без каких-либо ограничений на идентификатор. Важны три точки в кодовой базе (пути указаны относительно src/datamodel_code_generator/):

• Точка входа схемы. В parser/jsonschema.py определяется поле custom_base_path с alias="customBasePath" (строка ~644), которое используется через _resolve_base_class(...) в нескольких местах вызова.
• Отсутствующая проверка. parser/base.py, _resolve_base_class (строка ~1665), возвращает значение только после локального normalize() (дедупликация/обрезка). Проверка идентификатора не применяется.
• Сток. imports.py, Import.from_full_path() (строка ~35), выводит значение дословно в виде строки from ... import .... Значение также используется как базовый класс в model/base.py set_base_class (строка ~1324) и подставляется как есть шаблоном модели (class {{ class_name }}({{ base_class }}):).

Поскольку значение записывается в исходный код Python без ограничений, встроенные переводы строк и выражение без точек сохраняются в выводе как отдельные разбираемые строки, и средняя строка выполняется при импорте.

Полезная нагрузка по необходимости не содержит точек. Import.from_full_path разбивает значение по символу ., поэтому обычный вызов os.system(...) был бы разорван. Использование getattr(__import__('os'),'system')(...) позволяет избежать любых ., сохраняя разрешение того же вызова, а окружающие переводы строк сохраняют синтаксическую корректность выводимых строк from ... import ..., благодаря чему внедрённая средняя строка выполняется без ошибок.

Почему это пережило ужесточение кодовой базы

Это не проект, который пренебрегал защитой от инъекций. Мейнтейнер неоднократно ужесточал защиту именно от этого класса атак в нескольких бюллетенях (GHSA-5578, m34r, 8m8r, wjv6), каждый раз пропуская управляемую схемой строку импорта или типа через _validate_dotted_python_identifier_path до того, как она достигнет кодогенерации. Родственные поля customTypePath (проверяется в parser/jsonschema.py, строки ~4956, 5202) и x-python-import (строка ~2096) обе проходят через этот валидатор.

customBasePath — единственное родственное поле без такого вызова. Он достигает того же стока Import.from_full_path другим путём (_resolve_base_class), который никогда не был подключён к проверке, применявшейся к другим полям. Дефект сохранился именно потому, что окружающая защита выглядела полной: рецензент, ищущий непроверяемые строки импорта, видит валидаторы на тех полях, которые проверяет в первую очередь, а этот параметр проходит через хелпер, который выглядит как разрешение базового класса, а не как обработка импорта. Это пробел в систематическом исправлении, а не его отсутствие — именно поэтому он сохранился вплоть до последнего релиза.

Предусловия эксплуатации

Атакующему необходимо:

1. Цель, использующая datamodel-code-generator < 0.70.0.
2. Контроль над значением customBasePath в схеме, которую будет обрабатывать цель, — на практике это достигается предоставлением или изменением входной схемы (сторонний документ OpenAPI/JSON Schema или схема, отправленная в сервис).
3. Импорт или запуск сгенерированного модуля целью — это обычный workflow «сначала кодогенерация, затем использование».

Атакующему не требуется аутентификация или повышенные привилегии (PR:N). Базовый балл отражает то, что жертва выполняет обычное действие «сгенерировать и импортировать» (UI:R в v3.1 / UI:A в v4.0); развёртывание в виде сетевого сервиса устраняет даже это — именно отсюда берётся экологический балл 9.8.

Подтверждение концепции

Следующее было выполнено против реального, неизменённого пакета. Воспроизведение:

Входные данные атакующего (attack.json):

Сгенерированный generated_models.py в уязвимой версии (0.68.1):

Вызов атакующего попадает в сгенерированный исходный код дословно.

При импорте: команда выполняется. В проверенном запуске внедрённый маркер был выведен в stdout, а RCE_PROOF.txt был создан с именем текущего пользователя (root), что подтверждает произвольное выполнение команд через обычный workflow «сгенерировать и импортировать».

В исправленной версии (0.70.0): та же схема отклоняется до генерации какого-либо кода:

Файл не создаётся. Сообщение об отклонении прямо указывает на исправление: теперь значение должно быть путём из точечных Python-идентификаторов.

Вариант с сетевым сервисом. Было продемонстрировано, как неаутентифицированный loopback HTTP-сервис, который принимает схему через POST, генерирует модели и импортирует их, выполняет команду атакующего на сервере из одного неаутентифицированного curl и без какого-либо взаимодействия с пользователем. Именно такая форма развёртывания стоит за экологическим баллом 9.8. Файлы сервиса и атаки включены в репозиторий PoC.

Смотреть демо

Устранение

Обновитесь до datamodel-code-generator 0.70.0 или новее:

Версия 0.70.0 пропускает customBasePath через ту же проверку точечных идентификаторов, которая уже применяется к customTypePath и x-python-import, поэтому значение, не являющееся корректным путём идентификатора, отклоняется до генерации кода.

Если вы не можете обновиться немедленно: не генерируйте модели из схем, которые вы не контролируете полностью, и не импортируйте и не выполняйте модули, сгенерированные из недоверенных схем. В затронутых версиях нет конфигурационного флага, который добавил бы недостающую проверку; обновление — надёжное решение.

Примечание для тех, кто переиспользует внутренности генератора. Дефект заключался в отсутствующем вызове проверки на одном пути кода в Import.from_full_path, а не в изъяне самого стока. Любой нижестоящий проект, который подставляет управляемые схемой строки в генерируемый код, должен проверять каждое такое поле как точечный идентификатор, а не только те, что проходят через очевидный путь обработки импорта.

О балле CVSS

VulnCheck (CNA) присвоил 7.5 (High), что совпадает с базовым вектором, который мейнтейнер использовал для родительского бюллетеня CVE-2026-55415, поскольку это тот же класс инъекций, тот же сток Import.from_full_path и то же воздействие.

• AV:N: схемы обычно получаются по сети (загруженные или сторонние документы OpenAPI / JSON Schema).
• AC:H: эксплуатация зависит от того, сгенерирует ли жертва модели из вредоносной схемы, а затем импортирует или запустит сгенерированный код.
• PR:N / UI:R (v3.1): без привилегий атакующего; жертва выполняет обычный workflow кодогенерации и импорта.
• C:H / I:H / A:H: полное произвольное выполнение кода на хосте.

Экологический потолок — 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), и он применим именно к развёртыванию в виде сетевого сервиса, где генератор работает с недоверенными схемами и взаимодействие жертвы не требуется. Эта цифра — экологическое примечание для такого развёртывания, а не присвоенный базовый балл. Указывать оба значения и чётко разъяснять, какое из них что означает, — честная подача: база — 7.5, и до 9.8 балл достигает только в случае открытого сервиса.

Хронология раскрытия

Благодарность

Обнаружено и сообщено Rahul Karne, исследователем безопасности и старшим членом IEEE (IEEE Senior Member). Его исследования сосредоточены на инъекциях и дефектах обработки входных данных в open-source пакетах с большим числом зависимых проектов, включая CVE-2026-65321 (SQL-инъекция в PyAthena) и ужесточение защиты родительского класса, связанное с этой находкой.

Контакт: [email protected] · GitHub: rahulreddykarne

Ссылки

• NVD (CVE-2026-63720): https://nvd.nist.gov/vuln/detail/CVE-2026-63720
• Запись CVE: https://www.cve.org/CVERecord?id=CVE-2026-63720
• Бюллетень VulnCheck: https://www.vulncheck.com/advisories/datamodel-code-generator-code-injection-via-unvalidated-custombasepath-schema-field
• Коммит с исправлением 545a96c5: https://github.com/koxudaxi/datamodel-code-generator/commit/545a96c5
• Родительский бюллетень (неполное исправление): CVE-2026-55415 / GHSA-5578-w22f-pfx9
• Репозиторий проекта: https://github.com/koxudaxi/datamodel-code-generator
• Статистика загрузок: https://pepy.tech/projects/datamodel-code-generator

Пресса

Запросы СМИ: [email protected]. Полный PoC (схема атакующего, демонстрация сетевого сервиса) и дополнительные технические детали доступны по запросу.