EUVD-2026-36235Severity by source
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector reflects typical library deployments accepting remote MP4 submissions; PR:N and complete availability loss confirmed by advisory; no confidentiality or integrity impact.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
2DescriptionCVE.org
Allocation of Resources Without Limits or Throttling vulnerability in membraneframework membrane_mp4_plugin allows unauthenticated denial-of-service via BEAM atom table exhaustion.
The MP4 box header parser converts each 4-byte box name to an atom using String.to_atom/1 without validation. 'Elixir.Membrane.MP4.Container.Header':parse_box_name/1 in lib/membrane_mp4/container/header.ex interns every box name encountered while 'Elixir.Membrane.MP4.Container.Header':parse/1 walks the input. BEAM atoms are never garbage-collected, so each unique attacker-controlled 4-byte name is a permanent allocation. A crafted MP4 of approximately 8 MB containing roughly 1.1 million boxes with distinct non-standard names exhausts the atom table (default ceiling around 1,048,576 atoms), aborting the entire BEAM node and taking down all applications running on it.
This issue affects membrane_mp4_plugin from 0.3.0 before 0.36.7.
AnalysisAI
BEAM atom table exhaustion in Elixir's membrane_mp4_plugin (versions 0.3.0-0.36.6) allows denial-of-service by submitting a crafted MP4 file to any application using the library's container parser. The parser passed attacker-controlled 4-byte MP4 box names to String.to_atom/1 without validation; because BEAM atoms are permanent allocations counted against a hard ceiling (~1,048,576 by default), an ~8 MB file with ~1.1 million distinct non-standard box names exhausts the table and aborts the entire BEAM node, collaterally terminating every application co-hosted on that node. No public exploit has been identified at time of analysis; vendor-released patch 0.36.7 resolves the issue.
Technical ContextAI
The vulnerable code path is Elixir.Membrane.MP4.Container.Header:parse_box_name/1 in lib/membrane_mp4/container/header.ex, which called String.to_atom/1 on every 4-byte box type field extracted during MP4 container parsing. In the Erlang/Elixir BEAM runtime, atoms are a native immutable symbol type; they are never garbage-collected and are tracked globally against a hard process-wide ceiling (default 1,048,576). CWE-770 (Allocation of Resources Without Limits or Throttling) precisely describes the flaw: there was no allowlist, no per-parse budget, and no rejection of unknown names before atom creation. The fix replaces String.to_atom/1 with String.to_existing_atom/1 inside a rescue block, returning :error for any name not already registered in the atom table; the parse pipeline then classifies the box as :unknown and handles it gracefully. Affected CPE: cpe:2.3:a:membraneframework:membrane_mp4_plugin:*:*:*:*:*:*:*:* covering versions 0.3.0 through 0.36.6.
RemediationAI
Upgrade membrane_mp4_plugin to version 0.36.7 or later by updating the dependency in mix.exs to {:membrane_mp4_plugin, "~> 0.36.7"} and running mix deps.update membrane_mp4_plugin. The fix commit is available at https://github.com/membraneframework/membrane_mp4_plugin/commit/56373d1ddc86968e55fbde795c14eeba24357b57 and the advisory at https://github.com/membraneframework/membrane_mp4_plugin/security/advisories/GHSA-43hj-fxwj-49qw. If immediate patching is not feasible, restrict ingestion of MP4 files to trusted, pre-validated sources so attacker-controlled files cannot reach the parser; this is an operational control with no guarantees against insider or supply-chain abuse. As a secondary compensating measure, the BEAM atom table ceiling can be raised via the +t VM flag (e.g., +t 2097152), but this only delays exhaustion against a sufficiently large crafted file and should not be treated as a fix. Neither workaround eliminates the underlying unbounded allocation; patching is the only reliable remediation.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today