CVE-2023-49600

What it actually does

An out-of-bounds write in the ply_cast_ascii function of libigl v2.5.0 allows a heap buffer overflow when parsing a specially crafted .ply file.

Why it matters to the business

Applications using libigl for 3D mesh processing risk crashes or arbitrary code execution when handling untrusted PLY files, which could lead to service disruption or unauthorized access with low observed exploitation likelihood and no known ransomware use.

How an attack unfolds

An attacker crafts a malicious .ply file designed to trigger the out-of-bounds write during ASCII casting in PlyFile processing and supplies it to a vulnerable application that uses libigl, such as through file upload or direct opening, resulting in heap corruption that may be leveraged for code execution.

How to fix it

Upgrade libigl to a patched version that resolves the ply_cast_ascii vulnerability. Implement strict input sanitization and validation for all PLY files before processing and consider running file parsers in isolated environments.

How to confirm the fix worked

Verify libigl dependency versions across the codebase, test parsing with known-malicious PLY samples in a controlled environment to confirm absence of overflow, and review application logs for memory-related errors during file handling.

Typical attack path

1. Craft a malicious .ply file that exploits the ply_cast_ascii out-of-bounds write
2. Deliver the file to the target application via upload, email, or shared storage
3. Trigger parsing of the PLY file in libigl v2.5.0
4. Achieve heap buffer overflow to corrupt memory and potentially execute arbitrary code

How to detect it

Examine application logs for crashes or segmentation faults during PLY file parsing with libigl, review process memory dumps for heap corruption artifacts, and check for unexpected code execution following file processing events.

What your security team should do

• Audit and update all instances of libigl to eliminate the vulnerable version
• Add runtime protections such as ASLR and heap integrity checks where possible
• Restrict processing of external PLY files until patches are applied
• Monitor EPSS trends and exploit maturity indicators for changes in risk