CVE-2023-45666

What it actually does

Improper handling of the delays pointer in stbi__load_gif_main allows a memory leak when stbi__convert_format fails after allocation, or a double-free when the caller unconditionally frees the pointer on a null return value, resulting in heap corruption.

Why it matters to the business

Applications that process untrusted images can crash, leak memory under sustained load, or be compromised for remote code execution, leading to service outages, data breaches, and regulatory exposure especially in image-heavy workflows.

How an attack unfolds

An attacker supplies a crafted GIF that passes initial recognition but triggers an internal allocation of the delays array followed by a failure in stbi__convert_format; depending on the caller's free logic this produces either a double-free primitive usable for heap shaping and arbitrary write or persistent memory exhaustion.

How to fix it

Update the stb_image.h single-file library to a version containing the corrected stbi__load_gif_main logic that always resets *delays on every failure path; recompile and redeploy all dependent binaries; where immediate patching is impossible, wrap calls with explicit delays=NULL after every failure and add heap-integrity checks.

How to confirm the fix worked

Rebuild with the fixed header, run the library's existing test suite plus additional GIFs that exercise the convert_format failure path, and verify that *delays is always zero or freed exactly once on every return path using address-sanitizer or valgrind.

Typical attack path

1. Deliver malicious GIF via network upload, email attachment, or web page
2. Victim application invokes stbi__load_gif_main on the file
3. Library allocates delays buffer then fails in format conversion
4. Caller either double-frees or leaks the pointer according to its error-handling pattern
5. Double-free is leveraged for heap metadata corruption and eventual code execution

How to detect it

Monitor process crash logs for repeated heap-related faults during GIF decoding, inspect memory-leak reports from long-running services that call the library, and review application source for call sites that free a delays pointer after a null return from the GIF loader.

What your security team should do

• Inventory all products statically linking or shipping stb_image.h and prioritize update within 30 days given the 9.8 CVSS and public availability of the library
• Add image-processing sandboxes or seccomp filters around any use of the library until patched
• Enable compiler and runtime mitigations (ASLR, heap canaries, -fsanitize=address) in builds that consume the library