CVE-2025-15538: 
NixOS vulnerability analysis and mitigation

CVE-2025-15538 is a heap use-after-free vulnerability in the Open Asset Import Library (Assimp) affecting all versions up to and including 6.0.2. The flaw resides in the Assimp::LWOImporter::FindUVChannels() function within /src/assimp/code/AssetLib/LWO/LWOMaterial.cpp, triggered when processing malformed LightWave Object (LWO) files. The CVE was published on January 18, 2026, with a proof-of-concept exploit publicly disclosed at the same time. It carries a CVSS v3.1 base score of 7.8 (High) per NVD, while the CNA (VulDB) rates it 5.3 (Medium) (GitHub Issue, Red Hat Bugzilla).

The root cause is a use-after-free condition (CWE-416) combined with improper memory buffer handling (CWE-119) in the LWO file parser. During LWO2 file loading, LoadLWO2VertexMap() calls CreateNewEntry() which resizes a std::vector<bool> (a UV channel bitmap), causing the underlying storage to be reallocated and the old buffer freed. Subsequently, FindUVChannels() at LWOMaterial.cpp:400 dereferences a std::_Bit_reference that still points to the freed heap region, resulting in a heap-use-after-free detected by AddressSanitizer. Exploitation requires a locally accessible, specially crafted LWO file to be processed by the Assimp library; no network access or user interaction beyond supplying the malicious file is needed. A PoC file (assimp_poc10.zip) and full ASAN crash trace have been publicly released (GitHub Issue, PoC File).

Successful exploitation can result in memory corruption leading to information disclosure, data integrity violations, or denial of service (crash) of the application processing the malicious LWO file. Under CVSS v3.1 (NVD assessment), the vulnerability is rated with high confidentiality, integrity, and availability impact, reflecting the potential for arbitrary memory reads or writes in the context of the vulnerable process. The attack is limited to local access and does not directly enable remote code execution or lateral movement, but applications that ingest untrusted 3D model files (e.g., game engines, 3D editors, content pipelines) are at elevated risk if they process user-supplied LWO files (Red Hat Bugzilla, GitHub Issue).

A public proof-of-concept exploit (assimp_poc10.zip) was disclosed alongside the CVE report on January 18, 2026, and is referenced directly in the NVD entry. The EPSS score is very low at 0.013%, reflecting limited automated exploitation likelihood, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution or in-the-wild exploitation has been reported. The CVSS v4.0 exploit maturity is rated "Proof of Concept" (GitHub Issue, PoC File).

1. Prepare the environment: Obtain a system with Assimp version ≤ 6.0.2 installed, either as a standalone tool or as a library used by an application (e.g., a 3D content pipeline or game engine).
2. Craft or obtain a malicious LWO file: Use the publicly available PoC file (assimp_poc10.zip) or craft a custom LWO2 file that triggers the UV channel vector reallocation during parsing — specifically, a file structured so that LoadLWO2VertexMap() causes a std::vector<bool> resize that frees the backing buffer while a reference to it remains live.
3. Trigger file processing: Execute the Assimp tool or invoke the vulnerable application to process the malicious LWO file, e.g.: ./assimp extract assimp_poc10 /dev/null
4. Trigger the use-after-free: The parser calls LoadLWO2File() → LoadLWO2VertexMap() → CreateNewEntry() which resizes the UV channel bitmap, freeing the old buffer. When InternReadFile() subsequently calls FindUVChannels() at LWOMaterial.cpp:400, it dereferences the freed pointer, triggering the heap-use-after-free.
5. Achieve impact: Depending on heap layout and runtime conditions, the outcome may be a crash (DoS), memory disclosure, or potential memory corruption that could be further developed into code execution (GitHub Issue, PoC File).

• Process Behavior: Unexpected crash or abort of applications using Assimp when processing LWO files; ASAN output containing heap-use-after-free in Assimp::LWOImporter::FindUVChannels or LWOMaterial.cpp:400.
• Logs: Application crash logs referencing LWOMaterial.cpp, LWOLoader.cpp, or FindUVChannels; core dumps from Assimp-linked processes after LWO file ingestion.
• File System: Presence of unexpected or externally supplied .lwo files in directories processed by Assimp-based applications; presence of assimp_poc10 or similarly named files.
• Network (if applicable): Unusual file uploads to services that accept 3D model files (e.g., .lwo format) from untrusted sources, particularly if followed by service crashes.

Organizations should update Assimp to a version beyond 6.0.2 that addresses this issue; the fix is tracked via Red Hat Bugzilla (bug 2430745) and the upstream Assimp issue tracker. As interim mitigations, restrict local access to systems running vulnerable Assimp versions, implement input validation and file integrity checks for LWO files, and sandbox or restrict the execution environment where Assimp processes untrusted 3D model files. Avoid processing LWO files from untrusted sources until a patched version is deployed (Red Hat Bugzilla, Red Hat CVE).

Red Hat has tracked this vulnerability via their security response process (Bugzilla bug 2430745) and assigned it medium priority/severity. The CVE was announced via the @CVEnew account on X (Twitter) shortly after publication. No significant broader media coverage or notable researcher commentary beyond the initial disclosure and PoC submission has been identified (Red Hat CVE, Red Hat Bugzilla).