CVE-2026-102412

Executive Summary

CVE-2026-102412 is an Incorrect Authorization flaw (CWE-863) in Kibana's Fleet management functionality. An authenticated user holding limited Fleet privileges can access credential material—specifically private cryptographic keys configured for Fleet Server host connections—that should be restricted to users with Fleet settings administrative access. Successful exploitation enables disclosure of sensitive key material that could allow impersonation of trusted Fleet infrastructure components, though no public proof-of-concept, exploit code, or known in-the-wild exploitation has been observed.

Technical Analysis

The vulnerability is classified as CWE-863 (Incorrect Authorization) and maps to CAPEC-1 (Accessing Functionality Not Properly Constrained by ACLs). The core weakness is an access-control enforcement gap: a functionality exposed within Kibana's Fleet management surface is not constrained by the same administrative ACL that governs access to sensitive Fleet Server credential material. As a result, a lower-privileged authenticated user can reach data that the application intends to expose only to Fleet settings administrators.

Per the NVD description, the impacted asset is private cryptographic key material configured for Fleet Server host connections. Fleet Server acts as the control-plane component that Elastic Agents enroll with and communicate through; keys associated with Fleet Server host connections are, by design, meant to be confidential trusted-infrastructure secrets. The authorization model fails to gate access to these secrets by privilege level, so the confidentiality boundary between "limited Fleet management user" and "Fleet settings administrator" is not enforced.

The attack requires authentication (PR:L) and is network-reachable (AV:N). No user interaction (UI:N) and no elevated privileges beyond a limited authenticated Fleet role (PR:L) are needed. The CVSS vector reflects an impact confined to confidentiality (C:H, I:N, A:N) within an unchanged scope (S:U).

Technical specificity available from the provided data is limited: no affected version range, no function/endpoint/path names, and no patch reference were disclosed. Implementers should treat this as an authorization-design gap in the Fleet privilege model rather than assume specifics not present in the source data.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class (CWE-863 / CAPEC-1) and the NVD description.

1. Reconnaissance / target identification: An attacker first obtains valid low-privilege credentials to a Kibana instance and identifies that the deployment uses Fleet management and Fleet Server host connections. The Kibana Fleet interface is reachable over the network (AV:N).

2. Triggering the flawed authorization check: Leveraging the limited Fleet management role, the attacker accesses the Fleet functionality that exposes sensitive credential material. The ACL that should constrain this functionality to Fleet settings administrators is not properly applied, so the request is authorized despite insufficient privilege. The exact request surface is not specified in the available data; the flaw class is improper enforcement of administrative constraints on privileged functionality (CAPEC-1).

3. Payload / execution at the vulnerability-class level: No code execution or crafted payload is required. The attacker simply issues authorized-but-overprivileged requests through the Fleet management interface to retrieve credential material. This is an access-control bypass, not a memory-safety or injection exploit.

4. Post-exploitation impact: The attacker obtains private cryptographic key material configured for Fleet Server host connections. Where those keys are actively used, possession of the material could enable impersonation of trusted Fleet infrastructure components—that is, an attacker could present themselves as legitimate Fleet Server infrastructure within the deployment. This undermines trust assumptions in the agent-to-server enrollment/communication channel.

Because no exploit code, Nuclei template, or public write-up exists, defenders cannot rely on signature-based knowledge of a specific exploit; behavior-based and authorization-audit detection (see below) are the practical avenues.

Impact Assessment

The CVSS 3.1 base score is 6.5 (Medium), with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Key subscores:

• Attack Vector: Network — exploitable remotely.
• Attack Complexity: Low — no special conditions to bypass.
• Privileges Required: Low — only an authenticated user with limited Fleet management privileges.
• User Interaction: None.
• Scope: Unchanged — impact stays within the Kibana/Fleet trust boundary.
• Confidentiality: High — disclosure of private cryptographic key material.
• Integrity/Availability: None per the vector.

Business impact centers on trust and identity compromise: exposure of Fleet Server connection private keys can enable impersonation of trusted Fleet infrastructure, eroding the integrity of the agent-management plane even though the CVSS integrity subscore is None (the vector scores the immediate disclosure, not downstream misuse). Blast radius is limited to deployments that use Fleet with Fleet Server host connections and whose keys are actively used. Organizations running Kibana Fleet in production should treat this as an elevated-priority confidentiality exposure given the sensitivity of the affected material. No CISA KEV listing and no EPSS score are available at time of writing.

Detection Guidance

Sigma Rule

title: Kibana Fleet Credential Access by Low-Privileged User
id: 3f9a1c7e-2b64-4d0a-9c1e-kibana-fleet-cred-863
status: experimental
description: Detects access to Kibana Fleet credential material by users without Fleet settings administrative privileges (CVE-2026-102412, CWE-863).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-102412
author: Threat Intelligence
date: 2026/01/01
tags:
  - attack.credential_access
  - attack.t1552
