CVE-2026-31936 is a search permission bypass in iTop versions prior to 3.2.3. The vulnerability allows authenticated users to retrieve records outside their authorized scope through search queries—specifically, the search layer does not correctly inherit or enforce the access control constraints that govern direct object access. This is not a missing permission check; it's a seam misplacement between the query construction layer and the access control model.
If you run iTop, verify your version immediately. The fix is in 3.2.3, but you need to determine whether your deployment is truly remediated or whether residual exposure persists through three vectors that the core patch may not address.
First, check your extension ecosystem. Any custom portal, reporting module, or third-party extension that directly consumes iTop's search API may still be propagating the vulnerability if it receives raw query capabilities rather than pre-filtered result sets. If extensions in your environment call the search layer directly, they inherit the bypass regardless of core platform hardening. Audit any custom code that queries iTop data.
Second, legacy search handlers and deprecated API pathways represent a ghost surface. Prior to 3.2.3, developers may have implemented workarounds or delegation hooks to handle access control at the search layer. Some of these pathways were likely deprecated rather than removed. Confirm that your deployment doesn't expose old search entry points that bypass the 3.2.3 fix—this is especially critical if you've migrated from earlier iTop versions and left behind custom integrations.
Third, understand what the search actually exposes. This isn't arbitrary record disclosure. ITSM tools contain operational intelligence—infrastructure mappings, change records, incident histories, user privilege data. The relational graph of your environment is searchable. An attacker who exploits this to query 'all systems with external IPs, owned by vendor X, with pending changes' gains a reconnaissance map for supply chain attacks. Prioritize this vulnerability not as a data leak but as a pivot point.
The fundamental architectural issue is that search was implemented early in iTop's lifecycle when datasets were small and user populations trusted, while access control was retrofitted to object retrieval later. The query layer was never retrofitted. Combodo's 3.2.3 fix either surgically patched the specific endpoint or refactored access control at the query generation stage—demand clarity from your vendor on which, because only the latter eliminates residual risk. Regardless, audit your extensions and legacy integrations before assuming you're protected.