CVE-2026-108377 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.62.3 through 0.70.5, ClassRepresentation.render_metaclass inserts a schema-controlled Avro record name into the quoted Meta.schema_name field of generated Python source without escaping it. A crafted name can terminate the string literal and inject statements into the generated class body, which execute when the generated module is imported. Version 0.70.6 fixes the vulnerability by escaping schema values rendered into generated string literals.
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 bridge between Python object definitions and Avro serialization formats, allowing developers to generate Avro schemas from Python dataclasses or Pydantic models while also enabling code generation from existing Avro schemas. This dual functionality is critical for systems relying on strict schema validation and interoperability in distributed architectures. However, versions ranging from 0.62.3 through 0.70.5 contain a significant security flaw within the ClassRepresentation.render_metaclass function. The vulnerability arises when the library generates Python source code based on an Avro schema that contains a record name controlled by an external or untrusted input. Instead of properly sanitizing this input, the implementation inserts the schema-controlled Avro record name directly into the quoted Meta.schema_name field within the generated Python class body without applying any escaping mechanisms.
This lack of proper string escaping creates a classic code injection vector. If an attacker can influence the Avro schema's record name, they can craft a value that includes characters such as quotes or newlines to terminate the existing string literal prematurely. Once the string context is broken, subsequent content in the crafted input is interpreted not as data but as executable Python statements within the class body. When a developer imports the generated module, these injected statements are executed immediately during the import process. This constitutes an arbitrary code execution vulnerability, allowing for remote code execution if the source of the Avro schema is untrusted or compromised. The impact extends beyond simple script injection; it can lead to full system compromise depending on the privileges under which the Python interpreter runs and the sensitivity of the data being processed by the generated classes.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), specifically involving unsanitized input in code generation contexts. It also maps to MITRE ATT&CK techniques related to Command and Scripting Interpreter abuse, where an attacker leverages the application's own functionality to execute arbitrary commands. The root cause lies in the failure to treat dynamic schema values as data rather than executable code during the template rendering phase of source file generation. This is a common pitfall in libraries that perform metaprogramming or code synthesis without rigorous input validation and output encoding strategies appropriate for the target language syntax.
The vulnerability was addressed in version 0.70.6, which implements proper escaping logic to ensure that schema values rendered into generated string literals are safely encoded. This fix prevents special characters from breaking out of their intended string context, thereby neutralizing the injection attack vector. Organizations using dataclasses-avroschema should immediately upgrade to version 0.70.6 or later to mitigate this risk. For those unable to update instantly, it is imperative to ensure that all Avro schemas processed by the library originate from trusted sources and do not contain user-controlled record names. Additionally, implementing strict input validation on schema definitions before they are passed to the code generation engine can provide a layer of defense in depth against such injection attempts.