CVE-2025-62608 is a critical (CVSS 9.1) heap buffer overflow (CWE-122) in MLX, the machine learning array framework for Apple silicon. A malformed NumPy .npy file passed to the load function triggers a small out of bounds read. The fix is MLX 0.29.4.
What's affected
Per the record and the project advisory (GHSA-w6vg-jg77-2qg6), MLX versions before 0.29.4 are affected and 0.29.4 contains the patch. The advisory describes a 13 byte out of bounds read in mlx::core::load() when parsing a crafted .npy file, leading to a crash or information disclosure.
The flaw is in the C++ parser for the NumPy file format. Two details are worth knowing. The header length read from the file and the string actually built from it can differ, and a later check indexes into that string without confirming it is long enough. The project fixed it by tightening this handling. I am leaving out the crafted file layout on purpose.
How to check if you're exposed
Check the installed version in each Python environment that uses MLX:
pip show mlx
python -c "import mlx.core as mx; print(mx.__version__)"
Search your repositories and lockfiles for pinned versions:
grep -rn "mlx" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null
Then look at where mx.load is called in your code and what feeds it. A file you produced yourself is a very different risk from one downloaded from a model hub, a shared drive or a user upload.
What to do now
- Upgrade MLX to 0.29.4 or later:
pip install -U "mlx>=0.29.4", then pin the new version in your lockfile. - Rebuild any environment, notebook image or container that vendors an older MLX.
- Do not load .npy files from sources you do not trust until the upgrade is done.
- Where possible, prefer formats that do not parse arbitrary structure from untrusted files, and validate file origin before loading.
- Run a dependency scan on your repositories so older MLX pins in forgotten projects show up.
Why it matters
The parser trusted a length it had not verified against what it had built. That is a classic CWE-122 pattern: the code reads or writes past the end of a heap allocation. Here the impact in the advisory is a read, so the result is a crash or a small leak of adjacent memory, not code execution.
NVD scores it 9.1 because the vector assumes a network route to the loading code with high confidentiality and availability impact. In practice, exposure depends on whether your application loads files it did not create. A notebook that only loads your own weights is far less exposed than a service that accepts uploads.
The record does not mark this CVE as CISA Known Exploited, and the advisory does not claim exploitation. Reachability analysis helps here, because it separates projects that merely install MLX from those that call the load function on outside data.
Try it yourself
Whether you are exposed depends on what reaches the load call. This demo shows how reachability analysis narrows a long finding list.
Click through it at your own pace, or open it full screen.
Quick check
Is a crash the worst case?
The advisory lists a crash or information disclosure from a 13 byte out of bounds read. It does not claim code execution. Still, upgrade, since memory safety bugs are rarely fully understood at first report.
Does this affect other NumPy loaders?
No. The record is about the MLX implementation of load. NumPy and other libraries have their own parsers and their own advisories.
Sources
- Safeguard Gold entry for CVE-2025-62608
- MLX advisory GHSA-w6vg-jg77-2qg6
- Free in-browser dependency scan
Last reviewed: 18 October 2026.
