CVE-2026-112292 in CheckCle
Summary
by MITRE • 10/19/2026
CheckCle through 1.6.0 contains a missing authorization vulnerability that allows unauthenticated attackers to read, modify and delete records because shipped PocketBase collections use empty API rules. Attackers can query /api/collections/<name>/records endpoints to steal server_token values and alert_configurations secrets, disable alerting, alter status pages, or delete monitoring data.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in CheckCle versions through 1.6.0 represents a critical failure in access control mechanisms, specifically classified under CWE-285 as Improper Authorization. This flaw stems from the underlying configuration of PocketBase collections used by the application, which are shipped with empty API rules. In the context of web applications and APIs, these rules define who can perform specific actions such as reading, updating, or deleting data. When these rules are left empty or misconfigured to allow public access, it effectively disables authentication requirements for those endpoints, creating a direct path for unauthenticated attackers to interact with sensitive backend resources without valid credentials.
The technical exploitation of this vulnerability involves targeting the /api/collections/<name>/records endpoints exposed by the PocketBase instance integrated within CheckCle. Because there are no restrictions on who can query these records, an attacker can send HTTP requests directly to these interfaces from any location on the network or internet. The lack of server-side validation for user identity means that standard CRUD operations function identically whether initiated by a legitimate administrator or an anonymous actor. This architectural oversight allows attackers to enumerate existing data structures and extract sensitive information stored within the database, including server tokens and alert configuration secrets which are typically protected in properly secured environments.
The operational impact of this vulnerability is severe due to the nature of CheckCle as a monitoring tool. The ability to read records enables adversaries to steal server_token values and alert_configurations secrets. These credentials serve as keys for authenticating with external services or internal systems, potentially granting further access beyond the immediate scope of the application. Furthermore, the capability to modify and delete records allows attackers to disrupt security operations entirely. By altering status pages, they can mask ongoing attacks or create false positives that distract security teams. More critically, disabling alerting mechanisms ensures that malicious activities remain undetected for extended periods, while deleting monitoring data destroys forensic evidence necessary for incident response and post-attack analysis.
This vulnerability aligns with MITRE ATT&CK techniques related to Initial Access and Defense Evasion. Specifically, it facilitates unauthorized access through API endpoints (T1190) and allows attackers to disable security tools or services (T1562). The ability to delete monitoring data also correlates with Impact tactics such as Data Destruction (T1485), which aims to impair the availability of critical systems and information. The combination of these capabilities transforms a simple configuration error into a multi-stage attack vector that compromises confidentiality, integrity, and availability simultaneously.
Mitigation strategies must focus on immediate remediation of the underlying PocketBase configuration alongside application-level fixes. Administrators should update CheckCle to version 1.6.1 or later where this issue has been addressed by enforcing proper authentication rules on all API endpoints. For systems that cannot be immediately updated, it is imperative to manually configure the PocketBase collection rules to require valid user tokens for read, update, and delete operations. Additionally, network-level controls such as firewalls should restrict access to these internal APIs to trusted management networks only. Regular audits of third-party component configurations are essential to prevent similar misconfigurations in future deployments, ensuring that default settings do not introduce unintended exposure vectors.