CVE-2026-102410

Executive Summary

CVE-2026-102410 is a Missing Authorization vulnerability (CWE-862) in Kibana's Metrics Experience feature, where an internal API surface failed to enforce a Kibana-level authorization check that a related API in the same feature did enforce. A user holding only data-store-level read access to an index — but lacking the corresponding Kibana feature privilege — can retrieve index-derived metric data through the improperly constrained API. The confirmed impact is limited information disclosure (CVSS 4.3, Confidentiality: Low), requiring an authenticated low-privileged session but no user interaction.

Technical Analysis

The root cause is a missing authorization check (CWE-862) on an internal API surface within Kibana's Metrics Experience feature. Per the NVD description, the vulnerable API did not enforce a Kibana-level authorization check that an equivalent, related API in the same feature did enforce. This is a classic authorization-consistency defect: the feature's access-control model was applied unevenly across sibling endpoints.

The attack surface is the Kibana API layer reachable by an authenticated user. Once inside Kibana with a valid session, the attacker sends requests to the under-constrained internal endpoint rather than the properly-authorized counterpart. The authorization gate that would normally reconcile Kibana feature privileges against the requested operation is absent on this specific surface, so the request passes through to the underlying data layer.

The privilege mismatch is the crux: the attacker holds data-store-level read access to an index (e.g., Elasticsearch-level read on the backing index) but no corresponding Kibana feature privilege. Under correct behavior, the properly-authorized API would have blocked the retrieval because Kibana-level authorization is the intended enforcement boundary. Because the vulnerable API skips that boundary, index-derived metric data is returned to a principal who should not have been able to view it through Kibana.

Per the data provided, no specific function names, route paths, parameter names, or class names are available. The description does not identify the exact HTTP method, endpoint path, or parameter involved. The vulnerability class — CAPEC-1, "Accessing Functionality Not Properly Constrained by ACLs" — defines the mechanism: functionality reachable and usable by a principal beyond the intended ACL boundary.

No public PoC, exploit code, or Nuclei template exists (all confirmed negative). No affected version list is available in tracked sources.

Exploitation Scenarios

Step 1 — Reconnaissance / target identification. The attacker identifies a Kibana instance with the Metrics Experience feature enabled. This is an authenticated-adjacent step: the actor needs a valid Kibana session (PR:L, AC:L, no UI interaction required). Target identification can be done passively by confirming Kibana reachability and feature availability.

Step 2 — Privilege establishment. The attacker obtains or holds a low-privileged account that has data-store-level read access to a target index but no Kibana feature privilege granting access to the Metrics Experience data. This is the exact privilege configuration the flaw rewards — the account is "over-privileged" at the data-store layer relative to its Kibana role.

Step 3 — Triggering the flaw class. The attacker sends requests to the internal Metrics Experience API surface that lacks the Kibana-level authorization check. Because the endpoint does not enforce the Kibana feature privilege, the request is not blocked at the intended boundary. No exploit payload, injection string, or memory-corruption technique is required — the flaw is a pure authorization-gap: the request succeeds on the strength of the actor's session and data-store read access alone.

Step 4 — Post-exploitation impact. The response returns index-derived metric data that the properly-authorized sibling API would have blocked. The exposure is bounded to metric data derivable from the index the actor can already read at the data-store layer; it does not constitute write, integrity, or availability impact (CVSS I:N/A:N). The actor can enumerate or extract metric values that should have been gated behind Kibana feature privileges, potentially disclosing operational, performance, or business metrics.

No public PoC is available; the attack chain is inferred from the vulnerability class (CWE-862 / CAPEC-1) and the authorization-mismatch described in the NVD entry.

Impact Assessment

