BlackTree Security · Infrastructure · Automation · AI

The Ivanti ITSM Bugs That Let Strangers Run Code Before Login

An IT service-management system sits close to the machinery of an organisation: support requests, assets and workflows. Ivanti has now disclosed eight ways a remote user could make its Neurons for ITSM server run arbitrary code. Two of them require no login at all. The obvious question is not whether every ITSM server is compromised. It is whether your deployment reached the correct fixed state.

Ivanti’s 8 September bulletin says it was not aware of customer exploitation at disclosure. It says it found these issues using advanced language models in its product-security process. No confirmed exploitation is different from low risk: two of the flaws let a remote attacker run code without credentials.

Eight flaws, not one generic “Ivanti RCE”

The first two flaws are unauthenticated unsafe-deserialisation paths. Six other flaws involve unsafe deserialisation or missing authorisation, but require a logged-in user with low privileges. Those prerequisites change the immediate exposure, not the need to patch. A compromised low-privilege account could still become a route to server code.

VulnerabilityImpact and prerequisiteCVSS
CVE-2026-12744Unsafe deserialisation; remote code execution without authentication9.8
CVE-2026-12745Unsafe deserialisation; remote code execution without authentication9.8
CVE-2026-12651Unsafe deserialisation; remote code execution after low-privilege login8.8
CVE-2026-12650Unsafe deserialisation; remote code execution after low-privilege login9.9
CVE-2026-12648Unsafe deserialisation; remote code execution after low-privilege login8.8
CVE-2026-12645Missing authorisation; remote code execution after low-privilege login9.9
CVE-2026-12646Missing authorisation; remote code execution after low-privilege login9.9
CVE-2026-12647Missing authorisation; remote code execution after low-privilege login9.9

For each of these eight entries, the vendor lists the same affected and resolved release families. Cloud/SaaS version 2026.2 before mo2026.2 was affected; Ivanti says it applied the fix to every cloud landscape on 9 August. On premises, versions 2025.2, 2025.3, 2025.4 and 2026.1 need their respective September 2026 Security Patch. Version 2026.2 will also contain the fixes, but Ivanti says that new on-premises release will not be available until 21 September. It is not an immediate substitute for today’s release-line patches.

The exploitation and proof-of-concept status is likewise the same for all eight: Ivanti reports no known exploitation of customers before disclosure and no known public exploitation to support indicators of compromise. The bulletin does not establish whether a public proof of concept exists. Neither point removes the possibility of later exploitation. Ivanti lists no general workaround. Keeping an on-premises ITSM server off the public internet significantly reduces risk, but it is exposure reduction, not a fix.

The cloud and on-premises instructions are different

Cloud customers do not need to install a patch for this bulletin. Ivanti says the mo2026.2 fix reached all cloud landscapes more than four weeks before public disclosure. Administrators should still verify which tenant and environment they operate and retain the vendor’s confirmation. They should not apply on-premises guidance to SaaS by mistake.

On-premises customers need to identify every ITSM server and its exact release line, then obtain the matching September patch through Ivanti’s licensing portal. A generic “upgrade to 2026.2” ticket is not enough while that on-premises release remains unavailable. Confirm the patch level on every node, including test and disaster-recovery systems. If an instance is internet reachable, restrict access while the patch is prepared. Review logs and account activity according to normal incident-response practice, while recognising that Ivanti has not published exploit-specific indicators.

Ivanti’s monthly security post also names Endpoint Manager Mobile and Sentry. Those are separate products with separate advisories and fixed versions; their vulnerabilities are not additional rows in the Neurons for ITSM table above. The risk here is already substantial without borrowing severity from another product.

The lesson is proof of the fixed state

The most dangerous mistake would be to read the cloud remediation date and assume the entire estate is safe. Ivanti patched hosted landscapes in August, but the on-premises action falls on each customer. For a platform that can execute code on the server without authentication, the meaningful close-out is a version-by-version record showing which instances received which patch, not a general statement that “Ivanti was updated.”

Sources

Leave a Reply

Your email address will not be published. Required fields are marked *