Turning on SSO turned on the vulnerability, and turning it back off didn't help

The ManageEngine servers that fell to CVE-2022-47966 shared one trait: they had SAML single sign-on enabled, the thing security teams are constantly told to turn on. The vulnerability lived in the SSO handling, so doing the responsible thing, federating authentication through SAML, was precisely what exposed the box to unauthenticated remote code execution. And the vendor advisory’s wording carried a sting in the tail: it applied where SAML SSO “is/was enabled.” If you’d ever turned it on, even if you’d since turned it off, you were vulnerable. The good-hygiene checkbox was a one-way door.

What the bug is

CVE-2022-47966 is an unauthenticated RCE, CVSS 9.8, affecting 24 on-premise Zoho ManageEngine products (ServiceDesk Plus, ADSelfService Plus, Access Manager Plus, and many more). The root cause is a years-outdated bundled dependency: Apache Santuario (xmlsec) version 1.4.1, used to validate XML signatures on SAML assertions. An attacker sends a crafted SAML response to the SSO endpoint with a malicious XSLT stylesheet embedded in the signature’s transform section; when the stale xmlsec processes that transform during signature verification, it executes the attacker’s payload. No credentials needed. Zoho patched across the product line in October and November 2022, Horizon3 published a technical analysis and PoC on January 19, 2023, and CISA added it to the Known Exploited Vulnerabilities catalog on January 23 with the ransomware flag. Nation-state actors used it against internet-facing ServiceDesk Plus instances.

Three uncomfortable lessons

This CVE stacks several things worth pulling apart, because each one recurs.

A security feature was the attack surface. SSO is genuinely good practice; centralized, federated authentication reduces password sprawl and improves control. But “good for your identity posture” and “free of bugs” are different properties, and the code that implements a security feature is still code that can be vulnerable. The lesson isn’t “don’t use SSO,” it’s that enabling a feature, even a security one, expands your attack surface, and the feature’s implementation deserves the same patch attention as anything else.

“Was enabled” is a brutal clause. The advisory’s “is/was” wording reflects that the vulnerable code path and any persisted SAML configuration remained reachable even after SSO was disabled in the UI. That’s a reminder that turning a feature off in the console doesn’t always remove the underlying exposure, and that your remediation has to be the patch, not a config toggle you assume undid the risk.

One stale library, two dozen products. The bug wasn’t really ManageEngine’s authentication logic; it was an ancient version of a third-party crypto library that ManageEngine bundled across its entire product line. So a single outdated dependency became a simultaneous critical vulnerability in 24 products. This is the dependency-management story again, and the blast-radius version of it: when a vendor shares a component across a portfolio and lets it age, one library’s flaw is the whole catalog’s flaw. xmlsec 1.4.1 was many years old when this hit.

What to do

• Patch every affected ManageEngine product, now. Confirm the specific build for each product against Zoho’s advisory; the patches landed on different dates per product. If you run several ManageEngine tools, each needs checking.
• Don’t rely on having disabled SSO. Because the exposure persisted for instances where SAML was ever configured, the patch is the remediation, not toggling SSO off. Apply it regardless of your current SSO state.
• Get ManageEngine admin consoles off the public internet. These are IT-management products with broad reach; their web interfaces should sit behind VPN or strict access controls, not face the world. The exploited instances were internet-facing.
• Assume compromise on exposed, unpatched instances. With a public PoC since January 2023 and APT exploitation documented, an internet-reachable instance that lagged should be investigated for web shells, the management process spawning unexpected children, and the lateral movement these products’ privileged access enables. Rotate the credentials they held.
• Press vendors on bundled-dependency hygiene, and inventory your own. A product shipping a decade-old crypto library is a red flag; ask vendors how they track and update embedded components, and apply the same software-composition discipline to your own builds.

The reframe is for how you weigh enabling features. Every capability you turn on, including the security ones, is more code in your attack surface, and a feature implemented on top of a stale dependency can turn a best practice into your worst day. CVE-2022-47966 punished the organizations that adopted SSO and trusted that a security feature was inherently safe, on a product line carrying a years-old library. Patch the feature you turned on as diligently as the ones you didn’t, and don’t assume disabling something in the UI rolled back the risk. We flag the bugs that hide inside security features and shared dependencies, because those are the ones that catch the teams doing the right things.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2022-47966 — 2023-01
• ManageEngine Security Advisory: CVE-2022-47966 — 2022-10
• Security Affairs: Experts released PoC exploit for Zoho ManageEngine RCE flaw — 2023-01
• FortiGuard: PoC released for Zoho ManageEngine RCE vulnerability CVE-2022-47966 — 2023-01