RCE

CVE-2025-54418: CodeIgniter4 ImageMagick Vulnerability Lets Attackers Gain Remote Access

Amit Schendel

Amit Schendel

— 6 min read

You’ve built a beautiful web application. It has a sleek user profile page where users can upload a custom avatar. What could possibly go wrong? As it turns out, if you're using CodeIgniter4 with the ImageMagick handler, that innocent-looking image upload could be a Trojan horse, giving an attacker a shell on your server. Today, we're diving deep into CVE-2025-54418, a critical command injection vulnerability that turns image processing into a potential server takeover. Grab your coffee, and let's dissect how a simple filename can become a weapon.

TL;DR / Executive Summary

  • Vulnerability: OS Command Injection in CodeIgniter4's ImageMagick image processing handler.
  • CVE ID: CVE-2025-54418
  • Affected Software: CodeIgniter4 framework versions prior to 4.6.2.
  • Impact: Remote Code Execution (RCE). An attacker can execute arbitrary commands on the server by uploading a file with a specially crafted filename or by submitting malicious text for image watermarking. This can lead to a full system compromise.
  • Severity: High/Critical.
  • Remediation: Immediately upgrade to CodeIgniter4 version 4.6.2 or newer. If you cannot upgrade, switch to the gd image handler or meticulously sanitize all user-supplied filenames and text inputs used in image operations.

Introduction: The Deceptive Simplicity of Image Uploads

In the world of web development, interacting with the server's command line is a powerful but perilous game. We often rely on external tools to handle heavy lifting, and for image manipulation, few tools are as ubiquitous or powerful as ImageMagick. It’s a command-line wizard that can resize, convert, and transform images with ease.

CodeIgniter4, a popular PHP framework, provides a convenient ImageMagickHandler to act as a bridge between your PHP code and the ImageMagick binary. The problem? This bridge wasn't properly toll-gated. It allowed malicious "cargo"—in the form of unescaped user input—to pass directly into the command line.

This vulnerability, CVE-2025-54418, is a classic tale of command injection. It’s a stark reminder that any data originating from a user, even something as seemingly benign as a filename, is a potential threat. For developers, system administrators, and security professionals, this CVE is a case study in why we can never, ever trust user input.

Technical Deep Dive: How the Magic Becomes Malicious

The root cause of CVE-2025-54418 lies in how the ImageMagickHandler.php file constructs shell commands. It was essentially performing string concatenation, taking user-provided data and stitching it directly into a command string to be executed by the system.

Think of it like a game of Mad Libs. The code has a template for a command:

convert [options] "NOUN_1" "NOUN_2"

The framework expects NOUN_1 to be the source filename and NOUN_2 to be the destination. But what if a user supplies a "noun" like this?

my_image.jpg"; rm -rf /; echo "

The final command becomes a Frankenstein's monster of legitimate operations and malicious instructions. The shell executes the convert command, then dutifully moves on to the next command, rm -rf /, separated by the semicolon. Your server is now an unwilling participant in the attacker's script.

The Two Attack Vectors

This vulnerability manifests in two primary ways:

  1. Filename Injection in _resize(): When an image is resized, the source and destination filenames are passed to the command. The vulnerable code looked something like this:

    // VULNERABLE CODE (Simplified)
// system/Images/Handlers/ImageMagickHandler.php

