CVE-2026-108384 in dataclasses-avroschema
Summary
by MITRE • 10/13/2026
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.parse_fixed 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The dataclasses-avroschema library serves as a critical utility for developers working with Apache Avro serialization formats in Python environments. It facilitates the bidirectional conversion between Pythonic structures, such as dataclasses and Pydantic models, and their corresponding Avro schema definitions. While this functionality is essential for building robust data pipelines, versions ranging from 0.38.0 through 0.70.5 contain a significant security flaw within the BaseGenerator.parse_fixed method. This vulnerability stems from an improper neutralization of special elements during code generation, specifically when handling fixed type aliases in Avro schemas. The core issue lies in how the library processes and embeds these alias values into the generated Python source code annotations.
When generating Python code for a fixed type with aliases, the generator constructs a types.confixed annotation that includes the list of aliases provided in the schema. If the input schema contains an alias represented as a JSON array or list, the resulting Python expression is correctly formatted with quoted strings, rendering it safe upon import. However, if the alias is specified as a bare string rather than a list within the Avro schema definition, the generator fails to wrap this value in quotes. Instead, it emits the raw string content directly into the generated code as an unquoted Python expression. This lack of proper sanitization means that any arbitrary text provided in the aliases field becomes executable Python code when the resulting module is imported by a target application.
The operational impact of this vulnerability is severe, classified under CWE-94 Improper Control of Generation of Code (Code Injection). An attacker who can influence or supply an Avro schema file used for generating Python modules can inject malicious payloads into the aliases field. Upon importing the generated module, the Python interpreter will execute these injected commands with the privileges of the running process. This allows for arbitrary code execution, potentially leading to full system compromise, data exfiltration, or denial of service depending on the context in which the library is deployed. The vulnerability aligns with ATT&CK technique T1059 Command and Scripting Interpreter, as it leverages the Python interpreter to execute attacker-controlled commands through a trusted code generation process.
Mitigation strategies for this issue involve both immediate remediation and long-term defensive coding practices. Organizations using affected versions of dataclasses-avroschema must upgrade immediately to version 0.70.6 or later, where the vulnerability is addressed by enforcing strict validation that rejects aliases values which are not lists. For environments unable to update instantly, input validation should be implemented at the schema ingestion layer to ensure that all alias fields conform to expected data structures before being passed to the generator. Additionally, developers should avoid importing dynamically generated code from untrusted sources and consider using safer serialization mechanisms or sandboxing techniques if dynamic code generation is a required architectural pattern. Regular auditing of third-party dependencies for known vulnerabilities remains essential to maintaining secure software supply chains.