Adminer versions before 5.4.3 contain an unrestricted file upload vulnerability in the AdminerFileUpload plugin that allows authenticated users to upload PHP files by exploiting a permissive default extension allowlist. Attackers can upload PHP webshells to columns ending in _path and execute arbitrary code as the web-server user when uploadPath is web-served.

Adminer before 5.4.3 inserts unsanitized database server version strings into script tags with valid CSP nonces without proper validation. Attackers controlling a rogue MySQL server can return crafted version strings that break out of the JavaScript context and execute arbitrary code, bypassing Content Security Policy protections.

Adminer 4.6.0 through 5.5.0 (fixed in 5.5.1) contains an incomplete fix for a prior X-Forwarded-Prefix vulnerability (GHSA-8478-xrj3-h9c2). The validation guard (bootstrap.inc.php) only rejects prefixes matching ^/[^/], blocking //evil.com but allowing values such as /\evil.com whose second character is a backslash. Because browsers normalize backslash to forward slash, a network-path reference survives into REQUEST_URI and reaches cookie_path(), affecting the Set-Cookie Path attribute. Exploitation requires that clients can set the X-Forwarded-Prefix header (a misconfigured or absent reverse proxy). Impact is limited to anomalous cookie-path scoping.

Adminer before 5.4.3 fails to sanitize the server field before constructing a PDO DSN string, allowing unauthenticated attackers to inject ODBC parameters via semicolons. Attackers can inject TraceFile and TraceOn parameters to write PHP code to the web root, achieving remote code execution when the trace file is accessed.

Adminer before 5.4.3 contains an arbitrary file deletion vulnerability in SQLite mode where the database-list drop action fails to validate file extensions before deletion. An authenticated attacker can submit arbitrary relative file paths in the db[] parameter to delete any files writable by the PHP process.

Adminer before 5.4.3 uses a CSRF token scheme that transmits both the XOR mask and the masked value in every token (format (rand XOR secret):rand), allowing anyone who observes a single CSRF token (e.g., via network sniffing, log files, Referrer header, or XSS) to recover the session secret with a single XOR operation and forge unlimited valid tokens. The implementation is further weakened by a low-entropy session token (rand(1,1e6), ~20 bits) that permits blind brute-force, and by use of loose comparison (==) in token verification, enabling PHP type juggling. Exploitation enables cross-site request forgery against authenticated sessions, including execution of arbitrary SQL queries.

Adminer versions 5.3.0 through 5.4.2 with the sql-log plugin enabled contain an arbitrary file write vulnerability in the ns parameter of plugins/sql-log.php. An authenticated user can supply path traversal sequences in the ns parameter to write arbitrary .sql files with attacker-controlled content to any writable directory on the host.

Adminer before 5.4.3 contains a remote code execution vulnerability in SQLite query handling where VACUUM INTO is not blocked despite ATTACH restrictions. Authenticated attackers can execute VACUUM INTO to write PHP code to arbitrary file paths and execute commands on the server.

Adminer 4.6.0 before 5.5.0 prepends the client-supplied X-Forwarded-Prefix header to $_SERVER["REQUEST_URI"] with no trusted-proxy check and no validation of the prefix value. An attacker can supply an absolute URL (e.g. X-Forwarded-Prefix: https://evil.example) that flows into Location redirect headers, the Set-Cookie path attribute, and self-referential links. This enables an authenticated open redirect after state-changing POSTs, unauthenticated control of the session cookie path attribute, and poisoning of self-referential links; CR/LF cannot be injected, so header splitting/XSS is not possible.

Adminer before 5.5.0 contains a server-side request forgery vulnerability in the login form's server field validator, which only inspects leading integers for privileged ports and fails to reject non-numeric port values. Attackers can inject PDO DSN keys like host= and port= into the server parameter to bypass the privileged-port restriction and establish TCP connections to arbitrary internal hosts and ports before authentication.