CVE-2024-0321 is a critical severity (CVSS 9.8) stack buffer overflow weakness in GPAC. The record points to upstream fix commits and gives no release number, so check the project release notes. It is not listed as exploited in the wild by CISA.
What's affected
The gpac/gpac project, in versions prior to 2.3-DEV. The upstream fix, commit d0ced41651b2, adds a destination buffer length check to gf_text_get_utf8_line in src/filters/load_text.c, and the commit message says it fixes issue 2647.
The weakness is mapped to CWE-121, stack-based buffer overflow, and CWE-787, out-of-bounds write. The record was published on 2024-01-08. The record's KEV flag is false, so CISA does not list it in the Known Exploited Vulnerabilities catalog.
How to check if you're exposed
Find every copy of GPAC on your systems and in your build outputs. Package managers will not show copies that are compiled into other software.
MP4Box -version
gpac -version
dpkg -l | grep -i gpac
brew list --versions gpac
Compare the version to 2.3-DEV or later. If the build does not contain the upstream fix commit, treat it as affected.
You can also paste a manifest or SBOM into the free in-browser scanner at Safeguard Gold to see which known CVEs apply to your dependencies. It only covers components that appear in a manifest or SBOM, so a standalone appliance still needs the manual check.
What to do now
- Find every deployment of GPAC in your environment, including test systems and anything bought or installed by a team outside IT.
- Update GPAC to a release that contains the upstream fix, and confirm the version in the project release notes.
- Avoid processing files from untrusted sources with the affected component until it is updated.
- Run any conversion or parsing jobs in a sandbox or a container with reduced rights.
- Rebuild and redeploy anything that statically links or vendors the library, since updating the system package alone will not cover it.
- Re-run a scan after the change and record the date, so you can show the exposure is closed.
Why it matters
Memory safety bugs happen when code reads or writes outside the buffer it was given. The result ranges from a crash to code execution, depending on what sits next to the buffer and what protections the platform adds.
Parsers for media and text formats are common sources of these bugs, because they handle complicated input from many sources. The practical defence is to keep the library current and to limit what untrusted files are processed by it.
The CVSS vector reads as follows. The attack is possible over the network, attack complexity is low, privileges required are none, and user interaction is not needed. The impact on confidentiality, integrity and availability is high, high and high respectively. A score is a starting point. Your own exposure, meaning whether the product faces the internet and what it can reach, decides the real priority.
Try it yourself
You cannot patch what you cannot find, and bundled libraries are easy to miss. This demo shows a dependency inventory.
Click through it at your own pace, or open it full screen.
Quick check
Is this vulnerability known to be exploited in the wild?
The record's KEV flag is false, so CISA does not list it in the Known Exploited Vulnerabilities catalog. Check the vendor advisory for current status.
Which versions are fixed?
The record points to upstream fix commits and gives no release number, so check the project release notes.
Sources
Last reviewed: 19 October 2026.
