Summary
dataclasses-avroschema can place a schema-controlled record name into the callable position of a generated Python default factory without validating that name as an Avro identifier. If an attacker can influence a referenced record name and the generated model later consumes the default, the crafted value may execute an arbitrary Python expression in the application process.
dataclasses-avroschema can place a schema-controlled record name into the callable position of a generated Python default factory without validating that name as an Avro identifier. If an attacker can influence a referenced record name and the generated model later consumes the default, the crafted value may execute an arbitrary Python expression in the application process.
Affected context
The vulnerability occurs in dataclasses-avroschema versions that generate Python models or schema-related code from Avro definitions. It becomes risky when a referenced record name is obtained from a schema or other controllable input and is inserted into generated default-factory code before being checked against the Avro name grammar.
The vulnerability occurs in dataclasses-avroschema versions that generate Python models or schema-related code from Avro definitions. It becomes risky when a referenced record name is obtained from a schema or other controllable input and is inserted into generated default-factory code before being checked against the Avro name grammar.
Exploit preconditions
- Attack surface: Avro schema processing and Python model code generation
- Required access: Ability to supply or modify an Avro schema, or otherwise influence a referenced record name
- Trigger point: Instantiation of a generated model that evaluates the affected field's default factory
- Why exploitation is possible: The record name is placed in a callable expression without strict identifier validation, allowing crafted input to be interpreted as Python code
- Attack surface: Avro schema processing and Python model code generation
- Required access: Ability to supply or modify an Avro schema, or otherwise influence a referenced record name
- Trigger point: Instantiation of a generated model that evaluates the affected field's default factory
- Why exploitation is possible: The record name is placed in a callable expression without strict identifier validation, allowing crafted input to be interpreted as Python code
Why this happens
The underlying flaw is dynamic code generation that treats schema metadata as a trusted Python expression. A referenced record name is inserted into the callable position of a generated lambda without first restricting it to valid Avro name characters and structure. This maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced data can alter executable code produced by the application.
The underlying flaw is dynamic code generation that treats schema metadata as a trusted Python expression. A referenced record name is inserted into the callable position of a generated lambda without first restricting it to valid Avro name characters and structure. This maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced data can alter executable code produced by the application.
Potential impact
- An attacker may execute arbitrary Python expressions in the consuming application process
- The application could disclose, modify, or delete accessible data
- Credentials, tokens, or environment information could be exposed
- The affected service may be used for further compromise or lateral movement
- An attacker may execute arbitrary Python expressions in the consuming application process
- The application could disclose, modify, or delete accessible data
- Credentials, tokens, or environment information could be exposed
- The affected service may be used for further compromise or lateral movement
General mitigation guidance
Mitigation generally focuses on preventing schema data from becoming executable source code.
Common defensive patterns include:
- Validate referenced record names against the complete Avro name grammar before code generation
- Generate callable references from trusted, structured symbols rather than string interpolation
- Prefer data-driven default handling over dynamically generated executable expressions
- Apply strict schema validation before generating models or Python code
- Run schema-processing workloads with least-privilege permissions and restricted access to secrets
- Treat externally supplied schemas as untrusted even when they conform to a broader serialization format
Mitigation generally focuses on preventing schema data from becoming executable source code.
Common defensive patterns include:
- Validate referenced record names against the complete Avro name grammar before code generation
- Generate callable references from trusted, structured symbols rather than string interpolation
- Prefer data-driven default handling over dynamically generated executable expressions
- Apply strict schema validation before generating models or Python code
- Run schema-processing workloads with least-privilege permissions and restricted access to secrets
- Treat externally supplied schemas as untrusted even when they conform to a broader serialization format
How teams detect issues like this
Organizations can look for:
- Static analysis rules identifying string interpolation or concatenation inside generated Python expressions
- Code review signals where schema fields, record names, or metadata are inserted into callable positions
- Tests using invalid and adversarial Avro names to verify rejection before code generation
- Policy checks requiring allowlisted identifier validation and structured symbol resolution
- Runtime monitoring for unexpected model-generation behavior or child-process activity in schema-processing services
Automated security review tools may help identify dynamic code-generation patterns, but findings should be validated against the actual generation and execution flow.
Organizations can look for:
- Static analysis rules identifying string interpolation or concatenation inside generated Python expressions
- Code review signals where schema fields, record names, or metadata are inserted into callable positions
- Tests using invalid and adversarial Avro names to verify rejection before code generation
- Policy checks requiring allowlisted identifier validation and structured symbol resolution
- Runtime monitoring for unexpected model-generation behavior or child-process activity in schema-processing services
Automated security review tools may help identify dynamic code-generation patterns, but findings should be validated against the actual generation and execution flow.
