Kener CVE-2026-105030

Exploitation requires network reach to a Kener instance (version 4.0.0 up to but not including 4.1.6) exposing the vulnerable dashboard API handlers (monitor-bar, monitor-bars, monitor-latency-chart, monitor-day-incidents/latency/maintenances/status). No authentication and no user interaction are required (PR:N/UI:N). The key LIMITING factor is that the attacker must supply a valid monitor tag - known or successfully guessed - so disclosure is confined to monitors whose tags can be identified; impact is restricted to confidentiality of monitor metadata (names, descriptions, status, uptime history, latency) with no write or availability effect.

This is a genuine but moderate-priority issue, not a critical one. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 6.9 and correctly reflects network-reachable, low-complexity, unauthenticated access with low confidentiality impact only (VC:L; VI/VA:N) - there is no integrity or availability impact, so this is purely an information-disclosure flaw. The source-code diff confirms the root cause: dashboard API handlers (monitor-bar, monitor-bars, monitor-latency-chart, and several monitor-day-* endpoints) queried monitors by tag without filtering on status=ACTIVE and is_hidden=NO, so an attacker who supplies a valid tag receives data the operator intended to hide. No EPSS score, KEV listing, or public POC is present in the provided data, which lowers the realistic urgency: there is no evidence of active exploitation or mass scanning. The main mitigating factor against widespread automated abuse is that exploitation requires a known or guessed monitor tag, so disclosure is bounded to monitors whose tags the attacker can identify. Signals are internally consistent - no conflict between the vector and the description - and the vendor fix is confirmed, so the primary decision driver is simply patching to 4.1.6, prioritized by how sensitive the hidden monitors are in a given deployment.

An attacker who discovers a public Kener status page sends unauthenticated GET/POST requests to dashboard API handlers such as monitor-bar or monitor-latency-chart, supplying monitor tags that are known or guessed. Because these endpoints lacked visibility filters before 4.1.6, the server returns names, descriptions, status, uptime history, and latency for monitors the operator deliberately marked hidden or inactive. No public exploit code is identified at time of analysis, but the attack is trivial to reproduce with a simple HTTP client.