CVE-2026-100696

Executive Summary

CVE-2026-100696 is a pre-authentication Server-Side Request Forgery (SSRF) vulnerability affecting Adminer versions 4.16.0 through 6.0.1, residing in the optional Elasticsearch driver. Because authentication flow invokes Driver::connect() prior to validating login results, an unauthenticated attacker can force the Adminer server to issue arbitrary HTTP GET requests to internal hosts via crafted auth[server], auth[username], and auth[password] parameters. Successful exploitation enables internal network reconnaissance, port scanning, and service fingerprinting through a rendered response oracle, though it is bounded by the requirement that the optional Elasticsearch driver be deployed and that PHP allow_url_fopen be enabled.

Technical Analysis

The vulnerability is a classic SSRF (CWE-918) rooted in the ordering of authentication and connection logic within Adminer's request handling. In the affected versions, adminer/include/auth.inc.php invokes Driver::connect() before the login result has been validated. This means the connection routine — normally gated behind successful authentication — is reachable by an unauthenticated attacker who controls the submitted auth[server], auth[username], and auth[password] parameters.

When the optional Elasticsearch driver (plugins/drivers/elastic.php) is loaded, it uses get_url()/file_get_contents() to perform connection attempts. Critically, the driver performs only general server-syntax validation and does not block loopback, private, link-local, or other reserved address ranges. If no port is specified, it appends the default Elasticsearch port 9200. Adminer's generic port check additionally rejects ports below 1024, which constrains but does not eliminate the reachable attack surface — ports 1024 and above remain usable for scanning.

The observability of this flaw is what elevates it above a blind SSRF. Selected JSON error fields from non-2xx Elasticsearch-style responses, as well as raw connection failures, are rendered back on the login page. This turns the login interface into a port-scanning oracle: an attacker can distinguish open, closed, and filtered ports, and fingerprint services that emit Elasticsearch-compatible error responses. The request is issued server-side, so the attacker never needs direct network reachability to the target internal host.

Two deployment preconditions materially narrow the exposed population. First, the Elasticsearch driver is optional and is not present in a default build; it must be explicitly deployed, for example via the adminer/elastic.php template or an adminer_object() configuration. Second, PHP's allow_url_fopen must be enabled for file_get_contents() to fetch remote URLs. Where allow_url_fopen is disabled, the SSRF primitive is neutralized. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N) reflects network exploitability with no privileges or user interaction, a changed scope (the request crosses into internal network segments), low confidentiality impact, and no integrity or availability impact. The 5.8 base score is consistent with a reconnaissance-grade SSRF rather than a direct data-exfiltration or code-execution flaw.

Exploitation Scenarios

No public PoC or Nuclei template is available; the attack chain below is inferred from the vulnerability class and the explicitly described code path.

1. Reconnaissance / target identification. The attacker identifies an internet- or internal-facing Adminer instance deployed with the optional Elasticsearch driver enabled (e.g., reached through adminer/elastic.php or a custom adminer_object() configuration). Shodan-style fingerprinting of Adminer login pages supports this step; the driver need not be confirmed in advance because failed driver invocations are cheap to probe.

2. Triggering the flaw. The attacker submits a login request to Adminer supplying attacker-controlled auth[server], auth[username], and auth[password] values. Because auth.inc.php invokes Driver::connect() before validating the login result, the server-side connection attempt fires without any valid credentials. Pointing auth[server] at an internal address causes Adminer itself to originate the request.

3. Payload/execution at the vulnerability-class level. The Elasticsearch driver builds an HTTP request to the attacker-specified server using get_url()/file_get_contents(). If the attacker omits a port, the driver appends 9200; ports below 1024 are rejected by Adminer's generic port check, so the useful scanning range is 1024 and above. The attacker iterates reserved or internal targets and ports to map reachable services.

4. Post-exploitation impact. The login page renders selected JSON error fields from non-2xx Elasticsearch-style responses as well as connection failures. The attacker uses these rendered responses as an oracle to confirm open ports, distinguish filtered from closed ports, and fingerprint services that produce Elasticsearch-compatible errors. This yields internal network reconnaissance and service fingerprinting. Because the vector shows no integrity or availability impact, the outcome is information disclosure and attack-surface mapping that can feed subsequent, more targeted exploitation — not direct compromise of the Adminer host or the probed internal services.

This scenario is contingent on the two stated preconditions: the optional Elasticsearch driver being deployed and allow_url_fopen being enabled. If allow_url_fopen is off, the primitive is not exploitable as described.

Impact Assessment

The direct impact is limited to information disclosure (CVSS Confidentiality: Low) with scope change (S:C) — the attack crosses a trust boundary from the public Adminer interface into internal network segments. There is no integrity (I:N) or availability (A:N) impact, and the attack requires no authentication (PR:N) or user interaction (UI:N) with low complexity (AC:L), consistent with the 5.8 base score. The practical blast radius is the set of internal hosts and services reachable from the Adminer server, subject to the port floor of 1024 and the reachability constraints of the deployment.

Business impact centers on reduced internal-network opacity: an attacker gains a server-endorsed reconnaissance channel to enumerate internal services and fingerprint them, potentially enabling lateral-movement planning against services that were otherwise unreachable from the attacker's position. Exposed populations are those running Adminer at versions 4.16.0–6.0.1 with the Elasticsearch driver explicitly deployed and allow_url_fopen enabled. The EPSS score is not yet assigned by FIRST.org, and CISA has not added this CVE to the KEV catalog; there is no evidence of exploitation in the wild at time of writing. CVSS-derived severity alone may understate the value of this flaw to an attacker conducting multi-stage operations, since reconnaissance is frequently the first tactic in a broader kill chain (T1190).

Detection Guidance

Sigma Rule

