CVE-2026-129478 in Assimp
Summary
by MITRE • 11/15/2026
Assimp through 6.0.6 contains a heap out-of-bounds read vulnerability in glTFCommon::Util::ParseDataURI caused by storing the data offset in a signed char. Attackers can supply a crafted glTF file with a raw data URI whose segment starts beyond byte 127 to crash applications or leak adjacent heap memory.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The Assimp library, specifically through version 6.0.6, contains a critical security flaw within its glTF parsing module that stems from improper type handling during the processing of embedded data URIs. The vulnerability resides in the function glTFCommon::Util::ParseDataURI, which is responsible for decoding and interpreting raw data contained within Uniform Resource Identifiers found in glTF assets. When this function processes a URI segment, it calculates an offset to locate specific data boundaries but incorrectly stores this calculated value in a signed char variable rather than an appropriately sized integer type such as int or size_t. This architectural oversight creates a classic buffer overflow condition where the range of valid values is severely restricted by the eight-bit signed character limit, which typically ranges from negative one hundred twenty-eight to positive one hundred twenty-seven.
This data truncation leads directly to a heap out-of-bounds read vulnerability because any offset value exceeding one hundred twenty-seven will wrap around or be interpreted as a negative number due to two's complement representation rules in C and C++ environments. Consequently, when the application attempts to access memory based on this corrupted index, it may read from invalid locations outside the intended buffer boundaries. An attacker can exploit this by crafting a malicious glTF file that includes a raw data URI with segment parameters designed to trigger this overflow condition. Upon loading such a file, Assimp will miscalculate the memory address, leading to either an application crash or, more dangerously, the leakage of adjacent heap memory contents into the output stream or log files.
The operational impact of this vulnerability is significant for any software ecosystem that relies on Assimp for 3D model processing, including game engines, CAD applications, and visualization tools. A successful exploitation can result in denial of service through application termination if the out-of-bounds read triggers a segmentation fault or access violation. More critically, the ability to leak adjacent heap memory allows an attacker to potentially exfiltrate sensitive information such as encryption keys, user credentials, or other proprietary data residing in nearby memory allocations. This transforms what might appear as a simple parsing error into a serious confidentiality and integrity breach that can facilitate further attacks like arbitrary code execution if combined with additional exploitation techniques targeting the leaked memory layout.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, which describes errors resulting from arithmetic operations exceeding the maximum value of an integer type, leading to unexpected behavior such as negative indices. It also maps closely to CWE-787 Out-of-bounds Read, indicating that memory is accessed beyond its allocated boundary without proper validation. In terms of offensive security frameworks like MITRE ATT&CK, this flaw supports techniques related to Discovery and Collection, specifically allowing an adversary to gather information about the target system's memory structure through side-channel effects or direct data leakage during file processing operations.
Mitigation strategies must focus on both immediate patching and long-term defensive coding practices. The primary remediation is to upgrade Assimp to a version later than 6.0.6 where this type handling error has been corrected, ensuring that offset variables are declared using types capable of holding the full range of expected memory addresses without truncation. Developers integrating Assimp should also implement strict input validation for all glTF files before processing them in untrusted environments. This includes validating URI structures and enforcing maximum length constraints on data segments to prevent excessively large offsets from being processed at all. Additionally, employing static analysis tools that detect integer overflow patterns and using memory sanitizers like AddressSanitizer during development can help identify similar vulnerabilities early in the software lifecycle.