Spatial Media - Version 2.1 / Arbitrary File Write chained with Path Traversal leads to Remote Code Execution (RCE)

Introduction

spatial-media is an open-source specifications and tools repository developed by Google to facilitate the handling of spatial audio and video metadata. Its primary use is to inject specialized metadata—specifically Spherical Video V1/V2 and Spatial Audio specs—into video files such as MP4 and Mov containers. This enables web browsers, mobile players, and platforms like YouTube or VR headsets to recognize and correctly render 360-degree virtual reality, spherical, and 3D videos.

The importance of spatial-media lies in its role as a standardizing component in the immersive media pipeline. Without the proper injection of these metadata descriptors, 360-degree spherical streams would display as flattened, highly distorted rectangular frames. Because these utilities are frequently deployed within automated transcoding pipelines, cloud storage workflows, and video ingestion APIs to process user-submitted VR content, vulnerabilities in its processing code pose significant security risks to media ingestion platforms.

Vulnerability Description

Spatial Media v2.1 exposes a vulnerability chain composed of Arbitrary File Write and Path Traversal that can be reproduced in the Spatial Media Metadata Injector - Web Version deployment, including the official Docker-based setup, while remaining applicable to other operating systems supported by the project; the provided evidence shows a victim host at 192.168.1.90 building and running the application from the repository documentation, an attacker host at 192.168.1.88 preparing and executing exploit.py, and a successful post-trigger condition after a Gunicorn reload (kill -HUP 1) from within the container, confirming that attacker-controlled content written into the application path /app is subsequently processed during service restart, with observable execution in the running Unix environment as root.

Impact

The vulnerability chain results in direct compromise of the application runtime and completely breaks the trust boundary of the processing service. In practical terms, an attacker can cause unauthorized code to be executed inside the containerized application context, reaching the live /app directory and obtaining command execution as the service user shown in the evidence, which in this deployment is root. This means the integrity of the web service, its codebase, its execution flow, and any data handled during processing can no longer be considered trustworthy once the condition is triggered.

From an operational standpoint, the impact is equivalent to full takeover of the affected service instance, with the ability to alter application files, persist malicious modifications across process reloads, interfere with metadata processing results, access or manipulate files stored in mounted paths such as uploads, and use the compromised runtime as a foothold for further actions within the host or adjacent environments depending on container configuration. Because the observed execution occurs with elevated privileges inside the container, the severity is materially increased, especially in deployments where sensitive mounts, weak container isolation, shared storage, or administrative runtime practices are present.

Exploitation Scenario

A realistic attack scenario is one in which an internet-exposed deployment of Spatial Media Metadata Injector - Web Version processes attacker-supplied input through its normal web interface or reachable application endpoints, allowing the malicious chain to be delivered remotely without requiring local access to the host. In this situation, the adversary only needs network reachability to the service and the ability to interact with the exposed functionality used by legitimate users, after which the application’s own file-handling behavior and runtime reload behavior become the mechanism through which the malicious payload is introduced and later executed during routine service operations.

A similarly realistic scenario exists in internal environments where the application is deployed on a workstation, lab device, or server reachable from the same subnet, such as 192.168.1.0/24, and used by developers, testers, or media-processing operators. In that setting, an attacker with access to the shared network can interact with the service over HTTP exactly as an ordinary client would, place the crafted payload through the vulnerable processing path, and then wait for a common maintenance or workflow event such as a Gunicorn reload or container restart to cause the application to process the modified runtime state. This makes the attack path viable in both flat internal networks and remotely reachable deployments, even when the target is running inside Docker rather than directly on the host operating system.

Step-by-Step Reproduction

Victim User - IP Address: 192.168.1.90

Step No. 1. The user verifies their working environment:

Step No. 2. The user then clones the repository and, following the official documentation, deploys Spatial Media Metadata Injector - Web Version:

• Spatial Media Docker Instructions

docker build -t spatial-media-web -f docker/Dockerfile .
docker run -p 5000:5000 --name spatial-media-metadata-injector -v $(pwd)/data:/app/uploads spatial-media-web

Attacker User - IP Address: 192.168.1.88

Step No. 3. The attacker user verifies their working environment, runs exploit.py to chain the Arbitrary File Write and Path Traversal vulnerabilities, and then starts netcat, waiting for a reverse connection from the victim's IP address 192.168.1.90 to the attacker's IP address 192.168.1.88 on port 9001:

Step No. 4. Meanwhile, as part of their routine workflow, the victim restarts Gunicorn from Docker (kill -HUP 1), and through this single action alone, the attacker gains control of the Unix environment:

Executive Summary: RCE via Arbitrary File Write and Path Traversal in Spatial Media

The research identifies a critical Remote Code Execution (RCE) vulnerability in Spatial Media v2.1, specifically affecting the Spatial Media Metadata Injector web deployment.

• Root Cause: The application suffers from a combination of Arbitrary File Write and Path Traversal vulnerabilities in its metadata processing logic. The application fails to sanitize file paths supplied in metadata, allowing an attacker to write files to arbitrary locations on the filesystem.
• Exploitation Mechanism: By crafting malicious metadata, an attacker can overwrite critical application files within the /app directory. When the Gunicorn server is reloaded (kill -HUP 1), the application processes the injected malicious code, resulting in execution in the context of the root user.

Analysis of Scope and Security Implications

This vulnerability is of critical severity, as it enables full compromise of the containerized environment, bypassing standard trust boundaries.

1. Infection Scenarios

• Remote Exploit: Internet-exposed instances of the metadata injector can be targeted remotely by supplying malicious media files or metadata structures, allowing attackers to execute code without needing local system access.
• Workflow Persistence: By hooking into the service reload process (Gunicorn restart), the attacker ensures their malicious code becomes a permanent part of the execution flow, effectively backdooring the application until the container is destroyed.

2. Factors Exacerbating Risk

• Elevated Privileges: Because the containerized service often runs as root, the compromise provides the attacker with full control over the runtime environment, including the ability to access mounted data volumes, exfiltrate sensitive files, or pivot to the host OS if container isolation is weak.
• Trust Boundary Break: The attack turns the application's own file-processing logic against itself, making it nearly impossible for users to differentiate between legitimate media metadata and malicious injection attempts.

Conclusion and Recommendation

This is a critical-severity vulnerability. The chaining of file write and path traversal primitives allows for direct RCE within the application’s runtime context.

Suggested actions for the development team:

1. Strict Path Sanitization: Implement rigorous validation for all file paths processed during metadata injection to prevent path traversal (e.g., using os.path.basename and restricting target directories).
2. Restrict Write Access: Apply the Principle of Least Privilege to the service user account; the application should not run as root, and the web directory should be read-only where possible.
3. Execution Environment Security: Implement strict container isolation and integrity checks for application code to ensure that process reloads do not execute unauthorized or modified files.