# Imagick puts ImageMagick inside the PHP process, and the README says isolate it

> Imagick is the PHP extension that exposes the ImageMagick library to PHP, distributed through PECL and built with phpize or a package manager. Its README spends as much space on security as on installation, because the extension parses untrusted images inside your web process, and it recommends running it as a low privileged background task, checking magic bytes before processing and verifying the output after.

**Imagick/imagick** — 🌈 The Imagick PHP extension 🌈

- Repository: https://github.com/Imagick/imagick
- Website: http://pecl.php.net/imagick
- Stars: 626 · Forks: 164
- Language: C
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/imagick-imagick

## What the extension actually is

Imagick is a PHP extension to create and modify images using the ImageMagick library. That is the whole product, and the project page is the PECL listing rather than a website of its own.

The mechanics matter for anyone deciding whether to use it. The extension is a native C binding, with the class implementation spread across imagick.c, imagick_class.c, imagick_file.c, imagick_helpers.c and the draw, kernel and pixel iterator classes beside them. The stub and arginfo files, Imagick.stub.php and Imagick_arginfo.h, are the interface definitions, and regen_arginfo.sh regenerates them. The library is a dependency, not a fork, so the extension is a thin, well-defined surface over a large existing codebase.

The repository also carries a compatibility layer that is unusual and useful. shim_im6_to_im7.c and shim_im6_to_im7.h exist to bridge ImageMagick 6 and ImageMagick 7, and shim_php7_to_php8.h bridges PHP 7 and PHP 8. That is what lets the extension sit on top of either generation of ImageMagick and either generation of PHP without two separate code bases.

The README also mentions a version of Imagick for HHVM, and is clear about the relationship. The two extensions are mostly compatible in their API and both call the ImageMagick library, but they are completely separate code bases. The HHVM one lives in the HHVM repository rather than here.

The audience, then, is PHP developers who need image work beyond what the language's standard library provides, and who are prepared to install and maintain a native extension.

## Installing on Linux with phpize

The README says the best way of installing Imagick is through a package manager such as apt, yum or brew, because those will also install ImageMagick for you. That is the right advice for most people: the extension is a thin binding, and the package manager is what keeps the underlying library consistent with the rest of your system.

If you do need to compile from source, the order matters. You install ImageMagick first, at least version 6.2.4, though the README strongly recommends a more recent version because of the many bug fixes in it. Then the extension itself:

```bash
git clone https://github.com/Imagick/imagick
cd imagick
phpize && ./configure
make
make install
```

The last step is not enough on its own. You also need to add extension=imagick.so to your PHP ini file so that PHP loads the extension, which is the step people routinely forget because the build succeeds either way.

The build system is the standard PHP extension toolchain. config.m4 and imagemagick.m4 are the autoconf macros that let phpize discover the ImageMagick installation, config.w32 is the Windows build configuration, and imagemagick_dependency.sh is the helper for locating dependencies.

For a containerised build, the repository ships a docker-compose file with a set of build environments, centos6, centos7, developing, repro, testing7_2, testing8_0, fedora and nixos, each mounting the source at /var/app. The testing and fedora and nixos services add SYS_ADMIN and SYS_PTRACE capabilities and disable the seccomp profile, which is what a debugger or a sanitizer needs.

## The version matching rule on Windows

The Windows instructions are different in kind from the Linux ones. Instead of compiling, you install both Imagick and the underlying ImageMagick library from the PECL release directory and the dependencies directory on windows.php.net.

Then comes the constraint that decides whether the installation will misbehave: once compiled, Imagick should be run with the same version of ImageMagick that it was compiled against. Running against a different version of ImageMagick is known to cause stability issues, and so is not recommended or supported.

That is a sharper rule than the Linux section gives you, where the recommendation is simply to use a recent ImageMagick. On Windows you are taking a prebuilt binary for the extension and a prebuilt library, and the pairing has to be the one that was tested together.

