CVE-2024-24684

What it actually does

Stack-based buffer overflow in readOFF header parsing allows a malicious .off file to overwrite the fixed-size comment buffer via unsafe fscanf when the first header line exceeds 1000 bytes, enabling local code execution.

Why it matters to the business

Organizations relying on libigl for 3D geometry processing face risk of arbitrary code execution when users open attacker-supplied model files, potentially leading to workstation compromise, data theft, or ransomware deployment; the issue has remained unpatched for over two years with no known public exploits.

How an attack unfolds

An attacker crafts an .off file whose first header line exceeds 1000 bytes, then convinces a target to open the file with an application using the vulnerable readOFF function; the overflow corrupts the stack and can be leveraged for code execution without network access.

How to fix it

Upgrade to a version of libigl that contains a corrected readOFF implementation; until a fix is released, disable processing of .off files or sandbox applications that use the library when handling untrusted input.

How to confirm the fix worked

Rebuild the application with the updated library and confirm that long header lines in .off test files no longer trigger overflows; scan source and binary dependencies for the original libigl 2.5.0 readOFF pattern.

Typical attack path

1. Craft a malicious .off file with an oversized first header line
2. Deliver the file via email, download link, or shared storage
3. Victim opens the file in an application linked against vulnerable libigl
4. readOFF header parsing overflows the comment buffer
5. Attacker-controlled data overwrites return addresses or function pointers
6. Shellcode or ROP chain executes with the privileges of the victim process

How to detect it

Search file-access and process-creation logs for applications linked to libigl opening .off files; look for unusually long first lines in .off headers or crash reports indicating stack corruption during header parsing.

What your security team should do

• Inventory all software and containers that statically or dynamically link libigl
• Block or quarantine .off files at email and file-share gateways pending patch availability
• Apply application sandboxing or user-mode restrictions for any remaining 3D processing workflows
• Monitor vulnerability feeds for a future libigl security release and expedite deployment once available