Combodo iTop EUVD-2026-64187

Exploitation requires an authenticated iTop account with OQL query submission privileges (confirmed PR:L per CVSS vector). The flaw is triggered specifically when an OQL query joins one or more classes that are not listed in the SELECT clause - the silo access filter is never applied to those joined classes. Multi-tenant or silo-segregated deployments represent the meaningful risk population; installations where all authenticated users are permitted to see all data have no effective exposure from this flaw. After patching to 3.2.3, full protection additionally requires setting security.disable_joined_classes_filter to false in configuration; leaving the default value of true means the joined-class filter remains disabled even on the patched version.

The CVSS 7.7 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) reflects network-accessible exploitation at low complexity by any authenticated user, with a scope change indicating that data outside the user's security boundary is reachable. The S:C/C:H combination is the most operationally significant element: in multi-tenant iTop deployments - such as MSPs serving multiple clients or enterprises using silos for department isolation - this flaw breaks the core confidentiality guarantee. No EPSS score was supplied in the source data, so exploitation probability cannot be independently quantified; risk must be inferred from CVSS metrics alone. No KEV listing confirms active exploitation, and no public exploit code has been identified. Single-tenant deployments where all users legitimately share access to all data have negligible effective exposure. A key post-patch risk remains: upgrading to 3.2.3 alone does not fully close the gap unless security.disable_joined_classes_filter is explicitly set to false - this default-true flag means administrators who upgrade without reviewing configuration will retain the vulnerable behavior, making incomplete remediation a realistic outcome.

An authenticated low-privileged iTop user assigned to Silo A crafts an OQL query that joins a class belonging to Silo B without including that class in the SELECT clause. Because the silo access check only evaluates SELECT-listed classes, the join executes without restriction, and the query returns configuration items, tickets, or contact records from Silo B. No public exploit code has been identified, but the OQL query construction required is straightforward for any user familiar with iTop's data model.