Adminer CVE-2026-25892: The Self-Destructing Version Check

Adminer is the darling of PHP developers everywhere. It's a lightweight, single-file alternative to the bloated beast that is phpMyAdmin. You drop adminer.php onto your server, and boom—you have full database management. Its simplicity is its selling point. But as we see time and time again in security, 'simple' implementation often skips the 'complex' validation steps necessary to keep the bad guys out.

This specific vulnerability targets a feature that was supposed to be helpful: the automatic version check. The idea was innocent enough—notify the admin if their version of Adminer is outdated. However, the implementation committed a cardinal sin of web development: it trusted unauthenticated user input, serialized it, and wrote it to the local filesystem. This created a pathway for any random person on the internet to plant a landmine in the server's temporary directory.

What makes this bug particularly amusing (in a dark way) is that it doesn't leak data or execute code. It just throws a tantrum. It exploits the strictness of modern PHP against the laziness of legacy code, turning a helper feature into a global kill switch for the application.

Let's look at where things went wrong. In adminer/include/bootstrap.inc.php, there is a block of code listening for the ?script=version query parameter. This endpoint is accessible to anyone—no login required. Its job is to receive a version string and a signature, then cache them locally so the server doesn't have to constantly query the upstream update server.

Here is the offending code snippet:

if ($_GET["script"] == "version") {
    $filename = get_temp_dir() . "/adminer.version";
    $fp = file_open_lock($filename);
    if ($fp) {
        // VULNERABLE: blindly serializing $_POST input
        file_write_unlock($fp, serialize(array(
            "signature" => $_POST["signature"], 
            "version" => $_POST["version"]
        )));
    }
    exit;
}

Notice the complete lack of type hints or validation? The code assumes $_POST['version'] is a string. But this is PHP. If I send version[]=1, PHP kindly converts that into an array. The serialize() function doesn't care; it happily serializes the array and writes it to adminer.version. The trap is set.

The trap is sprung in adminer/include/design.inc.php, which runs every time a user loads a page to render the UI. It reads the cached file, unserializes it, and tries to verify the signature using openssl_verify.

$filename = get_temp_dir() . "/adminer.version";
if (file_exists($filename)) {
    $version = unserialize(file_get_contents($filename));
    // ... key setup ...
    
    // CRASH LANDING
    if (openssl_verify($version["version"], base64_decode($version["signature"]), $public)) {
        // ...
    }
}

In older versions of PHP (7.x), passing an array to a function expecting a string might just emit a warning and return false. The app would limp along. But PHP 8 stopped messing around. It introduced strict typing for internal functions. When openssl_verify receives an array as the first argument instead of a string, it throws a fatal TypeError.

Because design.inc.php is part of the core bootstrap process, this uncaught exception bubbles up and kills the entire script. The result? A confusing HTTP 500 error for every single user trying to access the database manager. The 'Persistent' part of this DoS is key—it doesn't go away until the temp file is physically deleted by an admin with shell access.

Exploiting this is trivially easy. You don't need a browser; you just need curl. The goal is to send a POST request that forces PHP to interpret the version parameter as an array. We do this by appending brackets [] to the parameter name.

Here is the kill command:

curl -X POST "http://target-server/adminer.php?script=version" \
     -d "version[]=ha_ha_business" \
     -d "signature=irrelevant"

That's it. One request. The server processes it, serializes the array into /tmp/adminer.version (or wherever sys_get_temp_dir() points), and the application is now dead.

This is a classic 'Griefing' vulnerability. It's not going to get you a shell (unless there's some wildly obscure gadget chain in the unserialize logic, which is unlikely here given the limited scope), but it effectively locks the admins out of their own database tools. In a crisis scenario where an admin needs to fix a DB issue right now, this DoS could be catastrophic.

The vendor, Jakub Vrána, fixed this in version 5.4.2 by realizing that server-side caching of version data was a bad idea to begin with. The patch didn't just add input validation; it ripped out the entire mechanism.

In the new version, the server-side ?script=version endpoint is gone. The openssl_verify logic in the PHP backend is gone. Instead, the application now uses a JavaScript fetch call in the browser to check for updates. This moves the trust boundary to the client, where it belongs for this kind of feature.

> [!NOTE] > Manual Remediation: If you can't upgrade immediately, you must delete the adminer.version file from your system's temp directory and block access to ?script=version via your web server config (Nginx/Apache).