libjpeg-turbo version 2.0.90 has a heap-based buffer over-read (2 bytes) in decompresssmoothdata in jdcoefct.c.

A heap-based buffer overflow issue was discovered in libjpeg-turbo in h2v2mergedupsampleinternal() function of jdmrgext.c file. The vulnerability can only be exploited with 12-bit data precision for which the range of the sample data type exceeds the valid sample range, hence, an attacker could craft a 12-bit lossless JPEG image that contains out-of-range 12-bit samples. An application attempting to decompress such image using merged upsampling would lead to segmentation fault or buffer overflows, causing an application to crash.

A crafted input file could cause a null pointer dereference in jcopysamplerows() when processed by libjpeg-turbo.

It was discovered that libjpeg-turbo was not properly handling EOF characters, which could lead to excessive memory consumption through the execution of a large loop. An attacker could possibly use this issue to cause a denial of service. (CVE-2018-11813) It was discovered that libjpeg-turbo was not properly performing bounds check operations, which could lead to a heap-based buffer overread. If a user or automated system were tricked into opening a specially crafted file, an attacker could possibly use this issue to cause a denial of service. This issue only affected Ubuntu 14.04 ESM. (CVE-2018-14498) It was discovered that libjpeg-turbo was not properly limiting the amount of main memory being consumed by the system during decompression or multi-pass compression operations, which could lead to excessive memory consumption. An attacker could possibly use this issue to cause a denial of service. (CVE-2020-14152) It was discovered that libjpeg-turbo was not properly setting variable sizes when performing certain kinds of encoding operations, which could lead to a stack-based buffer overflow. If a user or automated system were tricked into opening a specially crafted file, an attacker could possibly use this issue to cause a denial of service. (CVE-2020-17541)

Last updated 24 July 2024

Last updated 24 July 2024

Libjpeg-turbo (versions 2.0.91 and 2.0.90) is vulnerable to a denial of service vulnerability caused by a divide by zero when processing a crafted GIF image.

References: https://github.com/libjpeg-turbo/libjpeg-turbo/issues/493 [https://github.com/libjpeg-turbo/libjpeg-turbo/issues/493 https://github.com/libjpeg-turbo/libjpeg-turbo/commit/1719d12e51641cce5c77e259516649ba5ef6303c

libjpeg-turbo 2.0.4, and mozjpeg 4.0.0, has a heap-based buffer over-read in getrgbrow() in rdppm.c via a malformed PPM input file.

It was discovered that libjpeg-turbo incorrectly handled certain BMP images. An attacker could possibly use this issue to expose sensitive information. This issue only affected Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2018-14498) It was discovered that libjpeg-turbo incorrectly handled certain JPEG images. An attacker could possibly use this issue to expose sensitive information. This issue only affected Ubuntu 19.04. (CVE-2018-19664) It was discovered that libjpeg-turbo incorrectly handled certain BMP images. An attacker could possibly use this issue to execute arbitrary code. This issue only affected Ubuntu 19.04. (CVE-2018-20330) It was discovered that libjpeg-turbo incorrectly handled certain JPEG images. An attacker could possibly cause a denial of service or execute arbitrary code. (CVE-2019-2201)

DISPUTED In libjpeg-turbo 2.0.2, a large amount of memory can be used during processing of an invalid progressive JPEG image containing incorrect width and height values in the image header. NOTE: the vendor's expectation, for use cases in which this memory usage would be a denial of service, is that the application should interpret libjpeg warnings as fatal errors (aborting decompression) and/or set limits on resource consumption or image sizes.

get8bitrow in rdbmp.c in libjpeg-turbo through 1.5.90 and MozJPEG through 3.3.1 allows attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted 8-bit BMP in which one or more of the color indices is out of range for the number of palette entries.

Upstream patch: https://github.com/libjpeg-turbo/libjpeg-turbo/commit/9c78a04df4e44ef6487eee99c4258397f4fdca55

Upstream issue: https://github.com/libjpeg-turbo/libjpeg-turbo/issues/258

References: https://github.com/mozilla/mozjpeg/issues/299

Last updated 25 August 2025

Last updated 25 August 2025

