CheckCle CVE-2026-112292

No special conditions - the vulnerability exists in the default shipped configuration, because CheckCle's bundled PocketBase collections (pb_schema_latest.json) use empty listRule/viewRule/createRule/updateRule/deleteRule values, granting unauthenticated access to /api/collections/<name>/records. The only prerequisite is network reachability of the CheckCle/PocketBase API endpoint; any instance whose API is exposed to the attacker (internet-facing or reachable on the internal network) is exploitable out of the box with no authentication, user interaction, or non-default setting required. The primary limiting factor is therefore exposure scope rather than any configuration or privilege barrier; patching to the fixed version (which sets '@request.auth.id != ""') or restricting network access to the API mitigates it.

All available signals point to a genuine high-priority issue rather than an inflated CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with VC:H/VI:H/VA:H, base 9.3) describes trivially easy, remote, unauthenticated exploitation with full confidentiality, integrity and availability impact on the vulnerable system - and this is strongly corroborated by the vendor fix commit (f2c338c), which replaces more than a dozen empty PocketBase API rules ('') with '@request.auth.id != ""', directly confirming that shipped collections were world-accessible. The root cause (CWE-862 missing authorization via default-empty API rules) means no special conditions or attacker skill are required, which is consistent with the AC:L/PR:N metrics. Tempering factors: there is NO EPSS score, NO CISA KEV listing, and NO explicit public proof-of-concept in the provided data, so active exploitation cannot be asserted - this is not a confirmed in-the-wild threat. The practical risk is therefore bounded primarily by exposure (how many CheckCle instances are internet-reachable) rather than by exploitation difficulty. For any organization running CheckCle ≤1.6.0 with a reachable API, this should be treated as an urgent patch; the main uncertainty is deployment footprint, not exploitability.

An attacker discovers an internet-exposed CheckCle instance and, without any credentials, issues GET requests to /api/collections/<name>/records to enumerate records, harvesting server_token values and alert_configurations secrets. Using the same open rules they then disable alerting, tamper with public status pages, or delete monitoring history to hide an outage or intrusion. No public exploit code is identified in the provided data, but the vendor fix commit discloses the exact vulnerable collections, making exploitation straightforward.