Wysoka

ImageMagick has a Stack Buffer Overflow in image.c

  • Ujawniono: 25.08.2025
  • Aktualizacja: 11.10.2026 11:23

Hi, we have found a stack buffer overflow and would like to report this issue. Could you confirm if this qualifies as a security vulnerability? I am happy to provide any additional information needed.

Summary

In ImageMagick's magick mogrify command, specifying multiple consecutive %d format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through vsnprintf().

Additional information

Upon further investigation, we found that the same issue occurs not only with mogrify but also with the following subcommands: compare, composite, conjure, convert, identify, mogrify, and montage.

Furthermore, we confirmed that this vulnerability has the potential to lead to RCE. RCE is possible when ASLR is disabled and there is a suitable one_gadget in libc, provided that options and filenames can be controlled.

Details

  • Vulnerability Type: CWE-124: Buffer Underwrite
  • Affected Component: MagickCore/image.c - Format processing within InterpretImageFilename()
  • Affected Version: ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025)
  • CWE-124: Buffer Underwrite: A vulnerability where writing occurs to memory addresses before the beginning of a buffer. This is caused by a design flaw in fixed offset correction, resulting in negative pointer arithmetic during consecutive format specifier processing.

Reproduction

Tested Environment

  • Operating System: Ubuntu 22.04 LTS
  • Architecture: x86_64
  • Compiler: gcc with AddressSanitizer (gcc version: 11.4.0)

Reproduction Steps

bash
# Clone source
git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1
cd ImageMagick-7.1.1

# Build with ASan
CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install

# Trigger crash
./utilities/magick mogrify %d%d

Output

==4155==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffda834caae at pc 0x7f1ea367fb27 bp 0x7ffda834b680 sp 0x7ffda834ae10
WRITE of size 2 at 0x7ffda834caae thread T0
    #0 0x7f1ea367fb26 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668
    #1 0x7f1ea2dc9e3e in FormatLocaleStringList MagickCore/locale.c:470
    #2 0x7f1ea2dc9fd9 in FormatLocaleString MagickCore/locale.c:495
    #3 0x7f1ea2da0ad5 in InterpretImageFilename MagickCore/image.c:1696
    #4 0x7f1ea2c6126b in ReadImages MagickCore/constitute.c:1051
    #5 0x7f1ea27ef29b in MogrifyImageCommand MagickWand/mogrify.c:3858
    #6 0x7f1ea278e95d in MagickCommandGenesis MagickWand/magick-cli.c:177
    #7 0x560813499a0c in MagickMain utilities/magick.c:153
    #8 0x560813499cba in main utilities/magick.c:184
    #9 0x7f1ea1c0bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
    #10 0x7f1ea1c0be3f in __libc_start_main_impl ../csu/libc-start.c:392
    #11 0x560813499404 in _start (/root/workdir/ImageMagick/utilities/.libs/magick+0x2404)

Address 0x7ffda834caae is located in stack of thread T0 at offset 62 in frame
    #0 0x7f1ea2c60f62 in ReadImages MagickCore/constitute.c:1027

  This frame has 2 object(s):
    [32, 40) 'images' (line 1033)
    [64, 4160) 'read_filename' (line 1029) <== Memory access at offset 62 underflows this variable
HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 in __interceptor_vsnprintf
Shadow bytes around the buggy address:
  0x100035061900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061920: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3
  0x100035061930: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x100035061940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100035061950: f1 f1 00 f2 f2[f2]00 00 00 00 00 00 00 00 00 00
  0x100035061960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100035061990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000350619a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
  Shadow gap:              cc
==4155==ABORTING

Affected Code

In MagickCore/image.c, within the InterpretImageFilename() function:

