CVE-2026-14610: Assimp Buffer Overflow Vulnerability

CVE-2026-14610 Overview

CVE-2026-14610 is a heap-based buffer overflow in the Open Asset Import Library (Assimp) affecting versions up to 6.0.5. The flaw resides in the Assimp::CSMImporter::InternReadFile function within code/AssetLib/CSM/CSMLoader.cpp, which handles Character Studio Motion (CSM) files. A malformed CSM file with a non-positive frame range triggers an out-of-bounds heap write during preallocation. The vulnerability is classified under [CWE-119] (Improper Restriction of Operations within the Bounds of a Memory Buffer). Exploitation requires local access and the ability to supply a crafted file to an application that uses Assimp for asset import.

Critical Impact
A local attacker who supplies a crafted CSM file to an Assimp-based application can trigger a heap buffer overflow, leading to memory corruption and potential process compromise. A public proof-of-concept exists.

Affected Products

Open Asset Import Library (Assimp) versions up to and including 6.0.5
Applications and game engines that embed vulnerable Assimp builds for CSM file parsing
Content pipelines and 3D asset converters relying on Assimp's CSMLoader

Discovery Timeline

2026-07-03 - CVE-2026-14610 published to NVD
2026-07-06 - Last updated in NVD database
Patch commit - eb84eec580d3f4ba2f0fd87409b7d0744620f11e merged via pull request #6649

Technical Details for CVE-2026-14610

Vulnerability Analysis

Assimp's CSM loader parses motion data that specifies a first and last frame index. The loader uses these values to preallocate storage for frame data before reading records from the file. When last is less than or equal to first, the subtraction last - first produces zero or wraps around as an unsigned integer, defeating the preallocation heuristic. Subsequent writes into the undersized heap buffer overflow adjacent memory. Because the CSM header values are attacker-controlled, any application that feeds untrusted CSM files to Assimp inherits the flaw. Impact is bounded by the local attack vector: an adversary needs the ability to place a file on the system and cause a privileged or long-running Assimp consumer to open it.

Root Cause

The root cause is missing validation of the first and last frame indices before they are used in size arithmetic. The original code only excluded the sentinel value 0x00ffffff for last, but did not enforce last > first. This lets integer underflow reach the allocation size calculation, resulting in a heap buffer overflow ([CWE-119]) when frame data is written.

Attack Vector

Exploitation requires local delivery of a crafted CSM file to a process using Assimp. Typical vectors include 3D modeling tools, game engines, and asset conversion utilities that ingest user-supplied models. The attacker has no network access requirement but does need low-privilege local execution to trigger file parsing. A proof-of-concept archive is publicly available in the Assimp issue tracker.

cpp

// Patch from code/AssetLib/CSM/CSMLoader.cpp
// Prevent heap buffer overflow when last <= first

// If we know how many frames we'll read, we can preallocate some storage
unsigned int alloc = 100;
- if (last != 0x00ffffff) {
+ if (last != 0x00ffffff && last > first) {
    // re-init if the file has last frame data
    alloc = last-first;
    alloc += alloc>>2u; // + 25%

Source: GitHub Commit eb84eec

Detection Methods for CVE-2026-14610

Indicators of Compromise

CSM files where the header last frame index is less than or equal to the first frame index
Unexpected crashes or heap corruption reports (SIGSEGV, SIGABRT, ASan heap-buffer-overflow) in processes linked against libassimp while loading .csm files
Presence of the public proof-of-concept archive poc.zip originating from the linked GitHub attachment on shared file systems

Detection Strategies

Inventory binaries that link against libassimp (statically or dynamically) and flag versions at or below 6.0.5
Instrument CSM parsing with AddressSanitizer or a memory-safety fuzzer to surface out-of-bounds writes on malformed inputs
Monitor for process crashes originating in CSMImporter::InternReadFile via crash reporters, Windows Error Reporting, or Linux coredumpctl

Monitoring Recommendations

Log and alert on child-process crashes from asset import workflows, particularly for .csm file extensions
Track software bill of materials (SBOM) entries for Assimp to identify vulnerable transitive dependencies
Correlate file-write telemetry for .csm files landing in shared or user-writable directories consumed by build agents

How to Mitigate CVE-2026-14610

Immediate Actions Required

Update Assimp to a build that includes commit eb84eec580d3f4ba2f0fd87409b7d0744620f11e or a later release beyond 6.0.5
Rebuild and redistribute any downstream applications and plugins that statically link Assimp
Restrict which users can supply CSM files to privileged Assimp consumers, such as automated conversion services

Patch Information

The upstream fix adds a last > first guard before computing the frame allocation size. Apply the change from commit eb84eec or pull PR #6649. Vendors shipping Assimp should backport the guard into any maintained release branches. Refer to the VulDB entry for CVE-2026-14610 for cross-reference tracking.

Workarounds

Disable the CSM importer at build time by excluding ASSIMP_BUILD_CSM_IMPORTER from the CMake configuration if CSM support is not required
Preprocess untrusted CSM files with a validator that rejects headers where last <= first before passing them to Assimp
Run Assimp-based parsers in a sandbox or low-privilege service account to contain memory-corruption impact

bash

# Build Assimp without the vulnerable CSM importer
cmake -B build \
  -DASSIMP_BUILD_CSM_IMPORTER=OFF \
  -DASSIMP_BUILD_TESTS=OFF \
  -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release