SURIQ
A database admin panel with a path to running shell code is the worst kind of web-facing tool to leave open, and Adminer just handed attackers a fresh route to exactly that. CVE-2026-15686 lets an authenticated Adminer user turn a database session into arbitrary code running on the web server. Trend Micro's Zero Day Initiative published the advisory on July 29, crediting the researcher 0daystolive of Sorcery Ltd. Adminer already shipped the fix back in version 5.4.3, so the work in front of you is confirming what you run and how reachable it is.
Adminer is the single-file database manager many teams drop onto a server as a lighter stand-in for phpMyAdmin. That convenience is the risk. It is a browser-facing console wired straight to your database, and this flaw upgrades that access from reading tables to executing code.
What the flaw lets an attacker do
CVE-2026-15686 is an authenticated remote code execution bug rated CVSS 7.2. Someone who can log in to Adminer, using any database account it accepts, can defeat a built-in security filter, write a PHP file onto the server, and run it. The payoff is code execution in the web server's context, which on most hosts means the attacker now runs commands as your web application.
The mechanism is worth understanding because it tells you what to watch for. Adminer tries to block a dangerous class of SQLite statement, the ones that can write files to disk, using a regular expression filter. The bypass abuses how that filter breaks. Feed it a query stuffed with a huge run of SQLite comment lines and PHP's regex engine blows past its backtracking limit. At that point preg_match() returns false instead of a normal match result of 0 or 1. Adminer's code checked that return value as though false meant no dangerous pattern was found, so the blocked statement passed straight through. The ZDI advisory reduces this to the detail that matters to a defender: on the multi-query path, a function's return value was checked incorrectly. From there the now-unfiltered SQLite command writes a PHP payload the attacker executes. According to the vendor advisory the filter that failed guarded against SQLite ATTACH, the statement that lets SQLite open and write an arbitrary file.
Why "you need to log in first" is not the reassurance it sounds like
The CVSS vector marks this as needing high privileges (AV:N/AC:L/PR:H), and the advisory is clear that authentication is required. Read that carefully before filing it as low urgency. Adminer authenticates against the database, not against some separate admin tier, so "authenticated" means anyone holding credentials to a database the panel can reach: an application's database user, a developer's login, a shared read-write account someone pasted into a wiki. Adminer is also frequently left reachable from the public internet, sometimes at a guessable path, precisely because it is so easy to drop in and forget. Put an internet-exposed Adminer next to one weak or reused database password and this stops being a high-privilege bug and becomes a server takeover. The same exposure pattern has turned manageable bugs into incidents on other web control panels, from Control Web Panel to Unraid's web interface.
Affected and fixed versions
| Adminer release | Date | What it means for this flaw |
|---|---|---|
| 5.4.2 and earlier | up to 2026-02-08 | Vulnerable to CVE-2026-15686 |
| 5.4.3 | 2026-07-09 | First fixed release; also hardened SQLite ATTACH and VACUUM INTO handling |
| 5.5.1 (current) | 2026-07-21 | Latest release and the recommended update target |
Adminer 5.4.2 and every release before it are vulnerable. The fix landed in 5.4.3 on July 9, and the current release at the time of writing is 5.5.1. If you can, jump straight to 5.5.1 rather than the minimum 5.4.3. That 5.4.3 release quietly closed a cluster of related weaknesses: its changelog lists new blocks on SQLite ATTACH and VACUUM INTO statements and tighter server validation, which tells you the file-writing corner of SQLite was the real soft spot. A separate research team, Voorivex, also reported three more Adminer findings this year, so treat 5.4.3 as the floor and the current release as the target.
How to tell if you were hit
Because the goal is a PHP file on disk, the clearest signal is a new or modified .php file showing up in a path Adminer or your webroot controls, especially one you never deployed. Watch for unexpected files with recent timestamps under the directory Adminer runs from. In database and application logs, look for oversized query bodies padded with SQLite comment markers, and for ATTACH or VACUUM INTO statements, which a normal Adminer session has no reason to send. If you keep access logs, unexplained POST requests to your Adminer endpoint from unfamiliar addresses are the other place to look. The read-everything and write-a-file abuse of self-hosted admin tools leaves its trace in application logs, not network signatures, the same as the recent ERPNext database flaw.
Update, then get Adminer off the open internet
Patch first: move to Adminer 5.4.3 or later, ideally the current 5.5.1. That closes CVE-2026-15686 and the sibling SQLite issues in one step. But the durable fix is architectural, and it is the part a version bump does not give you. A browser-reachable database console with a route to code execution should not be answering requests from the whole internet. Put Adminer behind a VPN or an IP allowlist, add an authentication layer in front of it, and delete the copies you dropped onto servers for a one-time migration and never removed. If you must expose it, treat every database credential it accepts as a possible entry point and rotate the weak or shared ones. This is the lesson that keeps landing on self-hosted admin surfaces, whether a read-everything bug or command execution in a hosting panel.
The bug behind the bug
The instructive part is not the SQLite trick, it is the filter that failed open. A security check that returns false on an error, then gets read as "nothing to block," is a fail-open control: when it breaks, it breaks in the attacker's favor. Regular expressions are especially prone to this, because a pathological input can push the engine past its resource limits and force exactly that error return. The defensive rule is old and keeps getting relearned: a security decision must fail closed, so an error or an exhausted limit denies the action rather than allowing it. Blocklisting dangerous statements by regex is the fragile approach; refusing to run file-writing SQLite statements at all is the sturdy one. It is the same theme we keep tracking in the bug classes that refuse to die: the weakness is decades old in spirit, and it still lands on maintained software because one return value was checked the wrong way.