CVE-2026-108376 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.47.3 through 0.70.5, FieldRepresentation.get_field_default inserts a schema-controlled referenced record name into the callable position of a generated default_factory lambda without validating it as an Avro name. A crafted record name can become an arbitrary Python expression that executes when an instance of the generated model consumes the field default. Version 0.70.6 fixes the vulnerability by rejecting record names that do not match the Avro name grammar.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The dataclasses-avroschema library serves as a critical utility for interoperability between Python applications and Apache Avro serialization formats, allowing developers to generate Avro schemas from Python structures such as dataclasses, Pydantic models, and Faust Records, while also enabling the reverse process of generating Python code from existing Avro schemas. Within versions 0.47.3 through 0.70.5, a significant security flaw exists in the FieldRepresentation.get_field_default method, which is responsible for determining default values for fields during schema generation or model instantiation. This vulnerability stems from an insufficient validation of record names that are referenced within Avro schemas before they are embedded into generated Python code structures. Specifically, when constructing a default_factory lambda expression to handle field defaults, the library inserts the raw string value of a referenced record name directly into the callable position without verifying whether it conforms to the strict grammar rules defined for valid Avro identifiers.
This lack of validation creates a classic Code Injection vulnerability, technically classified under CWE-94 as Improper Control of Generation of Code or Script. Because Python lambda expressions are executable code blocks, an attacker who can influence the record name used in the schema definition can inject arbitrary Python expressions into this position. When an instance of the generated model is created and attempts to consume the field default value, the injected expression is evaluated by the Python interpreter. This mechanism allows for Remote Code Execution if the input originates from a malicious or untrusted source that controls the Avro schema structure. The impact is severe as it bypasses standard type checking mechanisms inherent in Pydantic or dataclasses, effectively turning configuration metadata into executable payload vectors.
The operational impact of this vulnerability extends beyond simple code execution to include potential denial of service and information disclosure depending on the injected expression. An attacker could craft a schema with a record name containing malicious Python syntax that triggers side effects such as file system access, network requests, or resource exhaustion upon model instantiation. This is particularly dangerous in microservices architectures where Avro schemas are frequently exchanged between services via registries like Confluent Schema Registry. If the registry allows users to publish schemas without rigorous validation of internal reference names, any service consuming those schemas and instantiating models will be vulnerable to code execution simply by deserializing or initializing data structures defined by that schema.
Mitigation strategies must focus on both immediate remediation and long-term defensive coding practices. The primary solution is to upgrade the dataclasses-avroschema library to version 0.70.6 or later, where this vulnerability has been patched by implementing strict validation of record names against the Avro name grammar before they are used in generated code contexts. For environments that cannot immediately update dependencies, developers should implement input sanitization at the schema ingestion layer, ensuring that any referenced record names conform to standard alphanumeric and underscore patterns typical of valid identifiers. Additionally, employing static analysis tools or linters configured to detect dynamic evaluation risks can help identify unsafe usage patterns in custom wrapper code around these libraries.
From a threat modeling perspective, this vulnerability aligns with ATT&CK technique T1059, specifically Command and Scripting Interpreter sub-techniques related to Python execution. It highlights the risk associated with treating metadata as executable logic without proper sanitization. Security teams should audit their dependency trees for versions of dataclasses-avroschema within the affected range and prioritize updates in production environments where Avro schemas are dynamically generated or consumed from external sources. Regular security reviews of code generation libraries are essential to prevent similar injection flaws that exploit the flexibility of dynamic language features like lambda expressions and string interpolation.