Combodo iTop EUVD-2026-64183

Exploitation requires network reachability to the iTop web interface and the presence of a new iTop installation with env-production populated (i.e., the setup wizard has completed and modules are compiled into production). No authentication is required (CVSS PR:N) and no user interaction is needed (CVSS UI:N). Attackers are limited to PHP files that already exist within installed module directories under env-production - they cannot upload or inject arbitrary code via this vector alone unless a separate write-access path exists. The scope of impact is limited to the iTop application (S:U), not the underlying operating system. The description's specific mention of 'new iTop instance' suggests that the attack surface may be narrower on long-established instances with non-default module configurations, but this has not been confirmed by the vendor advisory.

The CVSS 3.1 base score of 8.6 is driven by network accessibility, no authentication required, no user interaction, and high integrity impact - all consistent with the description. Scope is unchanged (S:U), meaning exploitation is contained to the iTop application rather than the underlying host, which limits but does not eliminate risk: arbitrary module PHP execution can manipulate ITSM records, trigger backup operations, or expose data through module-specific pages. No EPSS score was provided in the input, and no CISA KEV entry exists, suggesting this has not been observed in broad active exploitation at time of analysis. The description's qualifier 'new iTop instance' is a notable limiting signal - it is unclear from available data whether mature, fully-configured instances with non-default modules are equally exposed or whether the attack surface narrows in established deployments. This condition is inferred from the description and is not explicitly clarified in the advisory. Overall, this is a high-priority patch target for any internet-exposed iTop deployment, but the real-world exploitation risk is moderated by iTop's relatively limited deployment footprint.

An unauthenticated attacker sends a crafted HTTP request to https://target-itop/pages/exec.php specifying a module name and a PHP page present in the env-production directory. Because exec.php performs no authentication check prior to the 3.2.3 fix, the server executes the targeted PHP file and returns its output, allowing the attacker to invoke module functionality - such as triggering backup operations via ajax.backup.php or manipulating ITSM records - entirely without credentials. No public proof-of-concept code has been identified at time of analysis.