Preventing glTF Path Traversal in Image URIs

The glTF (GL Transmission Format) 2.0 specification allows 3D models to reference external texture assets through relative or absolute Uniform Resource Identifiers (URIs). While this modular approach optimizes asset reuse and streaming, it introduces critical path traversal vulnerabilities if parsers fail to sanitize URI inputs, potentially exposing local file systems or internal network resources. Securing glTF runtimes requires a defense-in-depth approach centered on URI sanitization, canonical path validation, filesystem sandboxing, and protocol restrictions.

Enforcing Strict Relative Path Restrictions

By default, external texture URIs in a glTF file should only reference files relative to the model’s parent directory. Runtimes must implement strict path validation:

  • Disallow Absolute Paths: Reject URIs that begin with root designators such as /, \, or Windows drive letters (e.g., C:\).
  • Strip or Block Directory Traversal Sequences: Reject or sanitize paths containing ../ or ..\ sequences to prevent escaping the intended asset directory.
  • Handle URI Encoding Attacks: Decode percentage-encoded characters (such as %2e%2e%2f for ../) before performing traversal checks, and avoid multiple decode passes that could lead to double-decoding vulnerabilities.

Canonical Path and Sandbox Verification

String-based path checks alone are often insufficient due to symbolic links, filesystem quirks, or alternate path representations. Applications must verify paths against the filesystem boundaries:

  1. Resolve the Real Path: Combine the base asset directory with the target URI and resolve the absolute, canonical path (e.g., using realpath() in POSIX or GetFullPathName() in Windows).
  2. Boundary Check: Confirm that the resolved canonical path explicitly starts with the canonical path of the allowed base directory. If the resolved path lies outside this boundary, loading must fail immediately.
  3. Disable Symlink Traversal: If the operating system permits, configure file loading routines to disallow traversing symbolic links or junction points that lead outside the asset directory.

Scheme and Protocol Whitelisting

External image URIs can reference remote network locations or alternative schemes. Parsers should tightly control permitted URI schemes:

  • Allowed Schemes: Restrict URIs strictly to relative paths and inline data: URIs (such as data:image/png;base64,...).
  • Block Dangerous Protocols: Prohibit sensitive or dangerous protocols, such as file://, ftp://, or internal network schemes, which can lead to local file inclusion (LFI) or Server-Side Request Forgery (SSRF) in server-side renderers.
  • Control Remote Fetching: If remote fetching (http:// or https://) is supported, route requests through a safe HTTP client that blocks internal IP ranges (such as 127.0.0.1 and private RFC 1918 blocks) and enforces Cross-Origin Resource Sharing (CORS) policies.

Alternative Architectural Defenses

To eliminate filesystem traversal risks entirely, applications can adjust how assets are packaged and handled:

  • Adopt the Binary glTF Format (.glb): Pack textures directly into the binary container. GLB files store images inside internal binary buffers accessed via byte offsets rather than external filesystem lookups.
  • Virtual Filesystems (VFS): Mount glTF models inside an isolated in-memory or chrooted virtual filesystem so the parser lacks direct access to the host machine's broader file structure.
  • Least Privilege: Run glTF parsing and rendering pipelines under dedicated service accounts with minimal read-only permissions limited strictly to the active asset repository.