The impact is information disclosure limited to Confidentiality: Low. Per CVSS:3.1 subscores: AV:N (network-reachable), AC:L (no special conditions), PR:L (authenticated low-privileged account required), UI:N (no victim interaction), S:U (impact confined to Kibana's security scope), C:L (limited data exposure), I:N (no integrity impact), A:N (no availability impact) — total 4.3.

The blast radius is constrained by the preconditions: the actor must already be authenticated and must already hold data-store-level read access to the index in question. This is not an unauthenticated perimeter breach and not a privilege-escalation-to-admin flaw. The realistic business impact is internal data exposure: metrics derived from indices an actor can read at the storage layer become retrievable through Kibana despite Kibana-level role restrictions. In multi-tenant or least-privilege deployments where Kibana roles are used to segregate visibility of observability/metrics data across teams, this undermines that segregation. Affected systems are Kibana deployments exposing the Metrics Experience feature; the underlying Elasticsearch data store is the source of exposed data. CISA KEV status is NO — no confirmed in-the-wild exploitation per tracked data.

Detection Guidance

Because this is an authorization-bypass against an internal Kibana API, detection focuses on anomalous access patterns to Kibana API surfaces and on audit-log evidence of a principal retrieving metric data without the corresponding feature privilege.

Sigma Rule

title: Kibana Metrics Experience Unauthorized API Access (CVE-2026-102410)
id: 7f3c1a20-9b6e-4d2a-8c11-0a1b2c3d4e5f
status: experimental
description: Detects access to Kibana internal Metrics Experience API without corresponding Kibana feature privilege, consistent with CWE-862 authorization bypass (CVE-2026-102410).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-102410
author: valtersit.com
date: 2026/01/01
logsource:
  product: kibana
  service: audit
detection:
  selection_path:
    url.path|contains:
      - '/api/metrics'
      - '/internal/metrics'
  selection_status:
    http.response.status_code: 200
  selection_user:
    user.roles|contains: 'kibana_'
  filter_authorized:
    kibana.privilege.granted: true
  condition: selection_path and selection_status and not filter_authorized
falsepositives:
  - Legitimate metric queries by properly-privileged observability users (tune by role)
level: medium
tags:
  - attack.t1213
  - cwe.862

YARA Rule

rule CVE_2026_102410_Kibana_Metrics_Authz
{
    meta:
        description = "Detects references to Kibana Metrics Experience internal API access attempts associated with CVE-2026-102410 authorization bypass"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-102410"
        date = "2026-01-01"
        cwe = "CWE-862"
    strings:
        $api1 = "/api/metrics" ascii nocase
        $api2 = "/internal/metrics" ascii nocase
        $feat = "Metrics Experience" ascii nocase
        $kbn = "kbn-xsrf" ascii nocase
    condition:
        ($api1 or $api2) and $feat and $kbn
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-102410 Kibana Metrics Experience Unauthorized API Access Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/api/metrics"; http.header; content:"kbn-xsrf"; classtype:attempted-recon; reference:cve,2026-102410; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-102410; sid:2026102410; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.action == "user_login" and user.roles : "kibana_user" ]
  [ http where http.request.method == "GET" and
            http.request.uri : ("/api/metrics*" or "/internal/metrics*") and
            kibana.privilege.granted == false and
            http.response.status_code == 200 ]

Splunk SPL Query

index=kibana_audit sourcetype=kibana:audit
| search (url.path="/api/metrics*" OR url.path="/internal/metrics*")
    http.response.status_code=200
| eval priv_granted=coalesce(kibana.privilege.granted, "false")
| where priv_granted!="true"
| stats count min(_time) as first_seen max(_time) as last_seen by user.name, url.path, src_ip
| where count > 0
| convert ctime(first_seen) ctime(last_seen)
| sort - count

Wazuh OSSEC Rule

<group name="kibana,cve-2026-102410,">
  <rule id="1024100" level="7">
    <decoded_as>json</decoded_as>
    <field name="url.path">/api/metrics</field>
    <field name="http.response.status_code">200</field>
    <description>CVE-2026-102410: Kibana Metrics Experience API accessed (possible authorization bypass - CWE-862).</description>
    <mitre>
      <id>T1213</id>
    </mitre>
  </rule>
  <rule id="1024101" level="10">
    <if_sid>1024100</if_sid>
    <field name="kibana.privilege.granted">false</field>
    <description>CVE-2026-102410: Unauthorized Kibana metrics data retrieval confirmed - missing Kibana feature privilege.</description>
    <mitre>
      <id>T1213</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch evidence exists from any tracked source, no vendor fix is referenced, no workaround is documented, and no affected version range is available. Treat this as unpatched and enforce compensating controls.

1) Immediate mitigations.

• Restrict Kibana access to trusted networks and authenticated users only; the flaw requires an authenticated session (PR:L), so tightening session issuance reduces the exposed population.
• Enforce least privilege at the data-store layer: revoke index read access from Kibana users who do not have a corresponding Kibana feature privilege for Metrics Experience. Because the flaw exploits the mismatch between data-store read access and Kibana feature privileges, eliminating that mismatch removes the attacker's premise.
• Where the Metrics Experience feature is not required, disable it to remove the attack surface.
• Monitor Kibana audit logs for principals retrieving metric data without the corresponding Kibana feature privilege (see Detection Guidance).

2) Patch / upgrade steps.

• No vendor patch is available per tracked sources. Monitor the Elastic/Kibana security advisories page and the NVD entry for CVE-2026-102410 for a fixed release. When a patch ships, upgrade Kibana to the fixed version and re-validate role mappings. Do not assume any current version is patched.

3) Long-term hardening.

• Adopt a consistent authorization-enforcement pattern across all sibling/internal API surfaces; this defect arose because one endpoint enforced the Kibana-level check and its relative did not. Treat parallel-endpoint consistency as a code-review and regression-test requirement.
• Implement automated authorization regression testing for internal APIs (verify each endpoint enforces the same feature-privilege gate as its equivalents).
• Apply defense-in-depth: minimize data-store-level read grants and align them tightly with Kibana role definitions.
• Enable and retain Kibana audit logging with sufficient fidelity to reconstruct principal, endpoint, privilege-grant status, and response code.

References

• NVD — CVE-2026-102410: https://nvd.nist.gov/vuln/detail/CVE-2026-102410
• CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
• CAPEC-1 — Accessing Functionality Not Properly Constrained by ACLs: https://capec.mitre.org/data/definitions/1.html
• MITRE ATT&CK T1213 — Data from Information Repositories: https://attack.mitre.org/techniques/T1213/
• Elastic Security Advisories (monitor for Kibana fix): https://www.elastic.co/community/security

Threat actor / exploit-in-the-wild evidence: None available. CISA KEV status is NO; no public PoC, exploit code, or Nuclei template exists per tracked data; EPSS has not yet been scored by FIRST.org.