ManageEngine CVE-2026-11374: Hard to Exploit, but Patching Isn't Enough

A flaw has been found in a set of ManageEngine products — software many companies use to manage employee passwords and run Active Directory (the system that centrally manages user accounts inside an organization) — that lets an unauthenticated outsider take over a user's account. The vulnerability identifier is CVE-2026-11374, with a severity of 9.0 (Critical) out of 10 on the CVSS scale.

The root cause lies in the mechanism for "SSO (single sign-on)," which lets a user reach multiple services with one login. The token used to identify a logged-in user could be predicted from the outside. If an attacker guesses it correctly, they can impersonate that user without knowing the password. The maker, Zoho (the company behind the ManageEngine brand), has already released fixes.

The impact is limited to deployments integrated with the unified management suite "ManageEngine AD360." Organizations using the four affected products in that setup should move to the fixed builds described below sooner rather than later.

[Update, August 17, 2026] Exploitation is hard. But patching is not the end of it

Two months have passed since publication. In that time Bishop Fox published a technical analysis (July 21, 2026) that makes the real shape of this flaw much clearer. The conclusion first: compared with the number 9.0, the actual difficulty of exploiting this is high. This is not the kind of hole that gets broken open at random from across the internet.

That does not mean you can close the book on it. One risk survives the patch, and the vendor has not addressed it. This update covers why exploitation is hard, what remains anyway, and exactly what administrators should tighten.

What was actually going on (the root cause)

Bishop Fox's analysis revealed what the ticket really contained. The SSO ticket ID was String ticketId = time.toString() — that is, the return value of System.currentTimeMillis(), the current time in milliseconds. It is a 13-digit number derived from the clock, so it can be predicted. An attacker only has to put that value into a cookie named CUSTOM_SSO_TICKET and replay it to hijack someone else's session. A token that should have been random was, in effect, a clock reading.

Note that Bishop Fox has not released a fully weaponized proof of concept. The company says it demonstrated end-to-end takeover in a lab environment, but it has withheld the details.

Why a CVSS 9.0 flaw is hard to exploit

The CVSS vector itself says so. In CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H, the relevant piece is AC:H (attack complexity: high). Zohocorp, the CNA that assigned the score, rated it as requiring no authentication and no user action (PR:N / UI:N) but as needing conditions to line up. The 9.0 figure is pushed up by the size of the impact on success (S:C / C:H / I:H / A:H).

Bishop Fox breaks that complexity into three layers. They are the reason "you can read the clock, so you can guess the ticket" does not translate into a working attack.

In Bishop Fox's own framing, "blind brute-forcing across the internet is not a realistic mass-exploitation technique" here. Blind brute-forcing means trying values one after another with no feedback on whether you are getting warmer. Barrier (a) removes the feedback, (b) restricts where you can try from, and (c) caps how fast you can try — so a scenario in which this flaw spreads indiscriminately is hard to construct.

That is not the same as "no threat." The realistic threat Bishop Fox names is a targeted attacker who is already inside the network. Barrier (b) — only requests from the victim network are accepted — is no obstacle at all to someone with an internal foothold. So the honest reading is that this is not a hole for getting in; it is a tool for widening access once someone is already in.

A risk that survives the patch

This is the part that matters most. Zoho's fix replaced the clock-derived ticket value with a random UUID (a long, non-repeating random identifier) and nothing more. The value is no longer predictable, but the nature of the ticket is unchanged. It is still:

• non-HttpOnly — HttpOnly is the cookie setting that keeps JavaScript from reading a cookie; without it, scripts running in the browser can read the value
• long-lived — the validity period is long, so a value obtained once stays usable for a long time
• a bearer token — a voucher that identifies whoever holds it, with no check on who that is

Put those three together and a ticket stolen by any route still works against a patched host. The patch closed the "guess the value" path; the "steal the value and reuse it" path is still open. And no vendor response to this point has been confirmed. Following the ADSelfService Plus release notes, the build after 6529 (June 3, 2026) is build 7000 (June 13, 2026), and there is no notice of an additional fix or remediation for CVE-2026-11374. Closing the remaining gap is left to the customer.

Additional hardening for administrators

On top of applying the fixed build, Bishop Fox recommends four hardening steps (tightening settings to reduce the room an attacker has). All of them are reachable from the product's admin settings.

1. Shorten the session timeout. The long life of the ticket is the core of the residual risk, so cut the validity period itself. The goal is to narrow the window in which a stolen value is usable — filling in, on the customer side, exactly what the patch left untouched.

2. Tighten reverse-proxy trust settings. A reverse proxy sits between users and the product and relays traffic. If it unconditionally trusts HTTP headers that claim a source IP, an attacker can talk their way past barrier (b) — the rule that only requests from the victim network are accepted. Explicitly limit which proxies and which headers you trust.

3. Restrict TRUSTED_IPS. This is the product's own allowlist of source IPs. Leave it wide open and barrier (b) is effectively gone. Limit it to the hosts the SSO integration actually needs.