c
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
  Image *image,const char *format,int value,char *filename,
  ExceptionInfo *exception)
{
...
  for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
  {
    q=(char *) p+1;
    if (*q == '%')
      {
        p=q+1;
        continue;
      }
    field_width=0;
    if (*q == '0')
      field_width=(ssize_t) strtol(q,&q,10);
    switch (*q)
    {
      case 'd':
      case 'o':
      case 'x':
      {
        q++;
        c=(*q);
        *q='\0';
        /*--------Affected--------*/
        (void) FormatLocaleString(filename+(p-format-offset),(size_t)
          (MagickPathExtent-(p-format-offset)),p,value);
        offset+=(4-field_width);
        /*--------Affected--------*/
        *q=c;
        (void) ConcatenateMagickString(filename,q,MagickPathExtent);
        canonical=MagickTrue;
        if (*(q-1) != '%')
          break;
        p++;
        break;
      }
      case '[':
      {
        ...
      }
      default:
        break;
    }
  }

Technical Analysis

This vulnerability is caused by an inconsistency in the template expansion processing within InterpretImageFilename().

The format specifiers %d, %o, and %x in templates are replaced with integer values by FormatLocaleString(), but the output buffer position is calculated by filename + (p - format - offset).

The offset variable is cumulatively incremented to correct the output length of %d etc., but the design using a static offset += (4 - field_width) causes offset to increase excessively when % specifiers are consecutive in the template, creating a dangerous state where the write destination address points before filename.

The constant 4 was likely chosen based on the character count of typical format specifiers like %03d (total of 4 characters: %, 0, 3, d). However, in reality, there are formats with only 2 characters like %d, and formats with longer width specifications (e.g., %010d), so this uniform constant-based correction is inconsistent with actual template structures.

As a result, when the correction value becomes excessive, offset exceeds the relative position p - format within the template, generating a negative index. This static and template-independent design of the correction processing is the root cause of this vulnerability.

This causes vsnprintf() to write outside the stack buffer range, which is detected by AddressSanitizer as a stack-buffer-overflow.

Proposed Fix

In MagickCore/image.c, within the InterpretImageFilename() function:

c
MagickExport size_t InterpretImageFilename(const ImageInfo *image_info,
  Image *image,const char *format,int value,char *filename,
  ExceptionInfo *exception)
{
...
  /*--------Changed--------*/
  ssize_t
    field_width,
    offset,
    written; // Added
  /*--------Changed--------*/
...
  for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%'))
  {
    q=(char *) p+1;
    if (*q == '%')
      {
        p=q+1;
        continue;
      }
    field_width=0;
    if (*q == '0')
      field_width=(ssize_t) strtol(q,&q,10);
    switch (*q)
    {
      case 'd':
      case 'o':
      case 'x':
      {
        q++;
        c=(*q);
        *q='\0';
        written = FormatLocaleString(filename+(p-format-offset),(size_t)
          (MagickPathExtent-(p-format-offset)),p,value);
        /*--------Changed--------*/
        if (written <= 0 || written > (MagickPathExtent - (p - format - offset)))
          return 0;
        offset += (ssize_t)((q - p) - written);
        /*--------Changed--------*/
        *q=c;
        (void) ConcatenateMagickString(filename,q,MagickPathExtent);
        canonical=MagickTrue;
        if (*(q-1) != '%')
          break;
        p++;
        break;
      }
      case '[':
      {
        ...
      }
      default:
        break;
    }
  }
  • By updating offset based on the difference between template description length (q - p) and the number of output bytes written, buffer position consistency is maintained.
  • Correction is performed according to the actual template structure, ensuring stable behavior regardless of format length without relying on static constants.
  • Range checking of written allows detection of vsnprintf failures and excessive writes.

Commits

Fixed in https://github.com/ImageMagick/ImageMagick/commit/66dc8f51c11b0ae1f1cdeacd381c3e9a4de69774 and https://github.com/ImageMagick/ImageMagick6/commit/643deeb60803488373cd4799b24d5786af90972e

Czego dotyczy

Kliknij technologię, aby zobaczyć wszystkie dotyczące jej podatności.

PlatformaPaczkaPodatne wersjePoprawka w wersji
.NET (NuGet) Magick.NET-Q16-AnyCPU < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-AnyCPU < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-OpenMP-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-OpenMP-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-HDRI-x86 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-OpenMP-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-OpenMP-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q16-x86 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-AnyCPU < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-OpenMP-arm64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-OpenMP-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-x64 < 14.7.0 14.7.0
.NET (NuGet) Magick.NET-Q8-x86 < 14.7.0 14.7.0

Odnośniki

Ocena CVSS 7.4/10
Wektor CVSS
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
Słabość (CWE)
CWE-124
Platforma
.NET (NuGet)
Paczka
Magick.NET-Q16-AnyCPU, Magick.NET-Q16-arm64, Magick.NET-Q16-HDRI-AnyCPU
Ujawniono
25.08.2025
Aktualizacja
11.10.2026 11:23

Źródła i licencje

OSV / GitHub Advisory Database - GHSA-qh3h-j545-h8c9 - CC BY 4.0

Historia podatności: Magick.NET-Q16-HDRI-arm64

Wszystkie opisane podatności tej paczki (.NET (NuGet)), od najnowszej. Widać, czy to jednorazowa wpadka, czy paczka, której trzeba pilnować.

Wszystkie (159) w archiwum
Wszystkich wpisów
159
Pierwsza → ostatnia
07.2025 09.2026
Bez poprawki
1
Wykorzystywana w atakach
0

Rozkład istotności

  • Wysoka 24
  • Średnia 95
  • Niska 40

Ujawnienia w latach

  1. 2025: 14
  2. 2026: 145
Istotność:
  1. Wysoka · 7.5 CVE-2026-53461 < 14.14.0 14.14.0
  2. Wysoka · 7.5 CVE-2026-53460 < 14.14.0 14.14.0
  3. Wysoka · 7.5 CVE-2026-46522 < 14.13.1 14.13.1
  4. Wysoka · 7.5 CVE-2026-33901 < 14.12.0 14.12.0
  5. Wysoka · 7.5 CVE-2026-33908 < 14.12.0 14.12.0
  6. Wysoka · 7.7 CVE-2026-30929 < 14.10.4 14.10.4
  7. Wysoka · 7.5 CVE-2026-28691 < 14.10.4 14.10.4
  8. Wysoka · 7.5 CVE-2026-24485 < 14.10.3 14.10.3
  9. Wysoka · 8.8 CVE-2025-55154 < 14.8.0 14.8.0
  10. Wysoka · 7.6 CVE-2025-55004 < 14.8.0 14.8.0
  11. ImageMagick has a Stack Buffer Overflow in image.c ten wpis
    Wysoka · 7.4 CVE-2025-53101 < 14.7.0 14.7.0

Dowiedz się, które podatności dotyczą Twojej aplikacji

Po podłączeniu integracji DockRay i włączeniu raportowania oprogramowania DockRay porównuje zgłoszone wersje komponentów ze znanymi podatnościami i powiadamia o potwierdzonych dopasowaniach. Zakres zależy od obsługiwanej technologii i dostępnych biuletynów.

Podłącz swoją aplikację
Newsletter DockRay

Bezpieczeństwo aplikacji w Twojej skrzynce

Najważniejsze podatności, konkretne zalecenia i praktyczne wskazówki dla Twoich aplikacji. Wybierz technologie i śledź to, co ma znaczenie dla Twojego projektu.

  • Codzienne zestawienie nowych podatności, także krytycznych.
  • Powiadomienia o ważnych aktualizacjach.
  • Praktyczne porady o bezpieczeństwie i monitoringu aplikacji.

Pozostaw puste, aby otrzymywać informacje o wszystkich technologiach.

Zapis jest bezpłatny. Wypiszesz się jednym kliknięciem w wiadomości.