It is a good illustration of the general shape of this project. Imagick is a binding to a library that moves on its own schedule, and the extension has to be rebuilt when that library changes in an incompatible way. The ImageMagick section of the README repeats the point: the library has had many bug fixes that fixed many image corruption issues, and it strongly recommends upgrading to the latest version, greater than 6.9.1 or 7.x, if at all possible.

There is also a NixOS note, because the two environment variables are easy to miss. You probably want to define FONTCONFIG_FILE to avoid a warning message when loading fonts, and MAGICK_CONFIGURE_PATH to have all the information available from Imagick::getConfigureOptions(). The repository links a shell.nix for that purpose.

## The security section treats every upload as hostile input

The most substantial part of this README is the security section, and its reasoning is worth following.

The extension works by calling the ImageMagick library, and although the ImageMagick developers take care in avoiding bugs, it is inevitable that some bugs will be present. ImageMagick also uses a lot of third party libraries to open, read and manipulate files, and those libraries are written by other people who also make mistakes. Because ImageMagick is used to process images, it is feasibly possible for hackers to create images containing invalid data to attempt to exploit these bugs.

From that, five recommendations follow.

Do not run Imagick in a server that is directly accessible from outside your network; it is better to use it as a background task with something like SupervisorD, or to run it on a separate server not directly accessible on the internet. Run it as a very low privileged process, locking down the files and system resources accessible to the PHP script.

Then two checks on the data itself. Verify that all image files begin with the expected magic bytes for the types you support, which can be done with finfo_file(). And check the result of the processing is a valid image file before displaying it, in case something managed to pipe arbitrary files into the output:

```php
<?php
	$finfo = finfo_open(FILEINFO_MIME_TYPE);
	$mimeType = finfo_file($finfo, $filename);
	
	$allowedMimeTypes = [
		'image/gif',
		'image/jpeg',
		'image/jpg',
		'image/png'
	];
	
	if (in_array($mimeType, $allowedMimeTypes) == false) {
		throw new \SecurityException("Was going to send file '$filename' to the user, but it is not an image file.");
	}
```

And the fifth is the one people skip: never directly serve files uploaded by users through PHP. Serve them through the webserver without invoking PHP, or use readfile() to serve them within PHP.

The README closes the section honestly: these recommendations do not guarantee any security, but they should limit your exposure.

## OpenMP thread limits and the stability warnings

ImageMagick can use the Open Multi-Processing API to process an image with multiple threads. Some implementations of OpenMP are known to have stability issues when they are used in certain environments, and the README offers four ways to deal with that.

Compile ImageMagick with the flag --disable-openmp. Or disable threads from Imagick by calling Imagick::setResourceLimit() with the RESOURCETYPE_THREAD resource type and the value 1, or with the numeric form Imagick::setResourceLimit(6, 1) if your version does not contain the RESOURCETYPE_THREAD constant. Or set the thread resource limit in ImageMagick's policy.xml file with a policy element for the resource domain named thread with the value 1, in a file possibly located at /etc/ImageMagick-6/policy.xml or a similar location. Or, if you do want OpenMP when it is called through Imagick, test thoroughly that it behaves correctly on your server.

The four options are ordered from most global to most local, and the choice between them is really a question of where you want the constraint enforced. Compiling it out fixes the library for everyone on the host. The policy.xml entry fixes it for every process that reads the policy, which is the usual way distributions configure ImageMagick. The Imagick call is per request, which is fine for a single application and useless for the rest of the stack.

The policy.xml route is also the one that matters for the security advice in the previous section, because a policy file is where an administrator limits what ImageMagick is allowed to do at all, independently of any application code.

## Documentation is the acknowledged weak spot

The README has a TODO section that says documentation needs a lot of work, points at the online editor for the PHP manual, and invites contributions.

That is worth weighing, because for a library of this age the documentation is the main thing that holds the knowledge. The extension is documented in the PHP manual, and the README notes that almost all of the functions in the library have an example at phpimagick.com, where you can see the example code to call the function as well as the generated image or the output.