4. Monitor logs for URL_ROLLING_THROTTLES_LIMIT_EXCEEDED. That is the string written to the log when the rate limit — barrier (c) — is hit. A run of these entries reads as a trace of attempted brute-forcing. Register the string as-is in your monitoring rules and you will catch attempts early.

If you do not use the SSO integration at all, there is one more option: disable the CustomSSO integration. Bishop Fox offers this as an additional mitigation, and since it merely turns off a feature you are not using, the side effects are easy to reason about.

What Bishop Fox's detection script can and cannot tell you

On July 20, 2026, Bishop Fox published a detection script (CVE-2026-11374-check). Understand its nature and its limits before you run it.

It is not an exploit. All it does is send one invalid ticket and observe whether a cleanup header comes back; it never restores a session. There is no impersonation logic in it, so it is safe to run against your own assets. As of August 17, 2026, it is the only public GitHub repository related to CVE-2026-11374.

It cannot, however, tell you whether you are vulnerable. The patch does not change this code path, so a patched build returns the same response. The POTENTIALLY_AFFECTED result it prints only indicates that an AD360 integration exists; whether that host is vulnerable must be determined separately from the build number. Treat it as a tool for inventorying integrations, not for passing or failing a host.

Where things stand: no exploitation reports, and not in KEV

Here is the picture as of August 17, 2026. There are no reports of exploitation in the wild. It is not listed in CISA KEV either, confirmed against the August 14, 2026 catalog (and the same on our KEV list overview). The CISA-ADP Vulnrichment SSVC assessment shown alongside NVD reads Exploitation: none (no evidence of exploitation) and Automatable: no (not something that can be automated into mass attacks), which lines up with Bishop Fox's conclusion. On the detection side, Tenable Nessus plugin 322756 is available, so environments running a vulnerability scanner can enumerate unpatched hosts mechanically.

The product scope has not moved either. The ManageEngine advisory still lists the same four products as at publication, and no addition of affected products since July 2026 has been confirmed. The table below remains current.

Japan's public bodies have still issued nothing

In Japan there has been no output from public bodies at all. As of August 17, 2026, there is no relevant entry in JVN or JVN iPedia, no alert from JPCERT/CC, and no listing in IPA's important security information. We could not find a Security NEXT article either. The only Japanese-language mention is a single blog post translating overseas coverage. For organizations running AD360 in Japan, there is essentially no way to reach the real picture in Japanese — that exploitation is hard, but that stolen tickets still work after the patch.

Who does this flaw affect, and how?

The targets are organizations that place management tools integrated with ManageEngine AD360 somewhere reachable from the internet. These products are the entry point through which employees reset their own passwords and administrators handle accounts and audit logs. To an attacker, that is where the "ring of keys" to the organization is gathered — and if it can be opened from the front, there is hardly a more convenient target.

What the attacker does is predict the token (SSO ticket) that identifies a logged-in user, and hijack that login session by impersonating the person. No password entry and no phishing email are needed. Once the impersonation succeeds, they inherit that user's permissions and roles as-is. If the hijacked account belongs to an administrator, the impact spreads all at once.

Realistic damage includes using a hijacked employee account as a foothold to break into internal systems, abusing the password-reset feature to seize other accounts, and viewing or tampering with audit logs to erase traces of the intrusion. When the foundation of identity management is breached, the user management of the entire company that rides on top of it is shaken. As noted below, this attack is not trivial to pull off, but its severity is undiminished. That is exactly why updating to the fixed version is worth hurrying.

Affected products and fixed builds at a glance

Here are the four affected products, with their fixed builds and release dates. Compare them against the build number of the product you run; if yours is older than the one below, you need to update. The fixes have been rolling out since early June 2026.

In every case, what is affected is not standalone use but a configuration integrated with AD360. The fix for each product is distributed as a "service pack," which you can apply from the product's update menu or from ManageEngine's service-pack download page.

[Added August 17, 2026] This scope of four products still holds. Checking the vendor advisory as of August 17, 2026, no addition of affected products since July has been confirmed. The build numbers and fix dates are unchanged from the table above. Applying the fixed build, however, is not where this ends — see the update section near the top.

What is happening technically

The heart of the problem is how the "ticket" issued to authenticate an SSO session is generated. According to ManageEngine, when you sign in to these products via SSO through AD360, the ticket generated to authenticate that session was predictable to an unauthenticated attacker. A ticket should be a random value that no third party can guess.

This is classified as use of insufficiently random values (CWE-330) and generation of predictable identifiers (CWE-340), which in turn lead to improper authentication (CWE-287). By guessing a valid ticket, the advisory says, an attacker can obtain the target user's identity and role information and take over the account.

Reading the CVSS vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H), the attack can succeed over the network, with no prior authentication and no user action. On the other hand, the "attack complexity: high (AC:H)" rating means that predicting the ticket requires certain conditions and attempts, and is not something just anyone can reproduce easily. Even so, given that an account can be seized without authentication and the breadth of the impact, the overall score is rated 9.0 (Critical). Zoho says it has strengthened how tickets are generated so they can no longer be predicted.

