The 72-hour federal patching clock on CVE-2026-10520 is real, and so is Ivanti's counter-claim that the exploitation that triggered it never touched a production customer. Both statements can be true at the same time, and the gap between them is where defenders need to focus this week.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on June 11, triggering BOD 26-04 and forcing federal civilian agencies to remediate within three days. The flaw is an unauthenticated, remote OS command injection in Ivanti Sentry that scores a 10 out of 10 on CVSS and yields root-level code execution. SecurityWeek reported that Ivanti shipped patches on June 10 across Sentry versions 10.5.2, 10.6.2, and 10.7.1, and updated its advisory to note the KEV listing. Ivanti's own position is sharper: the activity that put the CVE on KEV was "attempted exploitation of honeypots," not real-world targeting of customer systems.
The dispute resolves once the technical gating condition is named. CVE-2026-10520 is only reachable when the Sentry management interface on TCP port 8443 is exposed to a network an attacker can reach. In standard deployments, that interface sits behind a management appliance. EPMM-managed Sentry instances require mutual TLS to the management plane, and Neurons for MDM-managed appliances enforce restricted HTTPS. In those configurations, the unauthenticated path the CVE describes is not actually open to an external attacker. That is the basis for Ivanti's argument that honeypots are getting probed precisely because they often skip the management-side controls a production deployment uses.
The situation is not the same as declaring the CVE a nothingburger. A Sentry instance running outside the standard management chain is the configuration the CVSS 10/10 score actually describes: a lab appliance, a regional deployment someone stood up without EPMM enrollment, or an internal-only instance with port 8443 forwarded past the perimeter. A honeypot simulates that shape on purpose. CISA's KEV listing, with its three-day federal clock, is a blunt instrument that does not draw the distinction between a properly managed Sentry and a misconfigured one. The same advisory ends up telling two different stories to two different audiences.
The constructive operator takeaway is two-step. Patch to 10.5.2, 10.6.2, or 10.7.1, because vendor guidance on a CVE of this severity is not optional. Then audit whether any Sentry management interface is exposed to a network segment the deployment model does not assume: internet-facing, on a management VLAN reachable from a less-trusted zone, or behind a load balancer that terminates mTLS and re-encrypts without enforcing client certificates. Federal agencies have until the BOD 26-04 deadline to close that loop. The rest of the Ivanti Sentry installed base has the same problem on a longer clock.
The watch item for the rest of the week is whether independent telemetry, from Greynoise, Shadowserver, or Bitsight, corroborates either Ivanti's honeypot-only framing or the broader in-the-wild exploitation that KEV implies. Until that shows up, the dispute is a lesson in reading KEV entries as deployment-conditional risk signals rather than flat exploitation confirmations. It is also a reason to check the management plane, not just to pull patches.