RAE EUVD-2026-98203

Exploitation requires the attacker to control the 'target' argument within a model configuration consumed by the Config-Driven Model Instantiation component, specifically the get_obj_from_str function in src/utils/model_utils.py, which dynamically resolves and instantiates arbitrary Python objects from the config string. Limiting factors: the attack must be performed locally (AV:L), the attacker must already hold at least low-level privileges (PR:L), and a user must actively load/run the malicious configuration (UI:P) - i.e., it is not remotely reachable and is primarily a risk when loading untrusted config files. There is no default-configuration remote unauthenticated path.

This is a low-priority, low-real-risk issue despite the alarming 'code injection' (CWE-94) and 'RCE' framing. All signals point the same direction: the CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:P) requires LOCAL access, already-held privileges (PR:L), and active user interaction (UI:P), and all three impact metrics are only Low (VC:L/VI:L/VA:L), yielding a base score of just 2.4. There is no CISA KEV listing and no public proof-of-concept referenced, so exploitation status is 'no public exploit identified at time of analysis.' The vulnerability is the classic config-driven instantiation pattern (get_obj_from_str resolving a 'target' string to an importable Python object), where the attacker must already control the configuration that the victim loads and runs - meaning the 'injection' is largely self-inflicted code execution rather than a remotely reachable flaw. The only non-aligned nuance is the 'RCE' tag, which overstates severity relative to the Local attack vector and Low impacts; treat 'RCE' as aspirational labeling, not network-exploitable remote code execution. The report originates solely from VulDB and the upstream project has not yet acknowledged the GitHub issue, so vendor confirmation is absent.

An attacker who can supply or tamper with a model configuration file crafts a malicious 'target' value that get_obj_from_str resolves and instantiates, causing attacker-chosen Python code to execute when the victim loads that config locally. Because exploitation requires local access, prior low-level privileges, and the victim actively loading the poisoned config (UI:P), this is realistic only against someone who ingests untrusted config files. No public exploit code was identified at the time of analysis.