NORTH
Book a call
Oct 16, 2026 · 4 min read

Ivanti never assigned a CVE for the bug that hands attackers root

A CVE was assigned for the Ivanti escalation bug two days after disclosure, but not by Ivanti, and it still has no fixed version.

Article header: Ivanti never assigned a CVE for the bug that hands attackers root

Volexity traced an intrusion back to an Ivanti Connect Secure appliance running version 22.8R2.4, build 19097, with exploitation underway by October 3, 2026 — ten days before any of this was public. SecurityWeek reported the chain on October 13, the same day Volexity published the research behind it. Neither names a victim.

The chain has three links. Two are covered by CVE-2026-104935, which Ivanti's own CNA published October 13: an authentication bypass combined with a command-injection flaw that together hand an attacker code execution as the cgi-server user. Ivanti's description reads, verbatim, "Authentication bypass by spoofing in ICS before version 25.1.3.0 allows a remote unauthenticated attacker to execute arbitrary commands" — one CWE, CWE-290, covering two distinct defects. The third link is a separate privilege escalation that turns that cgi-server foothold into root. On October 13, Ivanti said the fix for it was still coming "in a future release in the coming weeks."

The score covers the entry, not the chain

CVE-2026-104935 carries a CVSS 3.1 base score of 8.6, and every outlet that covered this reported that number. Fewer read the vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. Scope Unchanged, Integrity Low, Availability Low — on a vulnerability whose own description ends in "execute arbitrary commands." That isn't a scoring error. It's arithmetically correct for the boundary Ivanti drew around this ID, and that boundary stops at the cgi-server account, one link short of root. The vector is the vendor stating, in a format built for machine parsing, exactly where its own scoring left off.

What happened to the third link

Re-querying MITRE's CVE record for Ivanti's recent assignments while drafting this turned up something the October 13 coverage couldn't have had. On October 15, a second record appeared: CVE-2026-111357, describing a flaw where Connect Secure 22.8R2.4 "mishandles the manner in which the dsinvoked broker trusts DSCache configuration data, leading to privilege escalation to root, as exploited in the wild in October 2026." That's the third link, now numbered.

Ivanti didn't assign it. The record's assigner is MITRE's own CNA, not Ivanti's — the same vendor that had filed the first CVE two weeks earlier through its own process. dateReserved and datePublished land in the same second, which is not how a vendor's advisory cycle runs; it's how an ID gets issued on request, outside that cycle.

Timeline from October 2 to October 16, 2026: October 2, CVE-2026-104935 reserved; October 3, exploitation begins on a fully patched appliance; October 13, SecurityWeek and Volexity publish, CVE-2026-104935 goes public, NVD analyzes it, and CISA adds it to KEV with an October 16 due date; October 15, MITRE assigns CVE-2026-111357 for the privilege escalation, bypassing Ivanti's own CNA; October 16, the KEV due date arrives and the second CVE is still unanalyzed by NVD, absent from KEV, and has no fixed version listed.

Having a number buys less than it looks like. NVD's record for CVE-2026-111357 shows vulnStatus: Received — not yet analyzed, no CPE range for a scanner to match a build string against. The affected block names exactly one version, 22.8R2.4, with no accompanying unaffected or fixed version listed anywhere in the record. CISA has not added it to the Known Exploited Vulnerabilities catalog as of this writing, and CISA's own vulnerability-enrichment tag on the record reads "Exploitation: none" — directly against the CVE's own description, which states the flaw is being exploited in the wild. Ivanti's advisory reference for the new CVE points to the same hub.ivanti.com URL as the first one; there's no separate advisory page for it either.

What to do with an ID that isn't finished

Treat a freshly assigned CVE as unverified infrastructure until each of the following checks out, not as a closed loop the moment it appears in a feed:

  • Who assigned it. Query cveawg.mitre.org/api/cve/<id> directly and check cveMetadata.assignerShortName. A vendor's own silence — an ID coming from MITRE instead of the product's own CNA — is itself a signal the vendor hasn't formally engaged yet.
  • NVD's vulnStatus. "Received" or "Awaiting Analysis" means no CPE match range exists yet. Don't read a scanner's silence on a CVE this new as clean; the scanner has nothing to compare against either.
  • KEV membership, checked directly against the JSON feed, not inferred from "exploited in the wild" language in a description. The two didn't agree here.
  • Whether the affected array names any unaffected or fixed version at all. If it doesn't, there is no build to upgrade to yet, regardless of whether the ID exists.

That's a recurring poll, not a one-time lookup. The honest cost of this practice is someone re-checking those four fields daily until the record stabilizes, because the feed your scanner subscribes to will lag all of them by days, and nothing will alert you when it catches up.

This week

  • Open a tracking item for CVE-2026-111357 now, owned by a person, with "fixed version published" as the trigger to close it rather than a calendar date — none exists yet.
  • Confirm your own scanner or vulnerability feed actually ingests MITRE-assigned records for your vendors, not only vendor-CNA ones; a scanner answers whether the build is below the fixed version, and this record has no fixed version for it to check against.
  • Don't close CVE-2026-104935 on the strength of its unaffected list alone — a build absent from one list can still be an affected version on another.
  • Read the KEV requiredAction text on CVE-2026-104935, not just the October 16 due date: it calls for BOD 26-04 mitigations and forensic triage, and the appliance Volexity found was fully patched for both numbered bugs when it was compromised — the patch is not the compromise check.

North InfoSec runs AI-assisted penetration testing and security assessments, including the kind of chained testing described above. northinfosec.com

← All articles