CVE-2026-32647

What it actually does

The vulnerability is a memory corruption flaw in NGINX Open Source and NGINX Plus when the ngx_http_mp4_module module is built in and the mp4 directive is enabled for content handling. A specially crafted MP4 file can cause the NGINX worker process to read or write outside the intended memory bounds. The most likely outcome is worker process termination and service disruption, but successful exploitation could potentially allow code execution in the context of the NGINX worker process, depending on build options, memory layout, sandboxing, and operating system hardening.

Why it matters to the business

Organizations using NGINX to serve or process MP4 media may face website or streaming-service outages if attackers can trigger repeated worker crashes. In a worst-case scenario, compromise of the NGINX worker process could allow an attacker to pivot into the web tier, tamper with served content, access files readable by the NGINX process, or use the server as a foothold. The issue is not currently listed in CISA KEV, has low EPSS probability, no known public exploit maturity, and a flat 30-day EPSS trend, but it remains important for internet-facing media services because the affected component is commonly deployed in high-availability web and content delivery paths.

How an attack unfolds

An attacker first identifies an NGINX endpoint that serves MP4 files through the ngx_http_mp4_module, usually by finding media URLs that support MP4 pseudo-streaming behavior such as byte-range or start-time based playback. The attacker then needs a way to cause NGINX to process a malicious MP4 file, either by uploading media to an application that stores files later served by NGINX, abusing a content publishing workflow, compromising a lower-privileged account that can place media files, or convincing the service to proxy or expose attacker-controlled MP4 content. When a client requests the crafted file, NGINX invokes the mp4 module to parse MP4 atoms and metadata. Malformed structures trigger a buffer over-read or over-write in worker memory. This can crash the worker, causing denial of service, or potentially corrupt memory in a way that enables execution of attacker-controlled code under the NGINX worker privileges.

How to fix it

Upgrade NGINX Open Source or NGINX Plus to a vendor-provided fixed release when available for the affected branch. If a fixed version is not yet available or cannot be applied immediately, disable use of the ngx_http_mp4_module by removing the mp4 directive from NGINX configuration for untrusted content locations, rebuilding NGINX without the module where practical, or routing MP4 delivery through a non-vulnerable media service. Restrict the ability to upload, publish, or place MP4 files that will be served by NGINX, and validate or transcode uploaded media before publication. Run NGINX workers with least privilege, keep OS memory protections enabled, use process isolation such as containers or mandatory access controls where appropriate, and configure monitoring or supervisors to detect worker crash loops. Do not rely on end-of-technical-support versions, as they may not be evaluated or patched.

How to confirm the fix worked

Confirm whether NGINX is built with ngx_http_mp4_module by checking the build options with `nginx -V` and reviewing loaded modules where dynamic modules are used. Review NGINX configuration for active `mp4;` directives, especially in locations serving user-supplied or externally sourced media. Validate remediation by confirming the vulnerable module path is no longer enabled for untrusted MP4 content or that the deployed NGINX package is at a vendor-fixed release. Reload NGINX and verify configuration with `nginx -t`. After remediation, request representative legitimate MP4 content to ensure expected playback still works and monitor error logs, system logs, and process supervision telemetry for absence of worker crashes during MP4 requests.

Typical attack path

1. Identify an NGINX-hosted site or service that exposes MP4 playback or streaming functionality.
2. Confirm that the ngx_http_mp4_module behavior is reachable, often by testing MP4 requests and playback parameters.
3. Obtain a path to have attacker-controlled MP4 content processed, such as upload, publishing, synchronization, or compromised file placement.
4. Create or obtain a malformed MP4 file designed to trigger the memory corruption condition.
5. Request the crafted MP4 through the affected NGINX location where the mp4 directive is active.
6. Cause the NGINX worker to crash repeatedly for denial of service or attempt reliable memory corruption for code execution.
7. If code execution is achieved, operate with the privileges and filesystem/network access available to the NGINX worker process.

How to detect it

Look for evidence that NGINX processed suspicious MP4 files shortly before worker crashes or abnormal restarts. Key log sources include NGINX access logs, NGINX error logs, systemd journal, syslog, kernel logs, container runtime logs, process supervisor logs, media upload audit logs, object storage access logs, and web application logs that record uploaded or published MP4 filenames. Correlate HTTP requests for MP4 files, especially newly uploaded, rarely accessed, unusually small or malformed files, with messages showing NGINX worker exits, segmentation faults, core dumps, or restart loops. Review whether requests used MP4 pseudo-streaming parameters such as start offsets or byte-range requests. If core dumps are available, preserve them for forensic analysis and check for crashes in or near ngx_http_mp4_module code paths. Also investigate any unexpected child processes, modified web content, new files in web-accessible directories, or outbound connections from the NGINX worker account following suspicious MP4 requests.

• mp4;
• ngx_http_mp4_module
• nginx: worker process
• exited on signal 11
• segmentation fault
• core dumped
• worker process exited on signal 11
• GET /.mp4
• GET /%2e%6d%70%34
• Range: bytes=
• ?start=
• .mp4?start=
• .mp4?end=
• .mp4?start=0
• nginx -V

What your security team should do

• Inventory all NGINX Open Source and NGINX Plus deployments that serve MP4 content and determine whether ngx_http_mp4_module and the mp4 directive are enabled.
• Prioritize internet-facing services and any applications where untrusted users, partners, or automated pipelines can upload or publish MP4 files.
• Apply vendor-fixed NGINX versions as soon as they are available for the deployed branch; avoid unsupported EoTS releases.
• If immediate patching is not possible, remove or disable the mp4 directive for locations handling untrusted media and move MP4 processing to a safer workflow such as pre-transcoding.
• Restrict media upload permissions and add media validation, transcoding, or sanitization before files are made reachable by NGINX.
• Add monitoring for NGINX worker segmentation faults, abnormal exits, restart loops, and suspicious MP4 request bursts.
• Review recent access logs for requests to newly uploaded or unusual MP4 files around the time of worker crashes.
• Ensure NGINX runs with least privilege and that filesystem permissions limit what the worker process can read or modify.