CVE-2026-108375: dataclasses-avroschema allows code injection through fixed-type aliases supplied as a bare string
dataclasses-avroschema generates Avro schemas from Python dataclasses, Pydantic models, and Faust Records and generates Python code from Avro schemas. From version 0.38.0 through 0.70.5, BaseGenerator.parsefixed interpolates a fixed type's aliases value directly into a generated types.confixed annotation. A list is represented with quoted entries, but a bare string is emitted as an unquoted Python expression and evaluated when the generated module is imported, allowing arbitrary code execution from a crafted schema. Version 0.70.6 fixes the vulnerability by rejecting aliases values that are not lists.
Other sources
dataclasses-avroschema generates Avro schemas from Python dataclasses, Pydantic models, and Faust Records and generates Python code from Avro schemas. From version 0.38.0 through 0.70.5, FieldRepresentation.getfielddefault inserts schema-controlled string, UUID, bytes, and fixed field defaults into quoted literals in generated Python source without escaping them. A crafted default can terminate the literal and inject statements into the generated module, which execute when the module is imported. Version 0.70.6 fixes the vulnerability by escaping schema values rendered into generated string literals.
— NVD
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
dataclasses-avroschemato a version that resolves this vulnerability.Fixed in 0.70.6
Event History
Frequently Asked Questions
Who is exposed to exploitation?
Applications using dataclasses-avroschema versions 0.38.0 through 0.70.5 are exposed if they generate Python code from an Avro schema that an attacker can craft or influence, and then import the generated module. The attacker does not need prior privileges, but user interaction is required to cause the generated module to be imported.
What specifically must an attacker control?
The attacker needs to supply a fixed type whose aliases field is a bare string rather than a list. That string is emitted as an unquoted Python expression in the generated types.confixed annotation and is evaluated during module import.
Is a normal list-form aliases value affected?
No. List aliases are generated with quoted entries; the vulnerable behavior occurs when aliases is provided as a bare string.
What should be done if an immediate upgrade is not possible?
Do not generate and import Python modules from untrusted Avro schemas, and reject fixed-type aliases values unless they are lists before processing schemas. Upgrade to version 0.70.6 when possible, which rejects aliases values that are not lists.
How can I determine whether generated code may be unsafe?
Review schemas processed by affected versions for fixed types with aliases represented as a string instead of a list. Also inspect generated modules for types.confixed annotations containing an unquoted aliases expression before importing them.