CVE-2025-15538
Use-After-Free in Assimp LWOImporter Causes Local Exploit
Publication date: 2026-01-18
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| assimp | assimp | to 6.0.2 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability is a heap-use-after-free flaw in the Open Asset Import Library (Assimp) up to version 6.0.2, specifically in the function Assimp::LWOImporter::FindUVChannels within LWOMaterial.cpp. It occurs when processing specially crafted LWO (LightWave Object) files, where the program accesses memory that has already been freed due to improper management of a std::vector<bool> container used for UV channel data. This leads to undefined behavior such as crashes or potential arbitrary code execution when the vulnerable function attempts to read from the freed memory. [2, 3, 4]
How can this vulnerability impact me? :
This vulnerability can cause the affected application to crash or behave unexpectedly when processing maliciously crafted LWO files. It may also allow an attacker with local access to execute arbitrary code, compromising the confidentiality, integrity, and availability of the system using the Assimp library for 3D model importing. The exploit has been publicly disclosed and is considered easy to exploit locally, leading to denial of service or potential code execution. [2, 3, 4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by reproducing the issue using the publicly available proof-of-concept exploit. Detection involves compiling the Assimp library with AddressSanitizer enabled and running the `assimp extract` command on a crafted malicious LWO file (such as the provided `assimp_poc10`). The AddressSanitizer will report heap-use-after-free errors during this process. Suggested commands include cloning the Assimp repository, checking out the specific commit, compiling with Clang and AddressSanitizer (`-fsanitize=address`), and executing: `assimp extract assimp_poc10` to trigger the detection. [2]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include avoiding processing untrusted or malicious LWO files with the affected Assimp versions up to 6.0.2. Since no known mitigations or patches currently exist, it is recommended to consider replacing the affected Assimp library with an alternative or updated version once available. Restrict local access to systems running vulnerable versions to prevent exploitation, as the attack requires local access. [4]