OneUptime CVE-2026-112047

Requires an authenticated OneUptime project member (PR:L) who holds the AI-access admin-set permission at the project level but is NOT scoped (via labels/owners) to the target Kubernetes cluster; the vulnerable endpoints - AI access test, agent reset, kubectl plan approval, and incident AI conversation - validated only project-wide permissions instead of the per-cluster edit ACL (KubernetesCluster Update, labels and owners included) on affected versions 14.0.2 through 14.0.68. Deployment must actively use OneUptime's Kubernetes cluster management and AI agent features for the flaw to be reachable. Limiting factors: no unauthenticated/external path (project membership and the admin-set permission are prerequisites), impact is scoped to clusters within the same project, and the incident AI conversation path runs only read-only kubectl/infrastructure commands; fixed in 14.0.69.

This is a genuine but moderate-severity authorization flaw (CWE-863), not a critical priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 base score agree that exploitation is network-reachable and low-complexity but requires existing authenticated project membership (PR:L), which sharply limits the attacker population to insiders or anyone who has already obtained valid project credentials. Impact is bounded (VC:L/VI:L/VA:N, scope unchanged), consistent with information disclosure of RBAC permissions plus limited integrity actions (agent reset, kubectl plan approval, running commands on out-of-scope clusters) rather than full system compromise. There is no EPSS score, no CISA KEV listing, and no public proof-of-concept in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The security advisory, patch commit, and release are all confirmed, so the primary conflicting/missing signal is simply the absence of exploitation-probability data (EPSS) - reasonable for a recently disclosed, patch-available issue. Net: a real authorization-scoping bug worth patching, especially in multi-tenant/multi-member OneUptime projects managing Kubernetes clusters, but not an emergency given the authenticated prerequisite and limited impact.

A low-privileged but authenticated member of a OneUptime project invokes the Kubernetes AI access test, agent reset, kubectl plan approval, or incident AI conversation endpoints, which only enforce project-wide permission checks rather than per-cluster/label/owner scope. Because the network vector is low-complexity (AV:N/AC:L) once authenticated (PR:L), the member can enumerate agent RBAC permissions, disconnect agents, approve kubectl changes, or run commands against clusters they were never authorized to manage. No public exploit identified at time of analysis.