One MP4 File to Crash or Own Your NGINX Server: CVE-2026-32647

A single, carefully crafted MP4 file — something that looks as innocent as a video asset in a media delivery pipeline — is all it takes to crash your NGINX worker process or, in the worst case, execute arbitrary code inside it. CVE-2026-32647 carries a CVSS score of 7.8 (HIGH) and targets the ngx_http_mp4_module, a built-in media streaming helper present in a significant portion of production NGINX deployments worldwide. If your NGINX serves video content, acts as a media proxy, or sits in front of a CDN origin, you need to understand this vulnerability before an attacker does.

What Is CVE-2026-32647?

CVE-2026-32647 is a memory-corruption vulnerability residing in ngx_http_mp4_module, the NGINX module responsible for pseudo-streaming support of MP4 video files — the feature that lets browsers seek to arbitrary timestamps in a video without downloading the entire file first. The module parses MP4 container metadata (atoms/boxes) at request time, and a malformed file can push that parser into reading or writing memory outside the bounds of an allocated buffer.

Two distinct primitive outcomes are possible: a buffer over-read (information disclosure or crash) and a buffer over-write (memory corruption, possible code execution). The CVSS 7.8 score reflects a local or network-reachable exploit path with high impact on confidentiality, integrity, and availability — without requiring authentication. Both NGINX Open Source and NGINX Plus are affected when compiled with ngx_http_mp4_module and the mp4 directive is active in the configuration.

How the Attack Works ⚠️

The attack vector is deceptively simple. NGINX’s MP4 pseudo-streaming feature is invoked when a client requests a URL like https://cdn.example.com/video.mp4?start=30. The ngx_http_mp4_module parses the file’s atom structure to locate the right keyframe offset. If the MP4 container has been crafted to contain malformed or oversized atom headers, the parser can compute an incorrect memory offset and either read beyond the allocated buffer or — critically — write attacker-influenced data into adjacent memory regions.

What makes this particularly dangerous in real-world deployments is that the attacker doesn’t necessarily need a login or a session. If your NGINX configuration serves MP4 files directly from disk or proxies them from an upstream storage bucket, anyone who can issue an HTTP GET request with a malformed file or manipulate an uploaded MP4 already in the serving path can trigger this. In environments where users can upload media (think: video platforms, e-learning portals, social apps), the attack surface widens dramatically — a malicious upload followed by a crafted request is a fully unauthenticated RCE chain.

In our enterprise deployments, we’ve seen ngx_http_mp4_module compiled in by default on Ubuntu/Debian packages (nginx-full) and enabled silently in configurations inherited from boilerplate templates. Many teams don’t even realize the module is active — making silent patching hygiene critical here.

Who’s Affected?

Two conditions must both be true for a system to be vulnerable:

NGINX is compiled with ngx_http_mp4_module — check with nginx -V 2>&1 | grep mp4. If you see --with-http_mp4_module, you’re in scope.
The mp4 directive is present in an active location block — the module being compiled in does nothing on its own; it must be explicitly enabled via configuration.

This affects both NGINX Open Source (all supported branches prior to the fix) and NGINX Plus (all releases prior to the patched version). End-of-Technical-Support versions are not evaluated — but if you’re running them, you carry this risk with no fix available. The affected surface spans media companies, CDN edge nodes, e-learning platforms, video conferencing infrastructure, and any enterprise reverse proxy serving static MP4 assets.

MITRE ATT&CK Mapping

This vulnerability maps cleanly to the following ATT&CK techniques:

T1190 — Exploit Public-Facing Application: The primary initial access vector; NGINX is public-facing and the exploit is triggered via HTTP.
T1499.004 — Endpoint Denial of Service: Application or System Exploitation: Worker termination via buffer over-read is a direct DoS primitive.
T1203 — Exploitation for Client Execution (adjacent): Relevant when the over-write primitive is weaponized for code execution within the worker process.

How to Defend Your Environment 🛡️

Remediation is straightforward in principle but requires deliberate attention in practice. Here’s what to do, in priority order:

Patch immediately: Apply the vendor-released fix for NGINX Open Source and NGINX Plus as soon as packages are available in your distro’s repository. Track the official NGINX changelog and F5/NGINX security advisories.
Audit your configurations: Run grep -r "mp4;" /etc/nginx/ across all config files. If the mp4 directive doesn’t appear, you’re not exploitable even with the module compiled in.
Disable the module if unused: If you don’t serve MP4 pseudo-streaming, remove the mp4 directive entirely. For custom builds, recompile without --with-http_mp4_module.
Harden upload pipelines: If users can upload MP4 files that NGINX later serves, add server-side MP4 validation (e.g., via ffprobe or a media transcoding step) before files enter the serving path. Never serve raw uploads directly through a vulnerable module.
Deploy WAF rules: Block or rate-limit requests containing .mp4 extensions combined with suspicious query parameters (?start=) from untrusted sources until patching is complete.
Monitor for worker crashes: Sudden worker process exited on signal 11 entries in NGINX error logs are a strong indicator of exploitation attempts triggering the over-read path.

Detecting Exploitation with Wazuh 🔧

