This CVE exposes a fundamental misunderstanding of where query-layer access control belongs. When iTop implemented silos for its OQL query language, the security check was attached to the SELECT clause — the visible output projection. But JOINs, WHERE conditions, subqueries, and EXISTS clauses can reference classes a user has no permission to access, and those references were never validated.
The root cause is not careless coding; it's a systematic cognitive trap. The SELECT clause is psychologically prominent — it determines what columns you see — while FROM, JOIN, and WHERE are treated as implementation details. This is the same failure pattern that's appeared in Django ORM, Hibernate HQL, Rails ActiveRecord, and others over fifteen years. The abstraction layer that makes query builders productive also makes the full data access surface invisible, so security checks get attached to what developers see, not what the query actually touches.
The fix required auditing the entire query AST for class references, not just the projection. This tells you the original implementation addressed the symptom (unauthorized SELECT results) rather than the attack surface (unauthorized data access through any query clause). If you're reviewing code that uses a query abstraction layer, ask: does the authorization check verify every class the query can reach, or only the classes in the SELECT statement?
The blast radius here is critical. iTop manages your CMDB — your infrastructure topology, change records, service relationships. A silos bypass doesn't expose one unauthorized row; it exposes the dependency graph of your entire IT environment. An authenticated user with limited access can traverse relationships they shouldn't see, mapping out infrastructure they shouldn't know exists.
Watch for this pattern in any system using an ORM or query builder. The abstraction that hides SQL complexity from developers is the same abstraction that hides security-relevant data access paths from auditors. If your access control lives at the output layer rather than the query construction layer, you're vulnerable to the same class of bypass.