logsource:
  product: elastic
  service: kibana
detection:
  selection_endpoint:
    url.path|contains:
      - '/fleet'
      - '/api/fleet'
  selection_action:
    http.method: 'GET'
  selection_status:
    http.response.status_code: 200
  filter_admin:
    user.roles|contains: 'fleet_admin'
  condition: selection_endpoint and selection_action and selection_status and not filter_admin
falsepositives:
  - Legitimate Fleet administrators whose roles are not captured in the log field
level: high

YARA Rule

rule CVE_2026_102412_Kibana_Fleet_Credential_Access
{
    meta:
        description = "Detects Kibana access logs indicating retrieval of Fleet credential material by non-admin users (CVE-2026-102412)"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-102412"
        date = "2026-01-01"
        severity = "high"

    strings:
        $p1 = "fleet" nocase
        $p2 = "fleet-server" nocase
        $p3 = "host" nocase
        $p4 = "secrets" nocase
        $a1 = "access" nocase
        $a2 = "denied" nocase
        $a3 = "es_secrets" nocase

    condition:
        (uint16(0) == 0x7B7B or true) and
        (2 of ($p*)) and
        (1 of ($a*))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-102412 Possible Kibana Fleet Credential Access (Low-Priv User)"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/fleet"; nocase; http.uri; content:"fleet-server"; nocase; http.uri; content:"hosts"; nocase; classtype:attempted-recon; sid:2026102412; rev:1; reference:cve,2026-102412; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-102412;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.action == "user_login" and event.outcome == "success" ]
  [ network where event.category == "network" and
      url.path : ("/api/fleet*" or "/fleet*") and http.request.method == "GET" and
      not user.roles : "fleet_admin" ]

Splunk SPL Query

index=kibana sourcetype=kibana:access OR sourcetype=elastic:kibana
http_method=GET
(url_path="*fleet*" OR url_path="*/api/fleet*")
(user_roles!="fleet_admin" AND user_roles!="*superuser*")
| stats count min(_time) as first_seen max(_time) as last_seen values(url_path) as paths by user_name src_ip
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="kibana,fleet,cve-2026-102412,">
  <rule id="1024120" level="10">
    <decoded_as>json</decoded_as>
    <field name="url.path">\.?/api/fleet/.*hosts.*</field>
    <field name="http.request.method">GET</field>
    <description>CVE-2026-102412: Kibana Fleet credential material accessed by limited-privilege user</description>
    <mitre>
      <id>T1552</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
  <rule id="1024121" level="12">
    <if_sid>1024120</if_sid>
    <field name="http.response.status_code">200</field>
    <description>CVE-2026-102412: Suspected successful Fleet credential disclosure to non-admin user</description>
    <group>credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

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

1. Immediate mitigations:

• Restrict and audit Kibana Fleet roles. Ensure only users who genuinely require Fleet settings administrative access hold privileges that can reach Fleet Server host connection credentials; remove or narrow "limited Fleet management" roles where possible.
• Apply network segmentation and strong authentication in front of the Kibana interface; limit exposure of the Fleet UI/API to trusted administrative networks.
• Enable and centralize Kibana/Fleet audit logging and monitor for access to Fleet credential material by non-administrative users (see Detection Guidance).
• If Fleet Server connection keys are suspected exposed, plan rotation of the affected private key material and evaluate the trust impact on enrolled infrastructure.

2. Patch/upgrade steps:

• No vendor fix, patch reference, or affected version range has been disclosed through tracked sources. Monitor the vendor's security advisories and the CVE record for an official fix and version guidance. Do not assume a fixed version exists until the vendor publishes one.

3. Long-term hardening:

• Enforce least privilege and separation of duties across Kibana roles; design the Fleet privilege model so that sensitive credential material is reachable only through explicit administrative ACLs (align to CWE-863 remediation: enforce authorization server-side for every privileged function).
• Adopt routine rotation and secure storage of Fleet Server connection keys; treat them as high-value secrets.
• Maintain continuous authorization testing (role-based access-control regression tests) and monitor for CAPEC-1 (functionality not constrained by ACLs) patterns.

References

• NVD — CVE-2026-102412: https://nvd.nist.gov/vuln/detail/CVE-2026-102412
• CWE-863 (Incorrect Authorization): https://cwe.mitre.org/data/definitions/863.html
• CAPEC-1 (Accessing Functionality Not Properly Constrained by ACLs): https://capec.mitre.org/data/definitions/1.html
• MITRE ATT&CK T1552 (Unsecured Credentials): https://attack.mitre.org/techniques/T1552/
• Elastic Security Advisories (monitor for an associated Kibana/Fleet advisory): https://www.elastic.co/community/security

Note: No CISA KEV listing, no EPSS score, no public PoC/exploit code, and no known threat actor campaign or exploit-in-the-wild evidence were available for this CVE at time of writing.