Security Advisories (9)
CVE-2016-1238 (2016-08-02)

Imager would search the default current directory entry in @INC when searching for file format support modules.

CVE-2008-1928 (2008-04-24)

Buffer overflow in Imager 0.42 through 0.63 allows attackers to cause a denial of service (crash) via an image based fill in which the number of input channels is different from the number of output channels.

CVE-2007-2459 (2007-05-02)

Heap-based buffer overflow in the BMP reader (bmp.c) in Imager perl module (libimager-perl) 0.45 through 0.56 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via crafted 8-bit/pixel compressed BMP files.

CPANSA-Imager-2014-01 (2014-01-03)

When drawing on an image with an alpha channel where the source minimum is greater than zero, Imager would read from beyond the end of a malloc() allocated buffer. In rare circumstances this could lead to some of the source image not being written to the target image, or possibly to a segmentation fault.

CVE-2024-53901 (2024-11-17)

"invalid next size" backtrace on use of trim on certain images

CVE-2006-0053 (2006-04-10)

Imager (libimager-perl) before 0.50 allows user-assisted attackers to cause a denial of service (segmentation fault) by writing a 2- or 4-channel JPEG image (or a 2-channel TGA image) to a scalar, which triggers a NULL pointer dereference.

CVE-2026-8669 (2026-05-15)

Imager versions through 1.030 for Perl allow a heap out of bounds (OOB) write on crafted multi-frame GIF files. Imager::File::GIF's i_readgif_multi_low allocates a single per-row buffer GifRow sized for the GIF's global screen width 'SWidth' and reuses it across every image in the file. The page-match branch validates Image.Width + Image.Left > SWidth before each DGifGetLine write, but the parallel skip-image branch at imgif.c:790-805 calls DGifGetLine(GifFile, GifRow, Width) with no such check.

CVE-2026-13705 (2026-07-06)

Imager versions before 1.032 for Perl have a heap out-of-bounds read in the bundled Imager::File::SGI reader via a 16-bit RLE literal run in read_rgb_16_rle. read_rgb_16_rle guards each literal run with if (count > data_left), but count is a pixel count while every 16-bit sample consumes two bytes. The copy loop reads inp[0] * 256 + inp[1] and advances two bytes per pixel, so a run with data_left / 2 < count <= data_left passes the guard yet consumes 2 * count bytes and reads past the end of the buffer. The 8-bit path is unaffected because there one pixel is one byte. Reading a crafted SGI image through Imager->read triggers the over-read before the parser rejects the malformed image, which can crash the process.

CVE-2026-14454 (2026-07-08)

Imager versions before 1.033 for Perl treat unsigned EXIF IFD entry counts as signed. Imager mishandled large EXIF IFD entry count values, treating them as negative numbers. This could lead to an attempt to allocate a block nearly the size of the address space, which fails and kills the process. An attacker could craft an image with EXIF data that terminates a worker process.

NAME

Imager::API - Imager's C API - introduction.

SYNOPSIS

#include "imext.h"
#include "imperl.h"

DEFINE_IMAGER_CALLBACKS;

MODULE = Your::Module  PACKAGE = Your::Module

...

BOOT:
  PERL_INITIALIZE_IMAGER_CALLBACKS;

DESCRIPTION

The API allows you to access Imager functions at the C level from XS and from Inline::C.

The intent is to allow users to:

  • write C code that does Imager operations the user might do from Perl, but faster, for example, the Imager::CountColor example.

  • write C code that implements an application specific version of some core Imager object, for example, Imager::SDL.

  • write C code that hooks into Imagers existing methods, such as filter or file format handlers.

See Imager::Inline for information on using Imager's Inline::C support.

Beware

  • don't return an object you received as a parameter - this will cause the object to be freed twice.

Types

The API makes the following types visible:

  • i_img - used to represent an image

  • i_color - used to represent a color with up to 8 bits per sample.

  • i_fcolor - used to represent a color with a double per sample.

  • i_fill_t - an abstract fill

At this point there is no consolidated font object type, and hence the font functions are not visible through Imager's API.

i_img - images

This contains the dimensions of the image (xsize, ysize, channels), image metadata (ch_mask, bits, type, virtual), potentially image data (idata) and the a function table, with pointers to functions to perform various low level image operations.

The only time you should directly write to any value in this type is if you're implementing your own image type.

The typemap includes typenames Imager and Imager::ImgRaw as typedefs for i_img *.

For incoming parameters the typemap will accept either Imager or Imager::ImgRaw objects.

For return values the typemap will produce a full Imager object for an Imager return type and a raw image object for an Imager::ImgRaw return type.

i_color - 8-bit color

Represents an 8-bit per sample color. This is a union containing several different structs for access to components of a color:

  • gray - single member gray_color.

  • rgb - r, g, b members.

  • rgba - r, g, b, a members.

  • channels - array of channels.

Use Imager::Color for parameter and return value types.

i_fcolor - floating point color

Similar to i_color except that each component is a double instead of an unsigned char.

Use Imager::Color::Float for parameter and return value types.

i_fill_t - fill objects

Abstract type containing pointers called to perform low level fill operations.

Unless you're defining your own fill objects you should treat this as an opaque type.

Use Imager::FillHandle for parameter and return value types. At the Perl level this is stored in the fill member of the Perl level Imager::Fill object.

Create an XS module using the Imager API

Foo.xs

You'll need the following in your XS source:

  • include the Imager external API header, and the perl interface header:

    #include "imext.h"
    #include "imperl.h"
  • create the variables used to hold the callback table:

    DEFINE_IMAGER_CALLBACKS;
  • initialize the callback table in your BOOT code:

    BOOT:
      PERL_INITIALIZE_IMAGER_CALLBACKS;

foo.c

In any other source files where you want to access the Imager API, you'll need to:

  • include the Imager external API header:

    #include "imext.h"

Makefile.PL

If you're creating an XS module that depends on Imager's API your Makefile.PL will need to do the following:

  • use Imager::ExtUtils;

  • include Imager's include directory in INC:

    INC => Imager::ExtUtils->includes
  • use Imager's typemap:

    TYPEMAPS => [ Imager::ExtUtils->typemap ]
  • include Imager 0.48 as a PREREQ_PM:

    PREREQ_PM =>
    {
     Imager => 0.48,
    },

AUTHOR

Tony Cook <tony@imager.perl.org>

SEE ALSO

Imager, Imager::ExtUtils, Imager::APIRef, Imager::Inline