So the documentation is spread across three places, and they have different characters. The PHP manual is the API reference, phpimagick.com is the worked examples, and this README is the operational guidance: installation, security, threading and platform quirks. The example scripts in the repository fill the fourth gap, with captcha.php, houghline.php, polygon.php, thumbnail.php and watermark.php showing the shape of real usage.

For version history, the README points at the ABI laboratory tracker for the underlying ImageMagick library, which is the place to see exactly what changed in the library between versions, as opposed to what changed in the extension.

The changelog lives in the repository as ChangeLog, and there is a package.xml for PECL packaging, a composer.json, and a validate_package.sh script. The test suite is run through runTests.sh, and the .phpt files under tests/ follow the standard PHP extension test format, with check-loaded.phpt verifying that the extension actually loaded.

## Licence, releases and the maintenance picture

The licence for the repository is recorded as a custom one that GitHub cannot classify, with the LICENSE file at the root as the authoritative text. That is worth checking against your own policy before you vendor anything, since the classification tools your organisation relies on will not tell you what the terms are.

The release history is on PECL, and the recent tags are 3.8.1 on 2025-11-26, 3.8.0 on 2025-04-10 and 3.8.0RC2 on 2025-03-13. The release candidates are published as tags rather than hidden, which is helpful if you want to see what changed before a stable tag.

The last push was on 2026-07-20 and the repository is not archived. So there is development, but the pace of published releases is what matters to you in practice, since that is what PECL gives you when you install the extension, and the compatibility rule is that the extension and the ImageMagick library on the machine need to agree.

Windows users get prebuilt binaries from windows.php.net, Linux users are pointed at their package manager, and everyone ends up with the same dependency underneath. That is the arrangement to plan around: the extension is not the hard part, keeping ImageMagick current on the host is.

## Conclusion

Imagick suits a PHP application that needs real image processing, resizing, watermarking or format conversion, and it is still the practical choice despite being a C extension around a library with a long history of parsing bugs. It is the wrong choice if your only need is thumbnails on upload, and the wrong choice if you must run image processing inside a request handler on a public web server, which is exactly what this README tells you not to do. Verify first that the ImageMagick version on the machine is the one the extension was compiled against, because a mismatch is explicitly unsupported and known to cause stability problems, and check the magic bytes of every upload before it reaches the library.

## FAQ

### How do I install the Imagick PHP extension on Linux?

The README says the best way is through a package manager such as apt, yum or brew, since those also install ImageMagick. To compile from source, install ImageMagick first, at least version 6.2.4, then clone the repository and run phpize && ./configure, make and make install, and finally add extension=imagick.so to your PHP ini file.

### Does the Imagick extension have to match the ImageMagick version?

Yes. Once compiled, Imagick should be run with the same version of ImageMagick that it was compiled against, and the README says running against a different version is known to cause stability issues and is not recommended or supported.

### What security precautions does the Imagick README recommend for user uploads?

Do not run Imagick on a server directly accessible from outside your network, use it as a background task or on a separate server, run it as a very low privileged process, verify magic bytes with finfo_file() before processing, check the output is a valid image file before serving it, and never serve user uploaded files directly through PHP.

### How do I disable OpenMP threads when using Imagick?

Four ways are given: compile ImageMagick with --disable-openmp, call Imagick::setResourceLimit() with the thread resource type and the value 1, set a thread resource policy in ImageMagick's policy.xml file, or, if you keep OpenMP, test thoroughly that it behaves correctly on your server.

## Sources

- [Imagick/imagick on GitHub](https://github.com/Imagick/imagick)
- [Issues](https://github.com/Imagick/imagick/issues)
- [Project website](http://pecl.php.net/imagick)
- [README](https://github.com/Imagick/imagick/blob/master/README.md)
- [Releases](https://github.com/Imagick/imagick/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/imagick-imagick