Summary
Adminer 6.0.0 through 6.0.1 contains a pre-authentication server-side request forgery issue in the official ClickHouse driver. An unauthenticated attacker may cause the Adminer server to send requests to arbitrary URLs and disclose response bodies from reachable internal services.
Affected context
The vulnerability occurs when Adminer loads the official ClickHouse driver plugin rewritten in the affected releases and accepts a user-controlled server value during login processing. Risk increases when the Adminer host can reach internal services or sensitive network endpoints and the target returns an error response whose body is reflected in the login page.
Exploit preconditions
- Attack surface: The unauthenticated Adminer login endpoint with the ClickHouse driver enabled
- Required access: Network access to the Adminer instance; authentication is not required
- Trigger point: Submission of ClickHouse connection parameters containing an attacker-controlled server URL
- Why exploitation is possible: The server uses the supplied URL for an outbound HTTP request and may render the raw response body when the target returns an applicable non-success status
Why this happens
The underlying bug is a failure to restrict and validate a user-controlled connection destination before performing a server-side request. The ClickHouse driver treats the submitted server value as an HTTP target, allowing external input to influence the Adminer server's network connections. Reflecting the target's response body into the login-page error further enables information disclosure, mapping to CWE-918: Server-Side Request Forgery.
Potential impact
- An attacker may probe internal hosts and network ports reachable from the Adminer server.
- Internal service error pages may be disclosed through the login interface.
- Responses could reveal stack traces, hostnames, file paths, or configuration identifiers.
- Network segmentation assumptions may be weakened by server-originated requests.
General mitigation guidance
Mitigation generally focuses on removing user control over outbound connection destinations and applying explicit network trust boundaries.
Common defensive patterns include:
- Restricting connection targets to approved schemes, hosts, ports, and deployment-specific destinations.
- Rejecting loopback, link-local, private, and otherwise non-public address ranges where they are not required.
- Resolving and validating destinations consistently, including protection against DNS rebinding and redirect-based bypasses.
- Avoiding reflection of raw upstream response bodies in user-facing errors.
- Applying egress network policies and least-privilege service permissions around the Adminer host.
- Using secure-by-default connection profiles rather than arbitrary URL-based server inputs.
How teams detect issues like this
Organizations can look for SSRF indicators through:
- Static analysis rules identifying user-controlled values passed to HTTP clients or connection constructors.
- Code review checks for unrestricted URL, hostname, scheme, port, redirect, or address-family handling.
- Tests that verify rejection of loopback, private, link-local, and metadata-service destinations.
- Web and network monitoring for unusual outbound requests from Adminer to internal addresses or unexpected ports.
- Policy enforcement that limits application egress and prevents raw upstream response bodies from reaching authentication pages.
Automated security review tools may help identify server-side request flows, but deployment-level network controls remain important.
