What is the CVSS score of CVE-2026-71266?

CVE-2026-71266 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.1%.

Which versions of tinyobjloader-c are affected by CVE-2026-71266?

tinyobjloader-c, a library used to parse 3D model files in applications ranging from gaming engines to design software, contains a stack-based buffer overflow that enables arbitrary code execution…

How to fix or mitigate CVE-2026-71266?

Within 24 hours, audit your technology stack to identify all applications and services using tinyobjloader-c (including transitive dependencies through build manifests and dependency trees); document scope and whether those applications accept external 3D asset loads or uploads from users. Within 7 days, implement interim controls: disable or restrict external MTL/OBJ file loading where operationally feasible, require all 3D assets to be sourced from internally-verified repositories only, and isolate systems that process 3D models from sensitive infrastructure using network segmentation. Within 30 days, pursue one of three paths: migrate to an actively maintained alternative library with equivalent functionality and security hardening, engage with community-maintained security forks of tinyobjloader-c if available, or implement defense-in-depth through runtime memory protections (address space layout randomization and stack canaries on affected systems) combined with strict file validation and sandboxed parsing.

tinyobjloader-c CVE-2026-71266

EUVD-2026-53351 HIGH

Stack-based Buffer Overflow (CWE-121)

2026-08-05 TuranSec

GHSA-gr59-p4q8-r75g

Buffer Overflow Stack Overflow Tinyobjloader C

7.8

CVSS 3.1 · Vendor: TuranSec

Severity by source

Vendor (TuranSec) PRIMARY

7.8 HIGH

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

vuln.today AI

7.8 HIGH

File-parsing attack via crafted .mtl asset (AV:L/UI:R); no attacker privileges or special conditions needed; full stack corruption yields C/I/A:H.

3.1 AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

4.0 AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

SUSE

HIGH

qualitative

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 05, 2026 - 13:35 vuln.today

CVE Published

Aug 05, 2026 - 12:26 cve.org

HIGH 7.8

DescriptionCVE.org

tinyobjloader-c's tinyobj_parse_and_index_mtl_file() (tinyobj_loader_c.h) reads each line of a .mtl material file into a fixed 4096-byte stack buffer linebuf via memcpy(linebuf, p, p_len), guarded only by assert(p_len < 4095). Because assert() compiles to a no-op under -DNDEBUG (standard for release builds), a crafted .mtl file containing a line (e.g. a "newmtl" material name) longer than 4096 bytes overflows linebuf into the adjacent stack variable namebuf and beyond, corrupting the stack of any application that loads attacker-supplied 3D model/material files. The identical vulnerable pattern is duplicated in a second function in the same file.

AnalysisAI

Stack-based buffer overflow in tinyobjloader-c's MTL material file parser allows an attacker who can supply a crafted 3D asset to corrupt the call stack of any application that loads it, potentially achieving arbitrary code execution. All versions of syoyo/tinyobjloader-c are affected because the only bounds guard in tinyobj_parse_and_index_mtl_file() is an assert() call that compiles to a no-op under -DNDEBUG - the standard flag for release builds - leaving memcpy(linebuf, p, p_len) completely unchecked. The identical vulnerable pattern is duplicated in a second function in the same header file, and no vendor-released patch has been identified at time of analysis. No public exploit code and no CISA KEV listing have been identified.

Technical ContextAI

tinyobjloader-c (CPE: cpe:2.3:a:syoyo:tinyobjloader-c:*:*:*:*:*:*:*:*) is a single-header C library (tinyobj_loader_c.h) by syoyo for parsing Wavefront OBJ and MTL 3D model and material files, commonly embedded in game engines, graphics tools, and real-time rendering pipelines. The root cause is CWE-121 (Stack-based Buffer Overflow): tinyobj_parse_and_index_mtl_file() allocates a fixed 4096-byte stack buffer named linebuf and copies each line of a .mtl file into it via memcpy(linebuf, p, p_len). The only size validation is assert(p_len < 4095), which the C standard guarantees is compiled out entirely when the NDEBUG preprocessor macro is defined - the universal convention for production release builds. A crafted .mtl line longer than 4096 bytes (e.g., a 'newmtl' material name) therefore overflows linebuf, corrupts the adjacent stack variable namebuf, and overwrites stack-frame metadata including the saved return address. Because the vulnerable pattern is duplicated in at least one additional function within the same header, the attack surface is wider than a single call path. Source confirmed at https://github.com/syoyo/tinyobjloader-c/blob/master/tinyobj_loader_c.h.

RemediationAI

No vendor-released patch has been identified at time of analysis; the references provided point only to the upstream repository (https://github.com/syoyo/tinyobjloader-c) and the vulnerable header (https://github.com/syoyo/tinyobjloader-c/blob/master/tinyobj_loader_c.h) without a tagged fix release. Until an official patch is available, the most direct compensating control is to replace the assert(p_len < 4095) guard in both affected functions with a runtime bounds check that returns an error or truncates input when p_len exceeds 4095 - this is a minimal one-line change but requires rebuilding all applications that embed the header. Applications that accept 3D assets from untrusted sources should additionally validate or reject .mtl files containing lines exceeding a sane maximum length before passing them to the parser. Running the parsing process in a sandboxed subprocess with reduced OS privileges (e.g., seccomp, pledge, or a dedicated low-privilege account) limits the blast radius of successful stack corruption without requiring code changes. Finally, ensuring release builds are compiled with stack canary support (GCC/Clang -fstack-protector-strong) and that ASLR is enabled at the OS level does not prevent the overflow but meaningfully raises the bar for reliable control-flow hijacking.