CVE-2023-47994: High Integer Overflow in FreeImage BMP Plugin

CVE-2023-47994 is a high severity (CVSS 8.8) integer overflow in FreeImage 3.18.0, in the LoadPixelDataRLE4 function of the BMP plugin. A crafted file could expose data, crash the program or allow code execution. I could not confirm a fixed version, so find your copies and contain them.

What's affected

The record names FreeImage 3.18.0. The NVD description says an integer overflow in the LoadPixelDataRLE4 function in PluginBMP.cpp allows attackers to obtain sensitive information, cause a denial of service or run arbitrary code. The weakness is CWE-190 (Integer Overflow or Wraparound).

The record scores it 8.8 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. As with the neighbouring FreeImage issue CVE-2023-47992, a crafted image has to be processed by something that uses the library. This one sits in the code that decodes 4 bit run length encoded bitmap data, so it only matters when BMP input is accepted.

The only reference is the reporter's repository. I did not find a vendor advisory or a release naming a fix, so no fixed version is stated here. The record does not flag the CVE as exploited in the wild.

How to check if you're exposed

FreeImage is a C and C++ library, so it is often compiled into another program or shipped as a shared library by your operating system. Look for it in several places.

dpkg -l | grep -i freeimage
rpm -qa | grep -i freeimage
ldconfig -p | grep -i freeimage
brew list --versions freeimage

The first two cover Debian and Red Hat family package managers, the third lists shared libraries the loader knows about, and the last covers Homebrew. Statically linked copies will not show up this way, so also search your source trees and vendored folders for a FreeImage directory, and check software bills of materials where you have them.

For container images, run the same package queries inside the image, or scan the image with a tool that reads package metadata. Version 3.18.0 is the one named in the record.

What to do now

1. Inventory every product and image that bundles FreeImage, including statically linked copies and vendored source folders.
2. Check the FreeImage project and your operating system vendor for a fixed release or a patch, since I could not confirm one from the record.
3. Stop passing untrusted image files to FreeImage where you can. Convert or validate uploads in a sandboxed process instead.
4. Run image decoding in a low privilege, resource limited process so that a crash or memory error stays contained.
5. Plan a move to a maintained image library if no patched FreeImage release is available for your platform.

Why it matters

Run length encoded bitmap decoding looks simple, but it reads counts from the file and uses them to compute how many pixels to write. If that arithmetic overflows, the decoder believes it has room that it does not have. That is the pattern behind this CWE-190 (Integer Overflow or Wraparound) entry.

For defenders, the useful question is not "is FreeImage on a disk somewhere" but "does any service hand it files from outside our trust boundary". Image upload endpoints, thumbnail generators and document converters are the usual answers. If you can limit accepted formats to those you need, you remove whole decoders from the attack surface. Check the Safeguard Gold page for this CVE and try the free in-browser scan at gold.safeguard.sh/scan against your manifests.

Quick check

Sources

• Researcher repository referenced by the NVD record (FreeImage-cve-poc)
• NVD record for CVE-2023-47994

Last reviewed: 19 October 2026.