Blog / Actualité sécurité

CVE-2026-118527 : la CVE Ivanti que le catalogue de la CISA lui-même n’explique pas

La CISA a ajouté CVE-2026-111357 et CVE-2026-118527 au catalogue KEV deux semaines après CVE-2026-104935. L’une referme une lacune de l’article original. L’autre pose une question à laquelle personne n’a encore répondu.

Études doctorales en sécurité de l’information achevéesSoutenance universitaire réussie · Soutenance finale de thèse à venir

La CISA ajoute deux CVE de plus à la même chaîne, et n’explique pas entièrement l’une d’elles

Tout le monde traite un ajout au KEV comme le moment où une vulnérabilité est enfin expliquée. L’entrée du catalogue de la CISA elle-même pour CVE-2026-118527 fait l’inverse. Elle affirme que le bogue existe, qu’il s’enchaîne avec deux autres CVE sur la même appliance, et s’arrête bien avant de dire ce qu’il est réellement. [4]

Deux semaines après mon article sur CVE-2026-104935 — la chaîne de welcome.cgi jusqu’au root que Volexity a reconstituée sur une appliance Ivanti Connect Secure entièrement corrigée —, la CISA a ajouté deux numéros de CVE supplémentaires pour cette même chaîne au catalogue des vulnérabilités activement exploitées, tous deux le 30 octobre 2026 : CVE-2026-111357 et CVE-2026-118527. [3][4] L’une règle un fil non résolu du premier article. L’autre en ouvre un nouveau.

CVE-2026-111357 est la moitié simple : enfin un nom pour un mécanisme que j’avais déjà détaillé

L’article original décrivait une étape d’élévation de privilèges sans numéro de CVE et sans correctif : un attaquant ayant déjà obtenu l’exécution de code en tant qu’utilisateur cgi-server sans privilèges pouvait rediriger dsinvoked, l’exécuteur de tâches root propre à ICS, en patchant la copie en mémoire d’une bibliothèque partagée. Cette étape a désormais les deux. Ivanti a publié un correctif le 29 octobre 2026, et la mise à jour de Volexity le nomme CVE-2026-111357. La description de NVD correspond indépendamment au mécanisme : le courtier dsinvoked fait confiance aux données de configuration DSCache, ce qui conduit à une élévation de privilèges jusqu’au root. [1][2]

L’indicateur de triage forensique propre à la CISA montre comment elle traite chaque CVE de cette chaîne. Obligatoire au titre de la Binding Operational Directive 26-04 pour CVE-2026-104935 et CVE-2026-111357. Pas obligatoire pour CVE-2026-118527. [5][3][4] Tirez vous-même vos conclusions sur le degré de certitude que la CISA accorde à cette troisième CVE.

// 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 ne correspond à rien que Volexity ait jamais écrit

La brève description de la CISA pour CVE-2026-118527 se lit comme une version simplifiée d’un bogue de l’article original : un attaquant distant et authentifié peut téléverser des fichiers dont il contrôle le contenu vers un emplacement connu sur le disque. [4] Cela ressemble à la façon dont se comporte déjà la course écrire-avant-de-valider de wu.cgi, qui écrit un fichier téléversé à un chemin prévisible dérivé d’un MD5 avant de vérifier son contenu. Proche, mais pas identique. L’article de Volexity, l’original comme la mise à jour, ne mentionne jamais CVE-2026-118527. [1] Et la CISA indique que celle-ci nécessite un attaquant authentifié. La course de wu.cgi, elle, est accessible sans authentification, via l’astuce d’en-tête de welcome.cgi qui ouvre toute cette chaîne.

Je ne sais pas laquelle de ces deux hypothèses est vraie : que CVE-2026-118527 soit un nouveau numéro pour un bogue déjà couvert sous CVE-2026-104935, ou qu’il s’agisse d’un problème de chemin prévisible véritablement distinct que personne n’a encore décrit publiquement. L’avis d’Ivanti lui-même, qui pourrait trancher cela en une phrase, ne s’est pas chargé lors de deux tentatives de recherche indépendantes, menées par deux personnes différentes, qui ont heurté le même mur par des voies différentes. C’est un obstacle persistant, pas une lacune à retenter plus tard. Jusqu’à ce que cela change, ou qu’Ivanti republie l’avis ailleurs, la question reste ouverte. Je préfère le dire clairement plutôt que deviner et me tromper dans un sens ou dans l’autre.

