Blog / Security news

CVE-2026-118527: The Ivanti CVE CISA's Own Catalog Can't Explain

CISA added CVE-2026-111357 and CVE-2026-118527 to the KEV catalog two weeks after CVE-2026-104935. One closes a gap from the original piece. The other raises a question nobody has answered yet.

Completed doctoral studies in Information SecurityUniversity defense passed · Final dissertation defense pending

CISA adds two more CVEs to the same chain, and doesn't fully explain one of them

Everyone treats a KEV addition as the moment a vulnerability finally gets explained. CISA's own catalog entry for CVE-2026-118527 does the opposite. It says the bug exists, says it chains with two other CVEs on the same appliance, and stops well short of saying what it actually is. [4]

Two weeks after I wrote about CVE-2026-104935, the welcome.cgi-to-root chain Volexity traced on a fully patched Ivanti Connect Secure appliance, CISA added two more CVE numbers for that same chain to the Known Exploited Vulnerabilities catalog, both on 30 October 2026: CVE-2026-111357 and CVE-2026-118527. [3][4] One of them resolves a loose end from that first piece. The other opens a new one.

CVE-2026-111357 is the clean half: a name, finally, for a mechanism I already walked through

The original piece described a privilege-escalation stage with no CVE number and no patch: an attacker who already had code execution as the unprivileged cgi-server user could retarget dsinvoked, ICS's own root-level task runner, by patching the in-memory copy of a shared library. That stage now has both. Ivanti shipped a fix on 29 October 2026, and Volexity's own write-up carries an update note naming it CVE-2026-111357. NVD's description matches the mechanism independently: the dsinvoked broker trusts DSCache configuration data, leading to privilege escalation to root. [1][2]

CISA's own forensic-triage flag tells you how it's treating each CVE in this chain. Mandatory under Binding Operational Directive 26-04 for CVE-2026-104935 and CVE-2026-111357. Not mandatory for CVE-2026-118527. [5][3][4] Draw your own conclusion about how settled CISA considers that third one.

// KEV catalog entries for this chain, read directly from CISA's own catalog pages.

CVE-2026-104935   added 2026-10-13   due 2026-10-16   forensic triage: required
CVE-2026-111357   added 2026-10-30   due 2026-11-02   forensic triage: required   (Ivanti's patch shipped 2026-10-29)
CVE-2026-118527   added 2026-10-30   due 2026-11-13   forensic triage: not required

// Same chain, three different clocks, and CISA treating the third CVE
// differently from the other two without saying why in the catalog entry itself.

CVE-2026-118527 doesn't match anything Volexity ever wrote down

CISA's short description for CVE-2026-118527 reads like a plain-language version of a bug from the original piece: a remote, authenticated attacker can upload files with attacker-controlled content to a known location on disk. [4] That's close to how wu.cgi's write-before-validate race already behaves, writing an uploaded file to a predictable, MD5-derived path before it checks the contents. Close, but not identical. Volexity's write-up, the original and the update, never mentions CVE-2026-118527 once. [1] And CISA says this one needs an authenticated attacker. The wu.cgi race is reached unauthenticated, through the welcome.cgi header trick that opens this whole chain.

I don't know which of two things is true: that CVE-2026-118527 is a new number for a bug already covered under CVE-2026-104935, or that it's a genuinely separate predictable-path issue nobody has described in public yet. Ivanti's own advisory, which could settle this in one sentence, has failed to resolve on two independent research passes, run by two different people, hitting the same wall by different routes. That's a persistent barrier, not a retry-it-later gap. Until that changes, or Ivanti republishes the advisory somewhere else, this stays an open question. I'd rather tell you that plainly than guess and be wrong in either direction.

One outlet reports a three-stage order Volexity's own account doesn't support

There's a second loose thread. One aggregator covering the 30 October KEV additions describes a specific chain order: the unauthenticated RCE (CVE-2026-104935), then an authenticated file-plant (CVE-2026-118527), then the privilege escalation (CVE-2026-111357), as if the newer CVE were a deliberate middle step. Volexity's own account doesn't work that way. It goes straight from the wu.cgi RCE to the dsinvoked privilege escalation, with no separate file-planting stage described in between. [6][1]

Either that outlet has detail from Ivanti's advisory that Volexity's post never covered, or it's simply wrong, and I can't tell you which from here. I'm not going to paper over the disagreement by picking whichever version reads better. The same piece also quotes two different CVSS scores for CVE-2026-111357 in its own text, 7.0 in one place and 8.8 in the other, and a 4.3 for CVE-2026-118527 that its own comparison table separately lists as 'awaiting analysis.' [6] Treat any number for these two CVEs other than NVD's own 7.0 for CVE-2026-111357 as unconfirmed, because right now, it is. [2]

What actually changes for you, with or without an answer to either question

Patch regardless. The first round of fixes for CVE-2026-104935 already closed the welcome.cgi and wu.cgi stages; I listed the exact builds in the original piece, and that list hasn't changed. The dsinvoked/DSCache stage needs its own update separately, tracked now as CVE-2026-111357, which Ivanti shipped on 29 October 2026. The federal deadline for that one was 2 November 2026 — today, as I write this. [1][3] CVE-2026-118527's deadline runs to 13 November 2026, and CISA's own forensic-triage flag marks it 'not required' under BOD 26-04, unlike the other two. [3][4][5]

Don't let an unresolved identity question talk you into waiting. Whether CVE-2026-118527 turns out to be a new bug or a renamed one, the fix path is the same: current builds, current advisories, and don't call an incident closed on a clean Integrity Checker Tool run. That limitation from the original piece hasn't gone anywhere.

// What this update actually settles, and what it doesn't.

SETTLED
  - CVE-2026-111357 is the dsinvoked / DSCache privilege escalation
    described in the original piece. Ivanti patched it on 2026-10-29.
  - CISA added both new CVEs to the KEV catalog on 2026-10-30.

NOT SETTLED
  - Whether CVE-2026-118527 is a new bug, or an existing one (the wu.cgi
    predictable-path upload) given its own CVE number.
  - Which chain order is correct: Volexity's (RCE straight to privilege
    escalation) or the three-stage order one outlet reported, with
    CVE-2026-118527 as a separate step in between.
  - Any CVSS score for CVE-2026-118527. NVD has no record for it as of
    this writing.

An unresolved KEV entry isn't a loose end you get to ignore

The honest version of this update is shorter than the hype around it: one new CVE number closed a gap I flagged two weeks ago, and one new CVE number opened a question CISA's own catalog doesn't answer. Both are true at once, and neither cancels the other out.

This is exactly the kind of gap I go looking for when I verify a patch for a client: not whether the CVE on the ticket got fixed, but whether every mechanism anyone has attributed to a chain actually got fixed, including the ones nobody has fully described yet. If you're sitting on an Ivanti Connect Secure box and want someone to check that against what's actually running, that's the work.

Sources

Need this checked in your own product?

Remediation & fix verification

Want to learn to find vulnerabilities like this yourself?

Secure code review course, one to one
All articles

08Contact

Shipping something that handles user data?

Send me a short brief. I reply within three days with questions or a proposal outline, and the price is agreed in writing before work starts.