The Everything Tool: What Ivanti's September Patch Reveals About the Trust We Outsource

There is a particular silence that settles over an IT operations room when someone realizes the tool they use to watch everything has quietly stopped watching them. It visited a mid-sized logistics firm I once advised — four thousand employees spread across three continents, every one of them carrying a managed phone, every one of them trusting a single console to decide what those phones could and could not do. That console could wipe a device, install software, read a configuration, silence a camera. In the most literal sense, it was the most powerful computer in the company. Whoever controlled it controlled the fleet. That is the shape of the September disclosure out of Ivanti. Ten CVE numbers. Three product lines. One patch cycle. And at the center of it, two words that should end every conversation about prioritization before it begins: authentication bypass. Not a buffer overflow in some forgotten library. Not a misconfiguration a customer committed on their own deployment. The failure was in the very logic that decides who is allowed to be in charge. When the thing that manages everything forgets who is permitted to manage it, the blast radius is not one application. It is every endpoint on the payroll. Context Ivanti is not a household name, and that is precisely the problem. It lives in the unglamorous layer of enterprise infrastructure that nobody photographs and everybody depends on. Three of its products matter here, and they matter together, because reading them as separate products is the first mistake most security teams will make. Sentry is a mobile traffic gateway. It stands between the mobile devices and the corporate backend, routing, inspecting, proxying. It is the border post. EPMM — Endpoint Manager Mobile — is the control plane. It manages the life cycle of the devices themselves: configuration profiles, patch policy, what gets installed, what gets revoked. And Neurons for ITSM is the service-desk brain, handling tickets and change workflows, deciding what counts as an approved action inside the IT department. Read those three roles back to yourself. Traffic. Control. Process. That is the entire chain of authority for a modern mobile workforce, sold as one integrated suite and deployed by administrators who, quite reasonably, assumed a security vendor had secured its own front doors first. The blockchain world should recognize this topology instantly, because we build the same kind of thing and give it different names. A bridge routes assets and holds custody. A multi-signature wallet controls the treasury. A governance module decides what counts as a legitimate change. The shape of the trust is identical — a small number of privileged components through which everything else flows. When decentralization advocates argue that a single point of trust is a single point of failure, this is the exact architecture we mean. So when a centralized vendor demonstrates that failure at scale, it is worth reading the code of that failure closely: not to gloat, but because the same lessons keep arriving in our own industry a few quarters later, wearing a different logo. I have spent years explaining why trust should be minimized and verified at every hop, and I keep a separate file of the times the centralized world proves the argument for me. This is one of those files. Conscience over consensus — the parts of the system everyone agrees to trust are the parts nobody checks. The Batch, Sorted by What It Actually Lets an Attacker Do Let me walk the September batch with an auditor's eye, because the severity ordering here is counter-intuitive, and the counter-intuition carries the entire lesson. Start with CVE-2026-83527, the Sentry vulnerability, rated 8.1. The technical classification is CWE-288 — authentication bypass using an alternate path or channel. In plain terms, an attacker reaches Sentry with no credentials at all, remotely, with no interaction required from a victim, and obtains full administrative access. The affected branches run back through R10.8.2, R10.7.3, and R10.6.4. An 8.1 does not, on its face, scream catastrophe. But a score measures a vulnerability, not a position. Sentry is not an isolated service. It is the proxy that mobile devices use to reach the corporate backend. If you hold Sentry as an administrator, you stand in the middle of every conversation those devices have with the enterprise. You can read, you can redirect, and — the part that rarely makes it into the advisory — you can harvest the credentials and tokens that pass through you. The severity is 8.1. The consequence is a master key to the building. Now take CVE-2026-18851, the EPMM flaw at 8.8. The class is CWE-862, missing authorization. This one requires an initial authenticated foothold — a low-privilege account, or a single compromised device. From there, an attacker escalates vertically to full administrative control. And what does that control unlock? Fleet configuration. Patch policy. The full mobile device management plane. In effect: command and control over every phone and tablet the company issued. Here is the reading I want you to hold. The EPMM vulnerability is a post-authentication privilege escalation, which means the industry's reflex — it needs credentials, so it is less urgent — is exactly backwards. Credentials are not a wall. In a world of reuse and leaked token pools, credentials are a door that is frequently left ajar. A post-auth escalation is not a harder attack. It is a quieter one, and quiet attacks are the ones that complete. Then there is the pair that belongs at the top of every remediation list and, in my experience, usually is not. CVE-2026-12744 and CVE-2026-12745, both in Neurons for ITSM, both rated 9.8. The class is deserialization of untrusted data leading to pre-authentication remote code execution. No credentials. No interaction. Code executing on the service. I have audited enough Java and .NET services to be blunt about deserialization: it is the cockroach of vulnerability classes. It survives frameworks, it survives refactors, and it stays on the OWASP Top Ten year after year because developers keep handing structured input to a parser willing to run whatever that input says. A 9.8 deserialization RCE is about as close as enterprise software gets to the door being open with the lights on. When two of them land in the same product on the same day, you are not looking at bad luck. You are looking at a process that is not catching an entire category of defect. The History That Is the Real Story Now set this batch against the history, because the history is the story. In August 2023, CVE-2023-38035 — a Sentry API authentication bypass, CVSS 9.8 — was actively exploited and promptly added to CISA's Known Exploited Vulnerabilities catalog. Then came CVE-2026-10523, a Sentry authentication bypass rated 9.9, allowing the creation of arbitrary administrator accounts without authentication. In January 2026, CVE-2026-1281 — an unauthenticated RCE in EPMM, CVSS 9.8 — was exploited as a zero-day. Months later, in May, came CVE-2026-6973, a post-authentication RCE in EPMM, used in chain with credentials the January zero-day had exposed. And now, in September, the batch in front of us: an authentication bypass in Sentry, a missing-authorization escalation in EPMM, and two pre-auth RCEs in Neurons for ITSM. I want to state the pattern plainly, because the industry keeps treating each as an independent event and they are not independent. The same product line has produced authentication bypasses across three consecutive years. CWE-288 and CWE-862 — both access-control weaknesses, both high on the CWE Top 25 — keep reappearing in the same family of products. That is not a run of bad luck. Based on my own audit experience, when the same class of defect recurs after patching, it almost always means the remediation was aimed at the individual CVE and not at the architectural cause. You patch the hole; you do not rebuild the wall. And so the next hole opens a meter to the left. The January-to-May chain deserves its own paragraph, because it is a textbook illustration of why losing a management tool is different from losing an application. CVE-2026-1281 was a zero-day; it was used before a patch existed. It exposed credentials. Those credentials were then reused in May against a separate, post-auth RCE — CVE-2026-6973 — to climb higher. This is what compromise looks like over time: not a single dramatic break, but a sequence in which each foothold funds the next. The management tool was not merely the target. It was the ladder. The Trust Cascade This is why the September batch worries me more than a set of CVEs normally would. Look at what the three product lines do together. Sentry guards the perimeter of mobile traffic. EPMM controls the devices. Neurons for ITSM manages the workflow of IT itself. An attacker who can move through those three has a complete path: from network edge, to device control, to process forgery. That last step is the one that keeps me up. If you reach the ITSM brain, you can open tickets, approve changes, and write the instructions other systems will treat as legitimate. You do not need to break the supply chain. You can author it. You can file a change request that looks ordinary and route it through an approval workflow that has been quietly subverted, and the enterprise will execute your instructions believing they came from its own people. Based on my audit work, that is the difference between an intrusion and an infection — and ITSM is where an intrusion learns to write prescriptions. I have seen this exact trust cascade before, in a smaller and less forgiving form. In 2017, during the fever of the ICO boom, I spent four months inside the smart contracts of a fundraising platform called EtherTrust. I found a reentrancy flaw that could have drained roughly $4.2 million of user funds. The interesting part was never the flaw itself. It was the assumption that had produced it — that because a component sat inside the system, it could be trusted with authority the rest of the system never re-checked. Centralized and decentralized architectures make the same mistake in different languages. We call one a privileged service account and the other a trusted contract, but the failure mode — authority inherited rather than verified — is identical. I published the EtherTrust findings rather than selling them quietly, and it cost me a lucrative consulting offer. It also gave me the reputation I still trade on. Trust is earned, not mined, and it is earned the same way in every architecture: by being verified at every hop. The Governance Failure The pattern across three years tells us something about the vendor, and I want to be fair as well as firm. The positive reading of the September batch is that Ivanti chose to publish ten CVEs together on a monthly cadence. That is better than reactive, one-off, panicked disclosures. From 2023 to now, the company has moved toward periodic, predictable patching, which lets enterprise customers plan their maintenance windows. That deserves acknowledgment. But the negative reading is louder. A monthly batch containing ten CVEs is not a sign of health. It is a sign of backlog. And the recurrence of access-control defects in the same product line suggests a security development life cycle with a structural blind spot, not a series of isolated slips. When a single class of defect survives three rounds of patching, the corrective action that was taken was evidently aimed at symptoms. The authentication module was not rebuilt. The threat model was not redrawn. The wall was plastered. I say this with a specific memory in mind. When I reviewed EtherTrust, what struck me was not the cleverness of the bug but the ordinariness of the thinking that created it — the assumption that once you are inside, you are trusted. That same assumption is what produces CWE-288 and CWE-862 at enterprise scale. It is not exotic. It is the default posture of engineers who have not been forced to ask who verifies the verifier. The Regulatory Frame The regulatory consequence of a batch like this does not fall primarily on the vendor. It falls on the customers, and most of them have not noticed yet. CVE-2023-38035, the 2023 Sentry bypass, was added to CISA's Known Exploited Vulnerabilities catalog. Under binding operational directive 22-01, that listing compelled federal agencies to remediate within a fixed window. The September batch carries no such listing — Ivanti states the vulnerabilities have not been seen exploited in the wild, and there is no evidence they have. But the historical footprint matters. In the previous twelve months this product family has already produced repeated zero-day-grade events, including the January EPMM zero-day. Federal contractors and critical-infrastructure operators running affected versions now sit on a compliance obligation regardless of whether an exploit exists, because their security baselines require timely patching of known severe defects. In Europe, the NIS2 directive imposes vulnerability-management duties on essential entities that do not care about CVSS scores; they care about whether a known-severe defect went unpatched. Under the SEC's disclosure rules, the burden of a four-business-day materiality filing rests with the affected public company, not the vendor — which means the practical effect of an Ivanti flaw can land on the balance sheet of a bank or a hospital that trusted its supplier. And in China and elsewhere, product-vulnerability regulations push the same obligation downstream. The uncomfortable truth is that the vendor's public statement — not observed exploited in the wild — is doing more compliance work than it can support. That statement is a snapshot of telemetry and known intelligence. It is not proof of absence, and it never has been. My own experience reading filings and advisories is that not-yet-exploited is a countdown, not an all-clear. The patch diff goes public the moment the fix ships, and the people who weaponize proofs of concept move in hours, not months. Historically, the window between a management-tool disclosure and observed exploitation is measured in days to a couple of weeks. The Market Frame The market consequences are quieter but real. UEM and MDM is a competitive field — Microsoft Intune, VMware Workspace ONE, Jamf and others — and customers increasingly buy security defaults rather than feature lists. A recurring pattern of authentication failures in a vendor's control plane does not produce a headline. It produces a slow drift of renewal decisions toward platforms that integrate identity and device management into infrastructure customers already own. When one vendor's security story is a stream of urgent patches, another's security story is a single sign-on boundary the customer never has to think about. Over a procurement cycle or two, that difference compounds. There is a perverse commercial wrinkle here, and it is worth naming. Widespread vulnerabilities do not hurt security spending; they justify it. Every disclosed flaw becomes a line item for compliance-driven patch management, for managed detection, for the remediation services built around the gaps. The industry's recurring revenue is, in part, financed by its recurring failures. That is not a conspiracy; it is an incentive, and incentives shape behavior. When a vendor's product is judged partly on responsiveness to its own vulnerabilities, the responsiveness itself becomes the product. Contrarian The consensus reaction to a batch like this is to triage: sort by score, patch the nine-point-eights first, note the eight-something ones as needs credentials, and move on. Conscience over consensus — I think that reflex is the actual vulnerability. A CVSS score measures one vulnerability in one context. It does not measure a control plane. Sentry, EPMM, and Neurons for ITSM are not three vulnerabilities; deployed together, they are one attack surface wearing three badges. A security team that patches them as three separate tickets has technically done its job and functionally missed the point. The number that should govern the response is not any individual score. It is the blast radius of the identity the tool holds. And the identity a management tool holds is, by design, enormous. There is a second contrarian point, and it cuts against my own tribe. It would be easy, and dishonest, to end by claiming decentralized systems would have prevented this. They would not — not automatically. The same trust cascade lives in our world: a bridge that routes everything, a multisig that controls the treasury, a governance module that approves changes. We have watched every one of those layers fail in exactly the same way. A nine-of-eleven multisig with eight keys on one laptop is a centralized system wearing decentralized branding. If we draw a lesson from Ivanti, it cannot be centralization bad, decentralization good. It has to be sharper: authority must be verified at every hop, and the components holding the most authority deserve the most scrutiny and the least convenience. That is the discipline this industry preaches and, all too often, does not practice. There is a third, quieter point about where the attack has moved. Attackers are no longer going primarily after operating systems and edge firewalls; vendors have hardened those and the returns are falling. They have moved to the management layer — the tools that administer the other tools. PaperCut. N-able. Ivanti. And, in the same September window, Microsoft's Patch Tuesday carried authentication gaps into its cloud identity services, while SAP's OVERPASS flaw, a CVSS 10.0 in the same class, was named by Mandiant among the most-exploited vulnerabilities of the prior year. When the identity provider itself can be bypassed on identity, zero trust stops being an architecture and becomes a slide deck. If the system that decides who you are can be lied to, nothing downstream of it is trustworthy by construction. Takeaway So what do we do with the September batch, beyond patching? Patch first, and patch the whole plane, not the loudest CVE. The two 9.8s in Neurons for ITSM go first, ahead of anything with a login prompt in front of it, because a pre-auth RCE does not wait for your credentials policy. Then Sentry, whose credential-free bypass sits on the border of everything. Then EPMM, understanding that its requires-authentication label describes a privilege escalation, not a perimeter. And then the step almost nobody takes: ask whether these three products should be holding the authority they hold at all. That is the question this industry asks itself constantly and answers too rarely. Who should hold the keys? How many hops stand between the edge and the treasury? What happens when the tool that watches everything is the one that stops watching itself? The management layer will keep being the target, because that is where the leverage is. The only real defense is to stop granting authority nobody verifies, and to start treating every trusted component as a future breach. Soul in the machine does not mean the machine is trustworthy. It means the people who build it owe us honesty about what it does when it fails — and proof, not a press release, that they rebuilt the wall instead of plastering over the crack.