Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
💧 Hex
Not in CISA KEV

CVE-2026-53423 — membrane_mp4_plugin

Fix: membraneframework/membrane_mp4_plugin@56373d1

CVE-2026-53423 is a CWE-770 vulnerability in membrane_mp4_plugin. A fix is available for membrane_mp4_plugin — see the affected versions and patch details below.

Unauthenticated denial-of-service via BEAM atom table exhaustion in membrane_mp4_plugin

Also known asEEF-CVE-2026-53423GHSA-43hj-fxwj-49qw
Published
Jun 11, 2026
Updated
Aug 12, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 1, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

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 CVE-2026-53423.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk+0.05%
Lower risk than most CVEs7th percentile — riskier than 7% of all scored CVEsHighest risk
0.00%0.23%0.45%0.68%0.1%0.1%0.1%0.2%Jul 26Sep 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected
💧membrane_mp4_plugin

Real-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

  1. 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).
  2. Concatenate them into a single binary (~8 MB total).
  3. Call Membrane.MP4.Container.parse!/1 on the binary inside any process running under the target BEAM node.
  4. 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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
💧Hexmembrane_mp4_pluginall versions0.36.7mix deps.update membrane_mp4_plugin

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for membrane_mp4_plugin, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. 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 CVE-2026-53423 is resolved across your whole dependency graph.

  3. Workarounds

    Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.

Frequently Asked Questions

### 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.Contain
O3 Security · Impact-Aware SCA

Is CVE-2026-53423 in your dependencies?

Find it across Hex, including transitive dependencies.

CVE-2026-53423: Fixed in 0.36.7 | O3 Security