Combodo iTop CVE-2026-33047

Exploitation requires a valid authenticated session in the target iTop instance - no write, admin, or elevated permissions are needed, only a basic user account (PR:L). The vulnerability is present in all iTop deployments prior to version 3.2.3 using the default web interface with object-locking enabled. Exploitation is strictly limited to availability disruption: locking objects prevents legitimate write-permission users from editing them, but the attacker cannot read protected data or alter object content. Unauthenticated or external attackers cannot exploit this vulnerability. The key limiting factors are the requirement for a valid iTop user account and the absence of any confidentiality or integrity impact, constraining the realistic threat to insider misuse or compromised low-privilege credentials.

The NVD-assigned CVSS 3.1 score of 4.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L) accurately characterizes the limited scope: exploitation requires authenticated access (PR:L) and yields only partial availability impact with no confidentiality or integrity compromise. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog, and no public exploit code has been identified, both of which are consistent with the moderate severity rating. EPSS data was not provided in the input and cannot be inferred. The practical risk profile is that of an insider threat or compromised low-privilege account selectively disrupting IT workflows by locking ITSM objects. Attack complexity is genuinely low once authentication is satisfied, but the blast radius is confined entirely to the iTop instance. This represents a real but low-urgency remediation priority - organizations with strict RBAC delegation or read-only user populations should treat it as a near-term patch rather than an emergency.

An authenticated low-privilege iTop user - such as a read-only service desk analyst - sends a crafted AJAX lock request to ajax.render.php specifying the class and key of a target configuration item or change record. Because no authorization check is performed prior to the fix, the lock is granted under the attacker's session, and administrators or change managers holding legitimate write permissions receive a lock conflict error and cannot save edits until the lock expires or is manually cleared by an administrator.