title: Adminer Elasticsearch Driver Pre-Auth SSRF Attempt
id: 8f4c1d2e-3a7b-4c9d-9e21-adminerel188d
status: experimental
description: Detects Adminer login requests manipulating auth[server] toward reserved/internal addresses, indicating CVE-2026-100696 SSRF.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-100696
author: valtersit.com
logsource:
  category: webserver
  product: apache
detection:
  selection_method:
    cs-method: 'POST'
  selection_uri:
    cs-uri-stem|contains:
      - '/adminer'
      - '/elastic.php'
  selection_params:
    cs-uri-query|contains:
      - 'auth%5Bserver%5D'
      - 'auth[server]'
  selection_target:
    cs-uri-query|re:
      - '(auth(\[|%5B)server(\]|%5D)=)(127\.0\.0\.1|localhost|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.|169\.254\.|::1|0\.0\.0\.0)'
  condition: selection_method and selection_uri and selection_params and selection_target
falsepositives:
  - Legitimate administrative configuration of a remote database host within private ranges
level: medium
tags:
  - attack.t1190
  - cve.2026-100696

YARA Rule

rule CVE_2026_100696_Adminer_Elastic_SSRF
{
    meta:
        description = "Detects requests targeting Adminer Elasticsearch driver SSRF (CVE-2026-100696)"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-100696"
        date = "2026-01-01"
    strings:
        $drv = "elastic.php" ascii nocase
        $param1 = "auth[server]" ascii
        $param2 = "auth%5Bserver%5D" ascii
        $param3 = "auth[username]" ascii
        $param4 = "auth[password]" ascii
        $priv1 = "127.0.0.1" ascii
        $priv2 = "169.254.169.254" ascii
        $priv3 = "localhost" ascii
        $port = ":9200" ascii
    condition:
        (uint16(0) == 0x4854 or filesize < 8000) and
        (any of ($drv)) and
        (any of ($param1, $param2, $param3, $param4)) and
        (any of ($priv1, $priv2, $priv3, $port))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-100696 Adminer Elasticsearch Driver Pre-Auth SSRF Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"auth"; nocase; content:"server"; nocase; pcre:"/auth(%5B|\[)server(%5D|\])=(127\.0\.0\.1|localhost|169\.254\.|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)/i"; reference:cve,2026-100696; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-100696; classtype:attempted-recon; sid:2026100696; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=60s
  [network where http.request.method == "POST" and
     url.path : ("*adminer*", "*elastic.php")]
  [network where http.request.method == "POST" and
     http.request.body.content : ("auth[server]=127.0.0.1", "auth[server]=localhost",
        "auth[server]=169.254.*", "auth[server]=10.*", "auth[server]=192.168.*")]

Splunk SPL Query

index=web sourcetype=access_combined OR sourcetype=access_common
| eval raw=_raw
| where match(raw, "(?i)auth(\[|%5B)server(\]|%5D)=(127\.0\.0\.1|localhost|169\.254\.|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)")
| stats count values(uri_query) as queries values(clientip) as src by host
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="web,adminer,ssrf,">
  <rule id="100696" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>adminer|elastic\.php</url>
    <regex type="pcre2">auth(\[|%5B)server(\]|%5D)=(127\.0\.0\.1|localhost|169\.254\.|10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)</regex>
    <description>CVE-2026-100696: Adminer Elasticsearch driver pre-auth SSRF attempt targeting reserved/internal address</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack_recon,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations.

   • Remove or disable the optional Elasticsearch driver where it is not operationally required; the flaw is not present in a default Adminer build. If the driver must remain, restrict access to the Adminer interface via network ACLs, VPN, or an authenticating reverse proxy so it is not internet-reachable.
   • Disable PHP allow_url_fopen on hosts running Adminer; this prevents the file_get_contents()-based fetch that underpins the SSRF primitive.
   • Egress-filter outbound connections from the Adminer server to loopback, private, link-local, and other reserved address ranges (including the 169.254.0.0/16 metadata range and 127.0.0.0/8) at the host firewall, restricting destinations to explicitly required backends.

2. Patch/upgrade steps.

   • Upgrade to Adminer 6.0.2 or later, where the vulnerability is fixed. No vendor-published patch references are currently tracked, so validate the upgrade through the official Adminer distribution channel and confirm the fixed version in your deployment manifest.
   • After upgrading, verify that adminer/include/auth.inc.php no longer invokes Driver::connect() prior to login validation and that the Elasticsearch driver enforces address-range restrictions.

3. Long-term hardening.

   • Do not expose administrative database tooling such as Adminer to untrusted networks; place it behind strong authentication and least-privilege network segmentation.
   • Adopt an outbound allow-list model for server-side URL fetching, and routinely review any component that performs get_url()/file_get_contents()-style requests for SSRF-resistant input validation.
   • Maintain continuous monitoring for CVE-2026-100696 advisories and track EPSS/K EV status, since no patch evidence, PoC, or in-the-wild exploitation is currently recorded and the situation may change.

References

• NVD — CVE-2026-100696: https://nvd.nist.gov/vuln/detail/CVE-2026-100696
• Adminer official project/download page (verify fixed version 6.0.2): https://www.adminer.org/
• MITRE CWE-918 — Server-Side Request Forgery (SSRF): https://cwe.mitre.org/data/definitions/918.html
• MITRE ATT&CK T1190 — Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190/
• FIRST EPSS (score not yet assigned at time of writing): https://www.first.org/epss/

No known threat actor campaigns or exploit-in-the-wild evidence have been identified for CVE-2026-100696. CISA KEV status: NO. No public PoC, exploit code, or Nuclei template is currently available; exploitation prerequisites (optional Elasticsearch driver deployment and enabled allow_url_fopen) further constrain the exposed population.