CVE-2026-112047 in OneUptime
Summary
by MITRE • 10/18/2026
OneUptime 14.0.2 before 14.0.69 contains an incorrect authorization vulnerability that allows authenticated project members to act on clusters outside their scope by exploiting project-wide permission checks. Attackers can call the AI access test, agent reset, kubectl plan approval and incident AI conversation features to learn agent RBAC permissions, disconnect agents, approve kubectl changes, or run commands on unauthorized resources.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
OneUptime versions prior to 14.0.69 contain a critical authorization flaw rooted in the application's handling of project-scoped access controls for cluster management operations. The vulnerability arises from an incorrect implementation of role-based access control checks, where the system fails to validate whether specific actions are permitted within the context of individual clusters or nodes when initiated by authenticated users with broader project-level permissions. Instead of enforcing granular restrictions that align with the principle of least privilege, the software relies on coarse-grained permission checks at the project level. This architectural oversight allows an attacker who has been granted access to a specific project to bypass intended boundaries and execute administrative commands against clusters or resources outside their authorized scope. The core technical flaw is a broken object-level authorization mechanism where the server trusts client-supplied identifiers for cluster IDs without sufficiently verifying that the requesting user's role explicitly permits interaction with those specific targets, effectively treating all managed infrastructure within a project as accessible to any member of that project regardless of individual assignment or restriction policies.
The operational impact of this vulnerability is severe, as it enables authenticated attackers to perform high-privilege actions on unauthorized Kubernetes clusters and associated agents. By exploiting the flawed permission logic, an adversary can leverage several distinct attack vectors available within the OneUptime interface. These include invoking AI access tests, resetting agent configurations, approving kubectl plan changes, and engaging with incident AI conversation features. Each of these functions serves as a potential entry point for lateral movement or privilege escalation within the infrastructure environment. For instance, an attacker can use the agent reset functionality to disconnect monitoring agents from unauthorized clusters, potentially causing service outages or obscuring security visibility. Furthermore, the ability to approve kubectl plan changes allows the adversary to execute arbitrary commands on cluster resources they do not own, leading to potential data exfiltration, configuration tampering, or complete compromise of the underlying infrastructure. The exploitation also facilitates reconnaissance, as attackers can probe agent RBAC permissions to map out the broader security landscape and identify further targets for escalation.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is granted privileges that exceed their intended role or scope. In terms of offensive cybersecurity frameworks, this behavior corresponds to ATT&CK technique T1078, Valid Accounts, as the attacker leverages legitimate credentials but abuses them for unauthorized access. Additionally, the ability to manipulate cluster configurations and approve changes relates to T1546, Event Triggered Execution, and potentially T1098, Account Manipulation, if the agent reset or permission checks are used to alter security postures. The lack of proper object-level authorization also reflects CWE-732, which pertains to incorrect permissions assignment for critical resources. To mitigate this risk, organizations must immediately upgrade OneUptime to version 14.0.69 or later, where the vendor has addressed these permission checks by implementing strict validation logic that ensures users can only interact with clusters and agents explicitly assigned to their specific roles within a project. Until an update is applied, administrators should restrict access to sensitive endpoints such as agent reset and kubectl approval interfaces through network-level controls like firewalls or API gateways, ensuring that only trusted IP ranges or service accounts can reach these functions. Regular auditing of user permissions and enforcing strict separation between development, staging, and production cluster access policies are also recommended defensive measures to limit the blast radius if such vulnerabilities exist in other components of the infrastructure management stack.