CVE-2023-49600 is a high severity (CVSS 8.1) heap buffer overflow in the PlyFile ply_cast_ascii code of libigl 2.5.0, triggered by a crafted .ply file. Talos reports no vendor reply and names no fixed version. Until the project says otherwise, avoid parsing untrusted PLY files with libigl.
What's affected
The NVD record names one version: libigl 2.5.0. The weakness is an out-of-bounds write in the PlyFile ply_cast_ascii functionality, classed as CWE-122 (heap-based buffer overflow) and CWE-787 (out-of-bounds write).
Talos advisory TALOS-2023-1879 gives the root cause as an unchecked read from an input stream that leaves a destination buffer too small. The CVSS vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Attack complexity is high, which fits a flaw that depends on a specially shaped input file reaching the parser.
Fixed versions: none are named. The Talos report lists a vendor contact timeline from November 2023 and says a status request on 2024-05-15 through a GitHub issue got no reply before public release on 2024-05-28. Check the libigl repository and its releases for any later change before you rely on a newer version.
How to check if you're exposed
libigl is a C++ geometry library, often vendored or pulled in through CMake, so it may not appear in a package manager lockfile. Search your repositories for it directly.
grep -ri "libigl" --include=CMakeLists.txt --include=*.cmake .
grep -rn "igl/" --include=*.cpp --include=*.h . | head
Then ask the question that matters for this bug: does any code path hand a PLY file from an outside source to libigl? A tool that only loads PLY files you generated yourself carries much less risk than a service that accepts uploads. Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan checks the open source packages in a manifest against known CVEs. It only sees what you give it, so it will not find a firmware image or a hosted product on its own. Use it for the code you ship and your asset list for everything else.
What to do now
- List every project that includes libigl, including vendored copies and submodules, and note the version.
- Find where PLY files enter those programs. Treat files from users, partners or downloads as untrusted.
- Stop accepting untrusted PLY input into libigl until a fixed release is confirmed, or convert files with a different, maintained parser first.
- If you must parse such files, run the parser in a sandboxed or low privilege process so a crash or memory corruption stays contained.
- Watch the libigl repository for a fix and update when one is published. Do not assume a version number is safe without reading the release notes.
Why it matters
A heap overflow lets a parser write past the end of a buffer it allocated. Depending on the memory layout, the result ranges from a crash to code execution in the process that parsed the file. The record scores confidentiality, integrity and availability impact all as high.
File format parsers are a steady source of this class of bug because they trust sizes and counts read from the file. The practical lesson is to treat any parser as a boundary: validate sizes, limit what the process can do, and keep it away from untrusted data when no fix exists. This CVE is not on the CISA KEV list, and the sources I read do not report exploitation.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is there a patched libigl release?
The Talos advisory names none and reports no vendor reply at publication. Check the project's releases before assuming a fix exists.
Does the attack need a login?
No. The vector shows no privileges and no user interaction. It does need a crafted PLY file to reach the parser, which is why attack complexity is rated high.
Sources
Last reviewed: 19 October 2026.