$action = ' -resize ' . $width . 'x' . $height . ' "' . $source . '" "' . $destination . '"';
$this->process($action); // Executes the command

    The double quotes around $source and $destination are meant to handle filenames with spaces, but they do nothing to stop shell metacharacters like ;, |, or backticks (`). An attacker could upload a file with a name like `evil.jpg;id>/var/www/pwned.txt` to execute the id command.

  2. Text Injection in _text(): The handler also provides a method to overlay text on an image (e.g., for watermarking). The text content and various options (font, color, etc.) were also insecurely added to the command string.

    // VULNERABLE CODE (Simplified)
// system/Images/Handlers/ImageMagickHandler.php

// ... other options
$cmd .= " -annotate 0 '{$text}'";
$cmd = " '{$source}' {$cmd} '{$destination}'";
$this->process($cmd); // Executes the command

    Here, an attacker could provide text like Hello'; touch /tmp/hacked; echo 'World. The single quotes are easily broken out of, allowing for arbitrary command execution.

The business impact is as severe as it gets: complete server compromise, data exfiltration, website defacement, or using your server as a pivot point for further attacks.

Proof of Concept: Seeing is Believing

Let's demonstrate this with a simplified PoC. We won't set up a full CodeIgniter instance, but we'll replicate the vulnerable logic.

Disclaimer: These examples are for educational purposes only. Do not attempt to run them on systems you do not own.

PoC 1: Malicious Filename Exploitation

Imagine an attacker uploads a file named exploit.png\id`.jpg. The backticks cause the idcommand to be executed. Let's simulate the vulnerableresize` logic.

<?php
// poc_filename.php - Simplified theoretical example

// Attacker controls this filename
$malicious_filename = 'exploit.png`id > /tmp/pwned_by_filename.txt`.jpg';

// Simulate file paths
$source_path = '/path/to/uploads/' . $malicious_filename;
$destination_path = '/path/to/processed/image.jpg';

// The vulnerable command construction from ImageMagickHandler
$command = 'convert -resize 100x100 "' . $source_path . '" "' . $destination_path . '"';

echo "Executing command: " . $command . "\n";

// In a real scenario, this would be executed via shell_exec() or proc_open()
// shell_exec($command); 

echo "Check /tmp/pwned_by_filename.txt for the output of the 'id' command.\n";

When executed, the shell first runs id > /tmp/pwned_by_filename.txt and substitutes its output into the command string. The convert command would likely fail, but the damage is already done. The file /tmp/pwned_by_filename.txt now contains the user ID of the web server process (e.g., uid=33(www-data)).

PoC 2: Malicious Text Exploitation

Now, let's simulate the text watermarking feature.

<?php
// poc_text.php - Simplified theoretical example

// Attacker controls this text input
$malicious_text = "Watermark'; whoami > /tmp/pwned_by_text.txt; echo '";

// The vulnerable command construction from the _text() method
$command = "convert 'source.jpg' -annotate 0 '{$malicious_text}' 'destination.jpg'";

echo "Executing command: " . $command . "\n";

// In a real scenario, this would be executed
// shell_exec($command);

echo "Check /tmp/pwned_by_text.txt for the output of the 'whoami' command.\n";

The attacker breaks out of the single-quoted text string, injects the whoami command, and then uses echo ' to provide a closing single quote to satisfy the shell's syntax. The file /tmp/pwned_by_text.txt will be created containing the web server's username.

Mitigation and Remediation: Locking the Gates

Fixing this vulnerability requires ensuring that any user-supplied data is treated as a single, inert argument, not as executable code.

The Official Fix: Upgrade!

The most important step is to upgrade your CodeIgniter4 installation to version 4.6.2 or later.

Patch Analysis: The Power of escapeshellarg()

The fix implemented by the CodeIgniter team is simple, elegant, and correct. They replaced the manual string quoting with PHP's built-in escapeshellarg() function.

Before:

- ... '"' . $source . '" "' . $destination . '"'
- ... " -annotate 0 '{$text}'"

After:

+ ... ' ' . escapeshellarg($source) . ' ' . escapeshellarg($destination)
+ ... ' -annotate 0 ' . escapeshellarg($text)

The escapeshellarg() function is the hero of this story. It does two crucial things:

  1. It wraps the entire string in single quotes.
  2. It escapes any single quotes already present within the string.

This effectively puts the user's input into a "sealed box." The shell sees the entire string—metacharacters and all—as one literal argument to the convert command. It can no longer be interpreted as a command separator or operator.

Workarounds for a Rainy Day

If you absolutely cannot upgrade immediately, you have a few options:

  1. Switch to the GD Handler: In your app/Config/Images.php, change the default handler from imagick to gd. The GD library is not vulnerable to this specific command injection issue.
    public string $handler = 'gd';
  2. Sanitize Filenames: Never use a user-supplied filename directly. When handling uploads, generate a random, safe filename.
    // Instead of using $file->getName()
$safeName = $file->getRandomName();
$file->move(WRITEPATH . 'uploads', $safeName);
  3. Sanitize Text Input: If using the text() method, strip out any characters that aren't on a strict allow-list.
    // Example sanitizer from the advisory
$safeText = preg_replace('/[^a-zA-Z0-9\\s.,!?-]/', '', $userInput);
$image->text($safeText, ...);

Timeline of Events

Lessons Learned

This vulnerability, while specific to CodeIgniter, teaches universal security lessons.

  1. Prevention is Paramount: The root of all command injection is misplaced trust in user input. Always sanitize, validate, and escape data that will ever touch a system shell. Use built-in, battle-tested functions like escapeshellarg() and escapeshellcmd() in PHP. Don't roll your own.
  2. Detecting the Undetectable: Detecting this attack requires monitoring for anomalous process execution. Your web server (www-data, apache) should not be spawning shells (/bin/sh) or running commands like whoami, nc, curl, or wget. Tools like auditd or modern EDR solutions can help flag this behavior.
  3. The One Key Takeaway: Security is a function of your weakest link. Your application could have a brilliant architecture, robust authentication, and encrypted data, but it can all be undone by a single line of code that improperly concatenates a string for a shell command.

So, take a moment and ask yourself: where in my codebase does user input get close to the operating system? Are my "bridges" properly guarded?

References and Further Reading

Read more