Assimp EUVD-2026-102359

Exploitation requires the target application to import an attacker-supplied Ogre3D asset through Assimp's Ogre importer - specifically a crafted .mesh file together with a .skeleton file whose submesh bone assignment references a bone index that does not exist in the skeleton, so BoneById() returns null and the subsequent dereference crashes the process. Limiting factors that reduce real-world risk: the vector is LOCAL (AV:L) with no network exposure, it requires user/application interaction to process the malicious file (UI:P), it needs no authentication (PR:N), and the outcome is limited to a crash of the host process (availability only) with no code execution or data disclosure. Risk is therefore concentrated in workflows that automatically or routinely ingest untrusted 3D model files.

This is a genuine but modest-severity availability-only issue, not a top priority. The authoritative CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 6.8 (Medium) and tells a consistent story: the attack is LOCAL (AV:L) and requires passive user interaction (UI:P) - the victim must import a malicious file - with impact confined to availability (VA:H), i.e. a crash, and zero confidentiality or integrity impact (VC:N/VI:N). This aligns cleanly with the CWE-476 NULL pointer dereference and the Denial-of-Service classification. No EPSS score, KEV status, or SSVC decision data was provided in the input, so exploitation probability and automatability cannot be quantified; absence of these is a data gap, not evidence of low risk per se. The vulnerability was reported by VulnCheck and is accompanied by a public technical write-up (hackmd) describing the crafted .mesh/.skeleton trigger, so a reproducible crash recipe is publicly documented. Net assessment: real, easily reproducible, but low real-world urgency because it yields only a crash of the host process (no RCE, no data exposure) and requires the target to process an attacker-supplied 3D asset - this is a high-CVSS-for-a-DoS but low-impact issue in practice. Patch/fixed-version information is NOT present in the provided data and should be confirmed against the Assimp repository and the VulnCheck advisory before remediation planning.

An attacker distributes a malicious Ogre3D asset (a crafted .mesh paired with a .skeleton file referencing a non-existent bone) and induces a victim application or user to import it via Assimp's Ogre importer. When BoneById() returns null for the missing bone index, the unchecked dereference in OgreStructs.cpp crashes the host process, causing a denial of service. A public technical write-up documents the crash trigger, so reproduction is straightforward.