Kibana CVE-2026-49089

Exploitation requires a valid Kibana account with at minimum read-only privileges - unauthenticated access is insufficient. The vulnerable code path is the connector reporting operation's query expression handler; this feature must be reachable by the attacker's role. No non-default configuration setting is identified as a prerequisite: the flaw appears to exist in standard Kibana deployments wherever the reporting connector feature is accessible. Limiting factors: the attacker must authenticate (PR:L per CVSS), must be able to reach the Kibana network endpoint (blocked in air-gapped or strictly network-segmented environments), and must target the specific reporting connector endpoint. There is no user interaction required and attack complexity is low once credentials are obtained. The exploit does not exfiltrate data or modify state - its sole impact is availability.

The CVSS base score of 6.5 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H correctly captures the key risk dimensions. The network-accessible attack vector (AV:N) and low complexity (AC:L) mean exploitation requires no special network position or timing. The PR:L metric is the critical limiting factor: an attacker must hold a valid Kibana account - but only read-only access is required, dramatically lowering the barrier compared to admin-only flaws. The availability impact is rated High (A:H) and is not overstated: a single request causes a full-process hang requiring manual intervention to restore service, meaning the practical availability impact is total rather than partial. Confidentiality and integrity are unaffected (C:N/I:N), keeping the overall score from reaching Critical. No EPSS data was provided and the CVE is not listed in CISA KEV, so there is no confirmed evidence of active exploitation. The absence of a public POC lowers immediate opportunistic risk. However, the attack is trivially reproducible once an attacker understands the endpoint, making the exploitation probability non-negligible for any organization where low-privilege users have grievances or where credentials are at risk of compromise.

An internal analyst holding a read-only Kibana account - or an external attacker who has phished or brute-forced such credentials - sends a single HTTP POST request to the connector reporting endpoint containing a pathologically large query expression. Kibana's evaluation engine begins processing the oversized expression, consuming the entire Node.js event loop, and all subsequent requests from legitimate users return errors or time out. The attack persists until a Kibana administrator manually restarts the process, resulting in a complete operational outage for any team relying on Kibana for dashboards, alerting, or SIEM visibility.