CVE-2024-23948

What it actually does

Improper array index validation in igl::MshLoader::parse_nodes when handling ASCII .msh files allows an out-of-bounds write during node parsing.

Why it matters to the business

Processing untrusted mesh files in applications using this library can lead to crashes, memory corruption, or arbitrary code execution, risking data loss or system compromise in engineering and 3D modeling workflows.

How an attack unfolds

An attacker crafts a malicious ASCII .msh file that triggers the vulnerable parse_nodes path; when a user or automated process loads the file through libigl, the out-of-bounds write occurs, potentially allowing code execution.

How to fix it

Upgrade libigl to a version that includes bounds checks in MshLoader::parse_nodes; rebuild and redeploy dependent applications; validate all .msh inputs with strict schema checks until patched.

How to confirm the fix worked

Confirm libigl version is updated; test with known-malformed .msh samples in a sandbox; review parse error handling and memory sanitizer results on file loading paths.

Typical attack path

1. Create specially crafted ASCII .msh file exploiting array index flaw
2. Deliver file via email, download, or shared storage
3. Victim application opens the file using libigl readMSH
4. parse_nodes processes malformed node data causing OOB write
5. Attacker payload executes or process crashes

How to detect it

Search application logs for .msh file loads followed by crashes or segmentation faults; inspect process memory dumps for OOB write patterns around node parsing; correlate with user-reported file handling failures.

What your security team should do

• Prioritize patching libigl in all build pipelines due to high CVSS and remote file-based attack vector
• Implement file-type sandboxing and content scanning for .msh files before processing
• Add runtime memory protections and fuzzing to mesh loaders
• Monitor for new exploit maturity signals given 869 days since disclosure