[Added August 17, 2026] At publication we could only say that "predicting the ticket requires certain conditions and attempts." Those specifics are now known. The ticket ID was the value of System.currentTimeMillis() itself — the current time in milliseconds — and replaying it in a CUSTOM_SSO_TICKET cookie hijacks the session. At the same time, Bishop Fox's analysis revealed the three barriers that block exploitation, and the risk that survives the fix (the cookie is still non-HttpOnly). Details are in the update section at the top.

What administrators should do now

No workaround (a temporary mitigation via configuration change) has been published. The response is updating to the fixed build, which is the only measure. Step by step:

1. Check your configuration. First, confirm whether you use any of ADSelfService Plus, RecoveryManager Plus, M365 Manager Plus, or ADAudit Plus integrated with AD360. If you have not integrated with AD360, you are not directly within scope of this issue.

2. Check your build number and update. If a product's build is older than the one in the table above, apply the distributed service pack. ADSelfService Plus is fixed at 6529, RecoveryManager Plus at 6321, M365 Manager Plus at 4817, and ADAudit Plus at 8703 and later. The update steps can be reached from each product's advisory.

3. Review your exposure. These management tools generally do not need to be broadly exposed to the internet. Check that they are not directly accessible from outside, using firewalls and access restrictions. This is also a basic measure to limit the damage if another vulnerability appears.

4. Harden further, after updating. [Added August 17, 2026] The fix only randomized the ticket value; the cookie itself is still non-HttpOnly and long-lived. Pair the update with a shorter session timeout, stricter reverse-proxy trust settings, a restricted TRUSTED_IPS list, and log monitoring for URL_ROLLING_THROTTLES_LIMIT_EXCEEDED. The detailed steps are in the update section at the top.

ManageEngine's account-management products have a history of authentication-bypass vulnerabilities being exploited in real attacks and listed multiple times in the U.S. government's Known Exploited Vulnerabilities (KEV) catalog. CVE-2026-11374 is not in KEV as of writing and no exploitation has been reported, but keeping in mind that this is an often-targeted product, it is safest not to put off the update. For similar "authentication bypass in a login platform," cases like the authentication bypass in the login platform Casdoor and the account takeover in GitLab share a common point: self-hosted products tend to lag on updates and are therefore more dangerous.

What we know, and what we don't yet

Frequently asked questions

Q. I use a ManageEngine product standalone. Am I affected?

This advisory covers configurations where the four products are integrated with the AD360 suite. There is no mention of the vulnerability for standalone use. That said, since the fixed builds are shipping steadily, it is safest to update to the latest service pack regardless of configuration.

Q. It's CVSS 9.0, yet "attack complexity is high"? What does that mean?

The CVSS score combines the size of the impact (an account can be seized without authentication) and how easy the attack is. Here the impact is extremely large, while the vector carries AC:H (attack complexity: high). Per Bishop Fox's analysis, that complexity consists of a server-to-server handshake, source-IP binding, and a limit of roughly 40 requests per 60 seconds per IP, which makes brute-forcing across the internet impractical. Read 9.0 as "large impact," not as "anyone can exploit it instantly."

Q. Is there a risk it is already being attacked?

As of August 17, 2026, no in-the-wild exploitation or KEV listing has been confirmed. The CISA-ADP SSVC assessment likewise reads "no evidence of exploitation" and "not automatable," matching Bishop Fox's conclusion. However, ManageEngine's account-management products have been targeted in the past, so you cannot let your guard down. Not putting off the update is the best preparation.

Q. Once I apply the fixed build, am I done?

No. The fix only replaced the ticket value with a random UUID; the cookie itself is still a non-HttpOnly (readable by JavaScript), long-lived bearer token. A ticket stolen by any route therefore still works against a patched host. No sign of vendor work on this point has been confirmed, so you need to add a shorter session timeout, a restricted TRUSTED_IPS list, and stricter reverse-proxy trust settings on your side.

Q. Can Bishop Fox's detection script tell me whether I'm vulnerable?

No. The script is detection-only: it sends an invalid ticket and observes the response headers, and it is not an exploit. The patch does not change this code path, so a patched host returns the same response. Its POTENTIALLY_AFFECTED result only indicates that an AD360 integration exists, so always confirm vulnerability from the build number.

Q. Have Japan's public bodies issued an alert?

Not as of August 17, 2026. We could confirm no entry in JVN iPedia, no alert from JPCERT/CC, and no listing in IPA's important security information. The only Japanese-language mention is a single blog post translating overseas coverage.

Revision History

Sources

• ▸ManageEngine - Security advisory: CVE-2026-11374
• ▸Bishop Fox - A Millisecond of Predictability: Why CVE-2026-11374 Is Hard to Exploit (July 21, 2026)
• ▸GitHub - BishopFox/CVE-2026-11374-check (detection-only script) (July 20, 2026)
• ▸Tenable - Nessus Plugin 322756
• ▸ManageEngine ADSelfService Plus - Release notes (builds 6529 and 7000 confirmed)
• ▸NVD - CVE-2026-11374
• ▸ManageEngine AD360 product page
• ▸CISA - Known Exploited Vulnerabilities Catalog