| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| GraphicsMagick 1.3.26 has a NULL pointer dereference in the WritePCLImage() function in coders/pcl.c during writes of monochrome images. |
| GraphicsMagick 1.3.26 has a heap-based buffer overflow vulnerability in the function GetStyleTokens in coders/svg.c:314:12. |
| There are lots of memory leaks in the GMCommand function in magick/command.c in GraphicsMagick 1.3.26 that will lead to a remote denial of service attack. |
| GraphicsMagick 1.3.26 has a heap overflow in the WriteCMYKImage() function in coders/cmyk.c when processing multiple frames that have non-identical widths. |
| GraphicsMagick 1.3.26 has double free vulnerabilities in the ReadOneJNGImage() function in coders/png.c. |
| GraphicsMagick 1.3.26 is vulnerable to a heap-based buffer overflow vulnerability found in the "Display visual image directory" feature of the DescribeImage() function of the magick/describe.c file. One possible way to trigger the vulnerability is to run the identify command on a specially crafted MIFF format file with the verbose flag. |
| GraphicsMagick 1.3.26 has a NULL pointer dereference in the WriteMAPImage() function in coders/map.c when processing a non-colormapped image, a different vulnerability than CVE-2017-11638. |
| In GraphicsMagick 1.3.26, a memory leak vulnerability was found in the function ReadMATImage in coders/mat.c. |
| When GraphicsMagick 1.3.25 processes an RGB TIFF picture (with metadata indicating a single sample per pixel) in coders/tiff.c, a buffer overflow occurs, related to QuantumTransferMode. |
| Heap-based buffer overflow in the WPG format reader in GraphicsMagick 1.3.25 and earlier allows remote attackers to have unspecified impact via a colormap with a large number of entries. |
| The MagickMalloc function in magick/memory.c in GraphicsMagick 1.3.25 allows remote attackers to have unspecified impact via a crafted image, which triggers a memory allocation failure and a "file truncation error for corrupt file." |
| Buffer overflow in the MVG and SVG rendering code in GraphicsMagick 1.3.24 allows remote attackers to have unspecified impact via unknown vectors. Note: This vulnerability exists due to an incomplete patch for CVE-2016-2317. |
| ReadRLEImage in coders/rle.c in GraphicsMagick 1.3.26 mishandles RLE headers that specify too few colors, which allows remote attackers to cause a denial of service (heap-based buffer over-read and application crash) via a crafted file. |
| Off-by-one error in the DrawImage function in magick/render.c in GraphicsMagick 1.3.26 allows remote attackers to cause a denial of service (DrawDashPolygon heap-based buffer over-read and application crash) via a crafted file. |
| ReadDCMImage in coders/dcm.c in GraphicsMagick 1.3.26 allows remote attackers to cause a denial of service (NULL pointer dereference) via a crafted DICOM image, related to the ability of DCM_ReadNonNativeImages to yield an image list with zero frames. |
| In GraphicsMagick 1.4 snapshot-20171217 Q8, there is a heap-based buffer over-read in ReadNewsProfile in coders/tiff.c, in which LocaleNCompare reads heap data beyond the allocated region. |
| ReadCMYKImage in coders/cmyk.c in GraphicsMagick 1.3.26 has a magick/import.c ImportCMYKQuantumType heap-based buffer over-read via a crafted file. |
| The ReadMNGImage function in coders/png.c in GraphicsMagick 1.3.26 has an out-of-order CloseBlob call, resulting in a use-after-free via a crafted file. |
| The ReadJPEGImage function in coders/jpeg.c in GraphicsMagick 1.3.26 creates a pixel cache before a successful read of a scanline, which allows remote attackers to cause a denial of service (resource consumption) via crafted JPEG files. |
| ImageMagick before 7.0.5-2 and GraphicsMagick before 1.3.24 use uninitialized memory in the RLE decoder, allowing an attacker to leak sensitive information from process memory space, as demonstrated by remote attacks against ImageMagick code in a long-running server process that converts image data on behalf of multiple users. This is caused by a missing initialization step in the ReadRLEImage function in coders/rle.c. |