The most reliable early signal for CVE-2026-32647 exploitation attempts is NGINX worker process crashes in your error log. A buffer over-read that doesn’t result in code execution will almost always terminate the worker with a segmentation fault. Wazuh can be tuned to alert on exactly this pattern and correlate it with the requesting IP. Drop the following custom rule into your Wazuh rules directory (e.g., /var/ossec/etc/rules/local_rules.xml):

<!-- Wazuh custom rule: CVE-2026-32647 NGINX MP4 worker crash detection -->

<group name="nginx,web,cve-2026-32647">

  <!-- Rule 1: Detect NGINX worker process crash (segfault / signal 11) -->
  <rule id="100650" level="12">
    <if_sid>31100</if_sid>  <!-- Parent: generic NGINX error -->
    <match>worker process \d+ exited on signal 11</match>
    <description>NGINX worker process crashed with SIGSEGV — possible memory corruption (CVE-2026-32647 candidate).</description>
    <mitre>
      <id>T1190</id>
      <id>T1499.004</id>
    </mitre>
    <group>crash,nginx,memory_corruption</group>
  </rule>

  <!-- Rule 2: Correlate crash with MP4 pseudo-streaming request pattern -->
  <rule id="100651" level="14" frequency="3" timeframe="60">
    <if_matched_sid>100650</if_matched_sid>
    <match>\.mp4</match>
    <description>Repeated NGINX worker crashes correlating with MP4 requests — high-confidence CVE-2026-32647 exploitation attempt.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>exploit_attempt,nginx,cve-2026-32647</group>
  </rule>

  <!-- Rule 3: Alert on access log entries with mp4 + start parameter from external IPs -->
  <rule id="100652" level="8">
    <if_sid>31101</if_sid>  <!-- Parent: NGINX access log entry -->
    <url>\.mp4\?start=</url>
    <description>NGINX MP4 pseudo-streaming request detected (mp4?start=) — monitor for CVE-2026-32647 probing.</description>
    <group>recon,nginx,mp4_streaming</group>
  </rule>

</group>

Complement these rules with a File Integrity Monitoring (FIM) check on your NGINX binary and configuration files. If an attacker achieves code execution via the over-write primitive, they may attempt to persist by modifying the NGINX config or dropping a shared library in the module path. In Wazuh’s ossec.conf, add:

<!-- Wazuh FIM: Monitor NGINX binary, config, and module directories -->
<syscheck>
  <directories check_all="yes" report_changes="yes" realtime="yes">/etc/nginx</directories>
  <directories check_all="yes" report_changes="yes" realtime="yes">/usr/sbin/nginx</directories>
  <directories check_all="yes" report_changes="yes">/usr/lib/nginx/modules</directories>
  <!-- Alert on new or modified MP4 files in web roots if user uploads are possible -->
  <directories check_all="yes" report_changes="yes" realtime="yes"
    restrict="\.mp4$">/var/www</directories>
</syscheck>

If you’re also running a SIEM pipeline that ingests NGINX access logs, a simpler but highly effective bash one-liner can help you do a rapid triage of your existing logs for exploitation fingerprints before Wazuh rules are deployed:

# Scan NGINX access logs for MP4 pseudo-streaming requests with abnormal start values
# Legitimate players send small integers; crafted files may send huge offsets or NaN
grep -E '\.mp4\?start=' /var/log/nginx/access.log \
  | awk '{print $1, $7}' \
  | grep -v 'start=[0-9]\{1,6\}"' \
  | sort | uniq -c | sort -rn | head -20

# Check NGINX error log for worker SIGSEGV events in last 24h
grep "exited on signal 11" /var/log/nginx/error.log \
  | awk -v d="$(date -d '24 hours ago' '+%Y/%m/%d')" '$0 >= d' \
  | wc -l

If you’re thinking about how agentic or AI-assisted systems interact with this — consider that as covered in our post on AI finding exploits faster than you can patch them, the gap between public CVE disclosure and weaponized exploit availability is shrinking. A CVSS 7.8 memory-corruption bug in a ubiquitous web server is exactly the class of vulnerability that automated exploit frameworks prioritize. Similarly, if you’re managing NGINX as part of a larger supply chain, the layered risk profile here mirrors what we discussed in the Rails CVE-2026-33174 DoS analysis — single directive, outsized blast radius.

What to Do Right Now — Action Checklist

✅ Run nginx -V 2>&1 | grep mp4 on every NGINX host. Document which systems have the module compiled in.
✅ Grep all configs for the mp4; directive. If it’s not there, you’re not immediately exploitable — but patch anyway.
✅ Apply the vendor patch as soon as your distro or F5 releases updated packages. Pin your NGINX version in CI/CD pipelines to catch regressions.
✅ If patching is delayed, disable the mp4 directive as a temporary mitigation and restart NGINX. Pseudo-streaming will break, but RCE/DoS risk is eliminated.
✅ Deploy the Wazuh detection rules above and validate them in a staging environment by intentionally triggering a worker crash.
✅ Review upload pipelines: Any path where a user-controlled MP4 can reach an NGINX mp4 location block must be treated as a critical attack surface until patching is confirmed.

📊 Original source: https://nvd.nist.gov/vuln/detail/CVE-2026-32647

Securtr