get8bitrow in rdbmp.c in libjpeg-turbo through 1.5.90 and MozJPEG through 3.3.1 allows attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted 8-bit BMP in which one or more of the color indices is out of range for the number of palette entries.

USN-3706-1 fixed a vulnerability in libjpeg-turbo. This update provides the corresponding update for Ubuntu 12.04 ESM. Original advisory details: It was discovered that libjpeg-turbo incorrectly handled certain malformed JPEG images. If a user or automated system were tricked into opening a specially crafted JPEG image, a remote attacker could cause libjpeg-turbo to crash, resulting in a denial of service, or possibly execute arbitrary code.

It was discovered that libjpeg-turbo incorrectly handled certain malformed JPEG images. If a user or automated system were tricked into opening a specially crafted JPEG image, a remote attacker could cause libjpeg-turbo to crash, resulting in a denial of service, or possibly execute arbitrary code.

Last updated 25 August 2025

Last updated 25 August 2025

A null pointer dereference vulnerability was reported in libjpeg library in cjpeg component. A maliciously crafted file could cause an application to crash. In specific cases this may also allow the attacker to remotely execute commands.

A flaw in libjpeg-turbo was reported [1],[2],[3] that could lead to a local denial of service when processing a specially-crafted JPEG issue.

One of the reports indicate that this only affects versions of libjpeg-turbo prior to 1.3.1 due to 1.3.1 rejecting the malformed image due to duplicate SOI markers.

Upstream has fixes for this issue [4],[5]. Also refer to the upstream bug [6].

[1] http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f [2] http://seclists.org/oss-sec/2014/q4/557 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369 [4] http://sourceforge.net/p/libjpeg-turbo/code/1365/ [5] http://sourceforge.net/p/libjpeg-turbo/code/1367/ [6] http://sourceforge.net/p/libjpeg-turbo/bugs/64/

A flaw in libjpeg-turbo was reported [1],[2],[3] that could lead to a local denial of service when processing a specially-crafted JPEG issue.

One of the reports indicate that this only affects versions of libjpeg-turbo prior to 1.3.1 due to 1.3.1 rejecting the malformed image due to duplicate SOI markers.

Upstream has fixes for this issue [4],[5]. Also refer to the upstream bug [6].

[1] http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26482&sid=81658bc2f51a8d9893279cd01e83783f [2] http://seclists.org/oss-sec/2014/q4/557 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768369 [4] http://sourceforge.net/p/libjpeg-turbo/code/1365/ [5] http://sourceforge.net/p/libjpeg-turbo/code/1367/ [6] http://sourceforge.net/p/libjpeg-turbo/bugs/64/

It was reported [1],[2] that libjpeg and libjpeg-turbo would use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in the presence of valid chroma data (Cr, Cb). An example proof of concept that can be viewed in a browser is also available [3].

This was reported and fixed initially in Google Chrome/Chromium; it does not appear to be fixed in upstream libjpeg or libjpeg-turbo yet. Patches to the third party source in Chromium for libjpeg [4] and libjpeg-turbo [5] however are available.

[1] http://googlechromereleases.blogspot.de/2013/11/stable-channel-update.html [2] http://packetstormsecurity.com/files/123989/IJG-jpeg6b-libjpeg-turbo-Uninitialized-Memory.html [3] http://lcamtuf.coredump.cx/jpegleak/ [4] http://src.chromium.org/viewvc/chrome/trunk/src/thirdparty/libjpeg/jdmarker.c?r1=228354&r2=228353&pathrev=228354 [5] http://src.chromium.org/viewvc/chrome/trunk/deps/thirdparty/libjpegturbo/jdmarker.c?r1=228381&r2=228380&pathrev=228381

A Heap-based buffer overflow was found in the way libjpeg-turbo decompressed certain corrupt JPEG images in which the component count was erroneously set to a large value. An attacker could create a specially-crafted JPEG image that, when opened, could cause an application using libpng to crash or, possibly, execute arbitrary code with the privileges of the user running the application.

Patch: http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo?view=revision&revision=830

References: http://code.google.com/p/chromium/issues/detail?id=130240 https://bugzilla.mozilla.org/showbug.cgi?id=759802