CVE-2022-47966: Zoho ManageEngine SAML unauthenticated RCE, actively exploited
The short version: CVE-2022-47966 is an unauthenticated remote code execution flaw affecting a long list of Zoho ManageEngine on-premise products. It stems from an outdated bundled XML-security library (Apache Santuario xmlsec), and it's exploitable when a product has SAML single sign-on configured — for some products, even if SAML was only ever configured in the past. It scores 9.8, it was exploited in the wild, and it's in CISA's KEV catalog. Patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | Critical — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | 99.75% · 99.95th percentile (2026-07-17) |
| In CISA KEV? | Yes — added 2023-01-23, remediation due 2023-02-13 |
| Known exploited? | Yes — actively exploited in the wild |
| Vulnerability type | Unsafe XML signature handling (CISA lists CWE-20 improper input validation; NVD lists no CWE) → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication, but SAML SSO must be (or have been) configured |
| Affected | Many ManageEngine on-premise products (e.g. ServiceDesk Plus before 14004, ADSelfService Plus before 6211, Password Manager Pro before 12124, and others) — see the vendor advisory for the full matrix |
| Fixed in | The fixed builds enumerated per product in ManageEngine's advisory |
What you need to know
CVE-2022-47966 isn't one product's bug — it's a shared flaw across dozens of ManageEngine on-premise products that all bundled an old version of the Apache Santuario xmlsec (XML Security for Java) library. That library version left certain security protections up to the calling application, and the ManageEngine products didn't supply them — so an attacker can forge a SAML response and reach code execution on the server without authenticating.
Why it's a top-priority item:
- It's pre-authentication. Exploitation requires no valid account.
- The precondition is broad — and sticky. The flaw is exploitable when SAML SSO is configured, and for some products it stays exploitable if SAML SSO was ever configured, even after it's turned off. "We disabled SSO" is not automatically safe.
- It was mass-exploited. Public exploit code appeared quickly and attackers used it broadly; CISA added it to KEV.
How serious we see it
Critical — the 9.8 holds up.
Unauthenticated code execution across a whole family of internet-facing management products, with a low bar and public exploitation, is squarely top-of-queue. The bounded, reassuring part is that it's fixable and scoped: each affected product has a named fixed build, and the exposure question — do we run one of these products, and was SAML SSO ever configured? — is answerable. The catch is the sticky precondition: check whether SAML was ever enabled, not just whether it's on today.
Recommendations
Straight from ManageEngine's advisory and CISA:
- Patch now. Upgrade each affected ManageEngine product to the fixed build named in the vendor advisory.
- Check SAML history, not just current state. Determine whether SAML SSO is or was ever configured — that's the exploitability trigger.
- Hunt. Given public exploitation, review logs for the affected SAML endpoints and for signs of post-exploitation.
- If compromised, respond. Rebuild the host, rotate credentials and secrets, and investigate lateral movement.
- Confirm your exposure first. Inventory which ManageEngine products you run and which versions.
How BreachRisk sees it
BreachRisk discovers internet-facing ManageEngine products in your external footprint from little more than your domain, fingerprints the product and version, and flags exposure tied to this KEV-listed, actively exploited flaw — surfaced at the top of your results because it's in KEV. For this vulnerability, our value is fast, outside-in detection and prioritization of the exposed, affected product; confirming the SAML-SSO precondition and exploitability is a job for your patch-and-hunt follow-up.
That continuous, attacker's-eye view is the point: when a single shared flaw touches many products at once, the exposed instances are already mapped and ranked, so you can go straight to inventory-and-patch instead of starting from scratch.