Un média rapporte un ordre en trois étapes que le compte rendu de Volexity lui-même ne confirme pas

Il y a un second fil non résolu. Un agrégateur ayant couvert les ajouts au KEV du 30 octobre décrit un ordre de chaîne précis : la RCE non authentifiée (CVE-2026-104935), puis un dépôt de fichier authentifié (CVE-2026-118527), puis l’élévation de privilèges (CVE-2026-111357), comme si la CVE la plus récente était une étape intermédiaire délibérée. Le compte rendu de Volexity lui-même ne fonctionne pas ainsi. Il passe directement de la RCE de wu.cgi à l’élévation de privilèges de dsinvoked, sans étape séparée de dépôt de fichier décrite entre les deux. [6][1]

Soit ce média dispose de détails tirés de l’avis d’Ivanti que l’article de Volexity n’a jamais couverts, soit il se trompe tout simplement, et je ne peux pas dire d’ici lequel des deux. Je ne vais pas gommer ce désaccord en choisissant la version qui se lit le mieux. Ce même article cite par ailleurs deux scores CVSS différents pour CVE-2026-111357 dans son propre texte, 7.0 à un endroit et 8.8 à un autre, ainsi qu’un 4.3 pour CVE-2026-118527 que son propre tableau comparatif indique par ailleurs comme « en attente d’analyse ». [6] Considérez tout chiffre pour ces deux CVE autre que le 7.0 de NVD lui-même pour CVE-2026-111357 comme non confirmé, parce que c’est exactement le cas en ce moment. [2]

Ce qui change réellement pour vous, avec ou sans réponse à l’une ou l’autre question

Corrigez quand même. La première vague de correctifs pour CVE-2026-104935 a déjà refermé les étapes welcome.cgi et wu.cgi ; j’ai listé les builds exacts dans l’article original, et cette liste n’a pas changé. L’étape dsinvoked/DSCache nécessite sa propre mise à jour séparée, désormais suivie sous CVE-2026-111357, qu’Ivanti a publiée le 29 octobre 2026. L’échéance fédérale pour celle-ci était le 2 novembre 2026 — aujourd’hui, au moment où j’écris ces lignes. [1][3] L’échéance de CVE-2026-118527 court jusqu’au 13 novembre 2026, et l’indicateur de triage forensique propre à la CISA la marque comme « non obligatoire » au titre de la BOD 26-04, à la différence des deux autres. [3][4][5]

Ne laissez pas une question d’identité non résolue vous convaincre d’attendre. Que CVE-2026-118527 se révèle être un nouveau bogue ou un ancien renommé, le chemin de correction reste le même : builds actuels, avis actuels, et ne déclarez pas un incident clos sur la seule base d’un passage propre de l’Integrity Checker Tool. Cette limite de l’article original n’a pas disparu.

// 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.

Une entrée KEV non résolue n’est pas un fil que vous pouvez ignorer

La version honnête de cette mise à jour est plus courte que le bruit qui l’entoure : un nouveau numéro de CVE a refermé une lacune que j’avais signalée il y a deux semaines, et un autre nouveau numéro de CVE a ouvert une question à laquelle le catalogue de la CISA lui-même ne répond pas. Les deux sont vraies en même temps, et aucune n’annule l’autre.

C’est exactement le genre de lacune que je recherche quand je vérifie un correctif pour un client : non pas si la CVE du ticket a été corrigée, mais si chaque mécanisme attribué à une chaîne a réellement été corrigé, y compris ceux que personne n’a encore entièrement décrits. Si vous avez un boîtier Ivanti Connect Secure et que vous voulez que quelqu’un vérifie cela par rapport à ce qui tourne réellement chez vous, c’est exactement ce travail-là.

Sources

Besoin de vérifier ce point dans votre propre produit ?

Remédiation et vérification des correctifs

Vous voulez apprendre à trouver vous-même ce type de vulnérabilité ?

Formation individuelle à la revue de code sécurisé
Tous les articles

08Contact

Vous livrez un produit qui traite des données d’utilisateurs ?

Envoyez-moi un bref descriptif. Je réponds sous trois jours avec des questions ou une première proposition, et le prix est fixé par écrit avant le démarrage.