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 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/
Last updated 25 August 2025
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.
Last updated 25 August 2025
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.