dataclasses-avroschema EUVD-2026-98978

Exploitation requires (1) use of dataclasses-avroschema's model-generator classes directly to generate Python source from an Avro schema, (2) that the Avro schema's enum symbol values are attacker-controlled or come from an untrusted source, and (3) that the victim subsequently imports the generated Python module, at which point the injected code in the enum class body executes. Limiting factors: this is not triggered by normal schema parsing/serialization - only by the code-generation path; it needs attacker influence over schema content; and it requires the developer/CI step of importing the generated module (UI:R). Affected versions are 0.38.0 through 0.70.5; 0.70.6 neutralizes it by escaping symbol values. Deployments that only generate from trusted, internally-authored schemas, or that never use the generator classes, are not practically exposed.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, base 8.8) rates this as high severity, and the CWE-94 code-injection classification plus the vendor advisory (GHSA-vrq9-94ww-jv3c) and fixing commit confirm the technical reality of arbitrary Python execution. However, the raw score overstates real-world risk for this particular flaw. Exploitation is not a classic remote server attack: it requires a developer to feed an attacker-controlled Avro schema into dataclasses-avroschema's model-generator classes AND then import the generated module - reflected in the UI:R metric. The AV:N label is defensible only because the malicious Avro schema may arrive over a network, but the actual trigger is a build-time/code-generation workflow rather than a running service, so AV:N is arguably generous (verify against your usage - if schemas are only ever locally authored, treat this as closer to local/supply-chain risk). No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit/POC was supplied, so there is no evidence of active or widespread exploitation. Net assessment: a genuine, confirmed RCE-class code-injection bug worth patching promptly for anyone who generates Python from untrusted Avro schemas, but it is a conditional, developer-tooling-scoped issue rather than a mass-exploitable internet-facing vulnerability.

A developer uses dataclasses-avroschema's model-generator classes to generate Python code from an Avro schema supplied by an untrusted or external party (e.g., a schema registry or third-party contributor). The schema contains an enum whose symbol value embeds a double quote and Python statements; render_symbols concatenates it into the generated enum class body, and when the developer imports the generated module the injected code executes. No public exploit code was supplied, but the mechanism is straightforward to reproduce from the fixing commit.