CVE-2026-34741

COMPONENT VERSION RANGE

NewScan fingerprints iTop from its response and reports this CVE when the detected version falls inside the affected range below.

NVD scores CVE-2026-34741 at 8.6; recorded `critical` under docs/severity-standard.md because it is an UNAUTHENTICATED bypass that ends in PHP execution on the server - server-side takeover is exactly what critical is reserved for, and iTop is a CMDB, so the box it runs on holds the asset inventory of everything else. ONE row for Combodo's whole 2026-08-22 batch rather than sixteen: 3.2.3 fixes all of them, so sixteen rows would be sixteen findings that all say `upgrade to 3.2.3` (the Bouncy Castle / Mailpit precedent). The fifteen in `cves` are the rest of the same release - four reflected XSS in the back office (30826 OQL tester, 30890 synchro import, 31803 tagadmin.php, 31880 universal search) plus 30819/30865 in dashboard revert and save, 33240 in the foreign-key search API, three access-control holes (31936 object info via search, 34948 OQL silos checked only on SELECT classes, 34836 ajax.render.php / ajax.document.php), 30866 unauthenticated read of uploaded files by URL, 27490 a 24-bit PRNG guarding unauthenticated inline images, 34949 unauthenticated deletion of the setup `.readonly` marker, 33047 object locking without write rights, and 27463 the version disclosure. NO `ge` bound, deliberately, and this is the case where inventing one would be the error rather than the safeguard: Combodo ships a single maintenance train, older 3.1/3.0/2.7 lines get no backport, so `lt 3.2.3` cannot call a patched install vulnerable the way an unqualified SPIP bound could. Version-match only - proving 34741 means executing PHP on a customer's CMDB and proving the XSS pair means firing script in a logged-in admin's browser. Reachable as of today because the new iTop tech_signatures rows read the release in-band off the login page; MEASURED 2026-08-22 against vbkunin/itop:3.2.2 on loopback, where the real matcher returns iTop 3.2.2 and this row fires. THE VERSION SOURCE AND THE VULNERABILITY ARE THE SAME BUG, which is worth stating rather than discovering later: CVE-2026-27463 IS the login-page version disclosure and 3.2.3 removes it, so the release is readable exactly while the install is vulnerable and unreadable exactly when it is patched - the abstention is correct, but it is correct by coincidence, and the first iTop advisory with a fix ABOVE 3.2.3 will need a different version source before it can be written as a row at all. That is MEASURED, not reasoned: vbkunin/itop:3.3.0-beta1, booted and installed on loopback the same day, already carries the 27463 fix - its logo img has no title attribute at all (the alt changed from `logo` to `iTop logo`) - and the live tools returned `iTop None` with zero findings, which is the negative arm holding on a real build rather than on a fixture. Both containers removed after. Only two findings were recorded against the affected 3.2.2 install and neither is a false positive: this row, and the base image's genuinely outdated Apache httpd 2.4.58 -> CVE-2024-38475. Two things the probes did NOT flag on that install and which are backlog items rather than claims: /manifest.xml is 1.3 MB of anonymous path+md5 inventory, and /setup/index.php still answers 200 after installation.