Description

Adminer 4.16.0 through 6.0.1 contain a pre-authentication Server-Side Request Forgery (SSRF) vulnerability in the optional Elasticsearch driver (plugins/drivers/elastic.php), fixed in 6.0.2. Because adminer/include/auth.inc.php invokes Driver::connect() before the login result is validated, an unauthenticated attacker who submits crafted auth[server], auth[username], and auth[password] parameters can cause the Adminer server to issue an HTTP GET request (via get_url()/file_get_contents()) to an arbitrary reachable host and port. The driver validates only general server syntax and does not block loopback, private, link-local, or other reserved addresses; if no port is given it appends the default 9200, and Adminer's generic port check rejects ports below 1024. Selected JSON error fields from non-2xx Elasticsearch-style responses, as well as connection failures, are rendered on the login page, providing a port-scanning oracle and enabling internal network reconnaissance and service fingerprinting. Exploitation requires that the optional Elasticsearch driver be explicitly deployed (e.g., via the adminer/elastic.php template or an adminer_object() configuration; it is not loaded in a default build) and that PHP allow_url_fopen be enabled.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-09-26T14:16:54.437Z",
  "pubdate": "2026-09-26T14:16:54.437Z",
  "executiveSummary": "Adminer versions 4.16.0 through 6.0.1 are susceptible to a pre-authentication Server-Side Request Forgery (SSRF) vulnerability within the optional Elasticsearch driver.\nThe vulnerability arises because the application invokes the Driver::connect() method before validating authentication credentials, allowing an unauthenticated remote attacker to force the server to initiate arbitrary HTTP GET requests.\nSuccessful exploitation enables internal network reconnaissance, service fingerprinting, and potentially port scanning of the host's internal network infrastructure.\nThe risk is constrained by specific environmental prerequisites: the optional Elasticsearch driver (plugins/drivers/elastic.php) must be explicitly deployed, and the PHP configuration must have allow_url_fopen enabled.\nBy manipulating the auth[server], auth[username], and auth[password] parameters, an attacker can bypass authentication to probe protected services.\nThis vulnerability is addressed in version 6.0.2, and immediate upgrades are advised for any deployments utilizing the Elasticsearch driver.",
  "technicalDetails": "The vulnerability resides in the interaction between the Adminer authentication workflow and the optional Elasticsearch driver (plugins/drivers/elastic.php). In the default login process, auth.inc.php invokes the Driver::connect() function prior to verifying the integrity or validity of user-supplied authentication parameters. This design flaw permits an attacker to supply malicious input to the Elasticsearch driver before access control mechanisms are enforced.\nThe attack vector leverages the Driver::connect() method, which utilizes internal functions like get_url() or file_get_contents() to communicate with a target Elasticsearch host. Because the driver performs minimal input validation—only verifying basic server syntax—it fails to implement necessary blocklists for private IP ranges, loopback addresses, or link-local interfaces. Furthermore, while Adminer imposes a restriction on ports below 1024, it implicitly appends a default port of 9200 if none is specified, facilitating requests to various services running on non-privileged ports.\nThe exploitation flow is as follows: An unauthenticated attacker submits a crafted HTTP request containing malicious values for auth[server], auth[username], and auth[password]. The application, processing this data through the elastic.php driver, initiates an outbound request to the target URI. If the target server returns an error or responds with specific Elasticsearch-formatted JSON, Adminer captures and reflects portions of this response on the login interface. This behavior transforms the application into an oracle, allowing an attacker to determine the existence of internal services or confirm open ports based on the differential between error messages and connection timeouts.\nThe vulnerability is technically enabled by the requirement that allow_url_fopen must be active in the server's php.ini, as this allows the PHP engine to perform the underlying HTTP request required for the SSRF. Because the connection failure information and error responses are rendered directly in the UI, the impact extends beyond simple request forgery to include reconnaissance, where an attacker can systematically map internal network topography, perform service fingerprinting, and identify reachable targets within the restricted network environment of the web server."
}