GHSA-qv2q-c278-pch5: Cryptographic Nonce Reuse and Information Disclosure in ImageMagick

ImageMagick provides built-in mechanisms for image obfuscation via the -encipher and -decipher command-line utilities. These utilities rely on the PasskeyEncipherImage method to scramble pixel data using AES in Counter (CTR) mode. Magick.NET, the .NET wrapper for ImageMagick, exposes this same cryptographic functionality to developers handling image processing in C# applications.

The vulnerability tracked as GHSA-qv2q-c278-pch5 identifies a critical cryptographic flaw in how this enciphering process initializes its state. The implementation fails to generate a unique initialization vector (IV) for distinct encryption operations. This flaw forces the cryptographic cipher into a degraded state where it reuses the same AES keystream across multiple images.

Consequently, this deterministic behavior invalidates the security guarantees of the AES-CTR implementation. The vulnerability maps directly to CWE-323 (Reusing a Nonce, KeyPair in Polyalphabetic Cipher) and CWE-330 (Use of Insufficiently Random Values). The maintainers now classify this feature strictly as casual obfuscation rather than secure encryption.

AES-CTR transforms a block cipher into a stream cipher by generating a keystream, which is then XORed with the plaintext data. The security of this mode strictly requires a completely unique nonce or IV for every encryption operation under a given key. If the IV repeats, the generated keystream repeats.

In the PasskeyEncipherImage implementation, the IV derivation mechanism is entirely deterministic and relies on insufficiently variable inputs. The algorithm splits the user-supplied passphrase into two halves. It uses the first half directly as the AES encryption key and processes the second half to generate the IV.

To construct the IV, the implementation combines the second half of the passphrase with the image dimensions, specifically the width and height. It then hashes this combined string to produce the final initialization vector. Because the derivation process relies solely on the passphrase and the dimensions of the target image, encrypting any two images of identical size with the same passphrase yields the exact same IV.

The exploitation of this vulnerability does not require complex software exploitation techniques or memory corruption. Instead, it relies on fundamental cryptanalysis techniques applied to stream ciphers that suffer from nonce reuse. An attacker only needs passive access to two or more ciphertext images encrypted under the identical configuration.

When the AES keystream is reused, the mathematical relationship between the ciphertexts and plaintexts becomes trivially solvable. Let the reused keystream be K, and two plaintexts be P1 and P2. The resulting ciphertexts are C1 = P1 ⊕ K and C2 = P2 ⊕ K. An attacker can XOR the two ciphertexts together, computing C1 ⊕ C2.

Because the XOR operation is commutative and self-inverting, the keystream K cancels out completely. The result is exactly P1 ⊕ P2. The attacker is left with the XOR sum of the two original unencrypted image files. From this state, the attacker applies standard crib-dragging techniques or statistical analysis to separate the individual image plaintexts, recovering the original pixel data.

The concrete security impact of GHSA-qv2q-c278-pch5 is restricted strictly to the loss of data confidentiality. The vulnerability possesses a CVSS v3.1 score of 3.7, reflecting its low severity and the specific preconditions required for exploitation. Attackers cannot leverage this flaw to achieve remote code execution, manipulate file system contents, or degrade application availability.

Data recovery requires the attacker to possess multiple images of identical dimensions encrypted with the same passphrase. In environments where an automated system scales and encrypts batch images (such as uniform profile pictures or standardized thumbnails), these preconditions are naturally met. The attacker must also possess the capability to intercept or access these stored ciphertext images.

While the technical severity is low, the vulnerability highlights a critical divergence between cryptographic expectations and implementation realities. Developers relying on Magick.NET's encipher functionality for secure data storage at rest will find their implementations vulnerable to trivial cryptographic analysis. The ImageMagick project explicitly advises treating this functionality only as a mechanism for casual obfuscation.

The primary remediation for this vulnerability requires upgrading the Magick.NET library to version 14.12.0 or later. This version adjusts the cryptographic behavior or explicitly defines the functional limitations of the PasskeyEncipherImage method. Administrators managing systems that rely on the affected .NET distributions must verify their package versions via NuGet and deploy the updated builds.

If immediate patching is unfeasible, developers must alter their application logic to prevent nonce reuse. The most effective workaround requires generating a unique, cryptographically secure passphrase for every single image encryption operation. Storing a unique key per image ensures that the deterministic IV derivation process never produces identical initialization vectors.

Architecturally, security teams should deprecate the use of ImageMagick's built-in enciphering tools for protecting sensitive image data. Applications requiring secure storage of images should utilize dedicated cryptographic libraries, such as the .NET framework's AesGcm class, which handles authenticated encryption and nonce generation correctly. Image processing pipelines should strictly handle formatting and transformations, leaving encryption to purpose-built cryptographic boundaries.