YOLOv9 CVE-2026-111991

Exploitation requires the victim to load an attacker-controlled or tampered ONNX model file into YOLOv9 via DetectMultiBackend, where the ONNX metadata fields 'names' and 'stride' are evaluated as code. The specific prerequisite is the use of the ONNX backend path that parses model metadata (loading a .onnx weights file), not PyTorch .pt-only usage. Limiting factors: the attacker cannot trigger this against a passive/running service - a user or automated pipeline must obtain and load the untrusted model (UI:P/UI:R), so the realistic threat is a supply-chain / malicious-pretrained-model scenario rather than direct remote compromise of a server.

Signals are mixed and point to a low operational priority despite a serious weakness class. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) yields only 2.1 because VulDB rated impact as VC:L/VI:L/VA:L (Low across the board), yet the CWE is CWE-74 code injection via eval of ONNX metadata (names/stride) in DetectMultiBackend.__init__ - a weakness that realistically produces arbitrary code execution in the loading process, not merely limited impact. This is a conflict worth flagging: the Low impact metrics appear to understate a code-injection flaw whose true impact is closer to full process compromise (see assessed vectors below). Mitigating the risk, exploitation is NOT zero-click: UI:P/UI:R means the victim must load an attacker-supplied malicious model file, so there is no spraying against a listening service. Exploitation status is 'publicly available exploit code exists' (POC disclosed per the issue report) - this is NOT active exploitation; the CVE is not in CISA KEV and no EPSS score was provided in the input. Net: a genuine code-execution bug in a developer-facing ML repo, but gated behind user-initiated loading of untrusted models and with no evidence of in-the-wild use, so it is a patch-when-convenient / supply-chain-hygiene item rather than an emergency.

An attacker publishes a trojanized YOLOv9 .onnx model (e.g., on a model hub, in a repo, or via a 'pretrained weights' link) whose embedded metadata fields names/stride contain injected Python. When a developer or inference pipeline loads it through DetectMultiBackend, the ONNX metadata handler evaluates the crafted strings and runs the attacker's code in the victim's process. A public proof-of-concept has been disclosed via the project's issue tracker (issue #670), lowering the effort to reproduce.