CVE-2026-33047: Combodo iTop Privilege Escalation Vulnerability

CVE-2026-33047 Overview

Combodo iTop is a web-based IT Service Management (ITSM) tool used to manage IT infrastructure, incidents, and service requests. CVE-2026-33047 is a missing authorization vulnerability [CWE-862] in iTop versions prior to 3.2.3. An authenticated user without write permissions on a target object can still acquire an ownership lock on that object. The flaw resides in the AJAX lock acquisition handler, which invoked iTopOwnershipLock::AcquireLock() without first verifying that the caller had UR_ACTION_MODIFY rights. Combodo fixed the issue in iTop 3.2.3.

Critical Impact
Authenticated low-privilege users can lock arbitrary iTop objects, blocking legitimate write operations by authorized users and degrading availability of ITSM workflows.

Affected Products

Combodo iTop versions prior to 3.2.3
Combodo iTop 3.x branch (fixed in 3.2.3)
Deployments exposing pages/ajax.render.php to authenticated users

Discovery Timeline

2026-08-21 - CVE-2026-33047 published to the National Vulnerability Database (NVD)
2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-33047

Vulnerability Analysis

The vulnerability is a missing authorization check in the AJAX endpoint responsible for acquiring iTop ownership locks. Before the patch, the handler read the obj_class and obj_key parameters from the request and passed them directly to iTopOwnershipLock::AcquireLock(). No call to UserRights::IsActionAllowed() gated the operation. Any authenticated user, regardless of assigned profile or ACL, could therefore lock any object in the Configuration Management Database (CMDB).

The practical impact is on integrity of the workflow and availability of the object. Once locked by an unprivileged user, other users with legitimate write permissions are prevented from editing the record until the lock expires or is released. In an ITSM context, this can stall incident tickets, change requests, and configuration item updates.

Root Cause

The root cause is broken access control on a state-changing action. The lock acquisition path in pages/ajax.render.php conflated authentication with authorization and treated the ability to reach the endpoint as sufficient. Object-level permission enforcement was performed only on the subsequent write, not on the lock itself.

Attack Vector

Exploitation requires network access to the iTop web interface and a valid low-privilege user account. The attacker sends a crafted AJAX request to pages/ajax.render.php specifying the target obj_class and obj_key. The server acquires the lock on behalf of the attacker without evaluating write permissions.

php

// Patch applied in pages/ajax.render.php
// Source: https://github.com/Combodo/iTop/commit/28db23069732da5322a4dda821135519297e5c29
$sObjClass = utils::ReadParam('obj_class', '', false, 'class');
$iObjKey = (int)utils::ReadParam('obj_key', 0, false, 'integer');

// Check user has access to the object before trying to acquire the lock
$oSearch = new DBObjectSearch($sObjClass);
$oSearch->AddCondition(MetaModel::DBGetKey($sObjClass), $iObjKey, '=');
$oSet = new CMDBObjectSet($oSearch);
if (
    false === $oSet->CountExceeds(0) ||
    UserRights::IsActionAllowed($sObjClass, UR_ACTION_MODIFY, $oSet) !== UR_ALLOWED_YES
) {
    throw new SecurityException(Dict::S('UI:ObjectDoesNotExist'));
}

$aResult = iTopOwnershipLock::AcquireLock($sObjClass, $iObjKey);

The fix instantiates a DBObjectSearch for the target object and calls UserRights::IsActionAllowed() with UR_ACTION_MODIFY. If the user is not allowed, a SecurityException is thrown before any lock is acquired.

Detection Methods for CVE-2026-33047

Indicators of Compromise

Repeated AJAX requests to pages/ajax.render.php with the lock operation parameter originating from accounts that hold read-only profiles.
Ownership locks held on CMDB objects by users whose profile does not grant UR_ACTION_MODIFY on that class.
User reports of persistent "object is locked" errors when attempting legitimate edits.

Detection Strategies

Correlate iTop application logs with the user profile database to flag lock acquisitions performed by accounts lacking modify rights on the target class.
Baseline normal lock acquisition volume per user and alert on outliers, particularly from service accounts or portal-only users.
Review web server access logs for unusual POST activity against ajax.render.php with the obj_class and obj_key parameters.

Monitoring Recommendations

Enable and centrally collect iTop audit logs covering lock, unlock, and modification events.
Ingest reverse proxy and PHP application logs into a SIEM to enable correlation across authentication and object access events.
Alert on any successful lock acquisition followed by no legitimate modification, which may indicate abuse aimed at denial of edit.

How to Mitigate CVE-2026-33047

Immediate Actions Required

Upgrade all Combodo iTop instances to version 3.2.3 or later.
Audit existing ownership locks and release any that were acquired by users without appropriate write permissions.
Review user profile assignments and remove excess accounts that no longer require access to the iTop portal.

Patch Information

The vulnerability is fixed in Combodo iTop 3.2.3. The corrective change is tracked as issue N°9233 and delivered in commit 28db23069732da5322a4dda821135519297e5c29, which adds a UserRights::IsActionAllowed() check with UR_ACTION_MODIFY before calling iTopOwnershipLock::AcquireLock(). See the Combodo iTop GitHub Security Advisory GHSA-3qpj-3fcg-f5jc and the upstream commit for details.

Workarounds

Restrict network access to the iTop web interface to trusted users and networks until the patch can be applied.
Tighten user provisioning so that only accounts with a legitimate need can authenticate to iTop.
Monitor and administratively clear stale locks on critical CMDB classes as a compensating control until the upgrade is deployed.

bash

# Verify installed iTop version and plan the upgrade to 3.2.3+
grep -R "ITOP_VERSION" /var/www/html/itop/approot.inc.php

# After upgrading, confirm the patched code path is present
grep -n "UR_ACTION_MODIFY" /var/www/html/itop/pages/ajax.render.php