GHSA-43hj-fxwj-49qw
Fix: membraneframework/membrane_mp4_plugin@56373d1GHSA-43hj-fxwj-49qw is a CWE-770 vulnerability in membrane_mp4_plugin. O3 Security confirms whether GHSA-43hj-fxwj-49qw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
membrane_mp4_plugin has an unauthenticated denial-of-service via BEAM atom table exhaustion
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-43hj-fxwj-49qw.
Real-World Exposure
membrane_mp4_pluginReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
Summary
membrane_mp4_plugin interns every 4-byte MP4 box name as a BEAM atom while parsing container headers, with no validation against an allow-list. Any code path that calls Membrane.MP4.Container.parse/1 (or the bang variant) on attacker-controlled MP4 bytes can be made to exhaust the BEAM atom table, which is uncapped at the source but bounded by the runtime ceiling (around 1,048,576 atoms) and never garbage-collected. Once the ceiling is hit, the entire BEAM node aborts.
Details
The MP4 container parser walks the input stream box-by-box. For each box, Membrane.MP4.Container.Header.parse/1 in lib/membrane_mp4/container/header.ex extracts the 4-byte name field and delegates to the private helper parse_box_name/1, which trims trailing spaces and passes the bytes through String.to_atom/1. Because String.to_atom/1 creates a new atom unconditionally, every distinct attacker-chosen 4-byte sequence becomes a permanent allocation in the global atom table. Atoms are not subject to garbage collection, so unique names accumulate for the lifetime of the node.
The fix replaces the unsafe interning with String.to_existing_atom/1 and treats unknown names as the :unknown atom downstream (with related plumbing in parse_helper.ex, serialize_helper.ex, and the ISOM/CMAF demuxer engines so the new error variant flows through cleanly).
PoC
- Generate an MP4-shaped payload of roughly 1.1 million minimal box headers, each 8 bytes long (4-byte size of 8, followed by a unique 4-byte ASCII name produced by enumerating combinations in the printable range).
- Concatenate them into a single binary (~8 MB total).
- Call
Membrane.MP4.Container.parse!/1on the binary inside any process running under the target BEAM node. - The node aborts once the atom table ceiling is reached.
Impact
An attacker who can get a single crafted MP4 file in front of any system that demuxes user-supplied media with membrane_mp4_plugin can crash the entire BEAM node hosting that pipeline, taking down every Erlang/Elixir application sharing the runtime. No authentication, network position, or user interaction is required beyond delivering the file to whatever processing path eventually calls the parser.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | membrane_mp4_plugin | all versions | 0.36.7 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for membrane_mp4_plugin. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update membrane_mp4_plugin to 0.36.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-43hj-fxwj-49qw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-43hj-fxwj-49qw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-43hj-fxwj-49qw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-43hj-fxwj-49qw in your dependencies?
O3 detects GHSA-43hj-fxwj-49qw across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.