The CVSS score of 6.5 for CVE-2026-34949 is misleading. This isn't a medium-severity issue — it's a privilege boundary collapse that transforms other vulnerabilities from medium into critical. The .readonly file in iTop gates every write operation in the application. Removing it doesn't just expose one function; it removes the global write lock across the entire platform. A stored XSS that requires authenticated access becomes remotely exploitable if an attacker can first delete this file and then exploit an IDOR or weak authorization check. You're not stacking severities — you're collapsing the privilege boundary that kept them separate.
The core problem is architectural: iTop treats filesystem state as a security boundary when it's actually mutable runtime state. The .readonly file is a configuration flag stored in a location the web server process can write to. An attacker who can determine the file path — and it's predictable, being part of the standard installation — can remove it without authentication. This isn't a code vulnerability in the traditional sense; it's a design failure where the application's permission model relies on the web server not modifying its own environment.
The patch quality determines whether Combodo understands this. A web-server configuration rule blocking DELETE requests to that path is fragile — it protects one deletion vector but leaves the file writable through other means. The meaningful fix moves write-permission enforcement into application logic or database-backed state, acknowledging that the filesystem cannot be a trusted security oracle.
Beyond this specific file, treat this as evidence of a broader pattern. Security controls implemented as deployment-time artifacts rather than application invariants create hidden exposure. Audit what else in your iTop deployment follows this model — configuration files, credentials, or any security-critical state that the web server process can mutate. The CVE is one instance; the architecture that produced it likely has siblings.