Lorsqu'on a mis en place son processus de veille sur les vulnérabilités, l'une des étapes après la souscription aux flux d'actualités est la qualification des vulnérabilités.

Ce processus est primordial pour rendre l'information utile d'un point de vue opérationnel.

Prenons en fil rouge l'exemple de la CVE-2026-28858 :

En lisant ce résumé sans plus de contexte, il est bien difficile de déterminer quels sont les risques métiers effectifs.

Bien qualifier une vulnérabilité requière de passer par plusieurs étapes :

• Comprendre les caractéristiques intrinsèques, c'est-à-dire ce que la vulnérabilité représente d'un point de vue technique ;
• Déterminer l'environnement dans lequel la vulnérabilité s'inscrit ;
• Etudier le risque d'exploitation de cette vulnérabilité au regard de ses caractéristiques et de l'environnement où elle se manifeste.

Techniquement, c'est quoi une vulnérabilité ?

Commençons par définir une vulnérabilité. D'après le NIST (National Institute of Standards and Technology):

An error, flaw, or mistake in computer software that permits or causes an unintended behavior to occur. CVE is a common means of enumerating vulnerabilities.

Une vulnérabilité est donc avant tout une erreur dans un logiciel qui provoque un comportement inattendu.

Cherchons d'abord à déterminer quels sont les logiciels affectés.

Dans le cas de la CVE-2026-28858, on identifie rapidement que l'éditeur du logiciel vulnérable est Apple et le logiciel est le firmware présent sur les iPhones et iPads ayant un numéro de version antérieur ou égal à la version 26.4.

Cette erreur peut avoir un impact sur le système qui opère le logiciel, notamment dans le cadre d'une exploitation malveillante. On considère qu'un acteur malveillant aura généralement des motivations qui peuvent porter préjudice à l'un des éléments suivants :

• La confidentialité : le fait de contrôler quelles informations sont communiquées ou non
• L'intégrité : le fait que les informations détenues par le système d'information sont fidèles à ce qu'elles représentent
• La disponibilité : le fait que les fonctions de stockage et de traitement de l'information sont dans un état opérationnel
• La preuve : le fait qu'il est possible de prouver comment une information a été stockée et utilisée

L'évaluation d'une vulnérabilité intègre principalement les 3 premiers points de contrôle et c'est justement ce qu'il est possible de trouver dans le fameux score CVSS (Common Vulnerability Scoring System).

L'évaluation de l'impact que peut avoir une vulnérabilité sur ces thématiques est généralement réalisée par le rédacteur de celle-ci. Mais il peut subsister des situations où ce contexte n'est pas directement apporté et où ce sont des tiers qui le font.

Dans le cas de notre CVE-2026-28858, nous avons bien une évaluation qui a été faite par un tiers. Vous pourrez la trouver dans la section ADP (pour Authorized Data Provider, un tiers adhérent au programme CVE qui a la possibilité d'ajouter des informations complémentaires à la base de référence).

Cette évaluation est faite au regard des informations intrinsèques à la vulnérabilité. Généralement elles sont détaillées dans la description (on indique dans notre cas une "buffer overflow", une catégorie de vulnérabilité liée à une mauvaise gestion de la mémoire). Mais il peut être nécessaire de les mettre au regard du contexte : portion du code affectée, contexte d'exécution, informations de classification complémentaires, nature du logiciel affecté, etc.

C'est cette étape qui peut être fastidieuse car il n'est pas toujours facile sans expertise et sans contexte supplémentaire de déterminer dans la pratique les caractéristiques qui en découlent. Il est aussi important de ne pas accorder une confiance aveugle. Le rédacteur de la vulnérabilité est souvent l'éditeur et celui-ci peut être hostile à certaines formes de transparence.

Comme indiqué un peu plus haut, un ADP a ajouté des informations complémentaires pour nous :

• Le SSVC (Stakeholder-Specific Vulnerability Categorization), un système de prise de décision par rapport à la vulnérabilité. On y apprend qu'aucune exploitation active n'est rapportée, que l'exploitation de la vulnérabilité peut être automatisée par un acteur de menace et que l'impact technique final est total
• Le CWE (Common Weakness Enumeration), c'est un mécanisme de catégorisation de la vulnérabilité
• Le score CVSS de base, ici à 9.8 (critique)

Ces informations sont fournies dans ce cas par le CISA (l'agence américaine de la sécurité de l'information).

Arrêtons-nous un instant sur le score CVSS :

Alarmant à première vue non ?

Le score est à 9.8 sur 10, donc à un niveau classé critique. Le vecteur donne des informations sur les métriques utilisées dans le calcul, c'est-à-dire les considérations que nous évoquions plus tôt.

Nous n'allons pas entrer dans le détail du calcul dans cet article mais nous allons déterminer si dans notre contexte cette vulnérabilité est effectivement importante pour nous (ou non).

Comprendre le contexte de la vulnérabilité

On l'a vu, cette vulnérabilité affecte les systèmes d'exploitation iOS et iPadOS qui sont responsables du bon fonctionnement des iPhones et iPads.

En lisant le vecteur CVSS (avec un oeil expert, mais le calculateur du First permet de retrouver ces éléments), on comprend :

• Le vecteur d'attaque est le réseau : cela indique que cette vulnérabilité est exploitable à distance.
• La complexité, les privilèges nécessaires et l'interaction utilisateur non nécessaire placent les barrières à l'exploitation bas
• L'exploitation de la vulnérabilité ne permet pas directement d'accéder à un domaine hors du téléphone ciblé
• Les impacts en confidentialité, intégrité et disponibilité sont hauts

Même avec ces éléments en main, la prise de décision se base toujours sur des éléments vagues à ce stade.

On l'a vu un peu plus haut, le CISA indique qu'il n'y a pas d'exploitation connue de la vulnérabilité. On aimerait donc en tenir compte dans la suite de notre analyse ainsi que d'autres éléments temporels:

• La vulnérabilité est-elle activement exploitée ? Existe-t-il un code d'exploitation publiquement connu ? Quelles sont les circonstances de la découverte : audit interne ou annonce d'exploitation en 0-day (vulnérabilité exploitée avant que l'éditeur en ait connaissance) ?
• Avons-nous des options pour limiter le risque ou mettre en oeuvre un correctif ?
• Les informations à notre disposition sont-elles fiables ?

Se poser ces questions, c'est prendre en compte la réalité et l'importance de la menace telle qu'elle provient des adversaires. Il s'agit d'une étape essentielle dans la prise de décision.

Jusqu'ici nous avons des informations qu'on peut considérer comme raisonnablement fiables : Apple a un bon historique de transparence sur ses vulnérabilités et le CISA a une approche indépendante des éditeurs tout en constituant une source de référence.

Nous pouvons donc pousser un peu plus loin et consulter l'avis de l'éditeur spécifié en référence de la vulnérabilité pour se faire une idée plus complète.

Apple y spécifie un lot de vulnérabilités corrigées dans leur cycle de mises à jour de sécurité du 24 mars 2026.

On y retrouve notre CVE dans la section dédiée à la téléphonie et on y apprend qu'un correctif est effectivement disponible puisque qu'Apple détaille la mesure qu'ils ont mis en place pour corriger la vulnérabilité. Via les personnes créditées, on y apprend aussi que la vulnérabilité a été signalée par un laboratoire de sécurité des technologies embarquées à l'Institut supérieur coréen des sciences et technologies (KAIST).

Cette information constitue un signal faible que la vulnérabilité a été découverte dans un contexte académique et n'a à ce titre probablement pas été exploitée en amont.

Lorsqu'on fait une recherche sur le numéro d'identification de notre vulnérabilité, les références obtenues ne mettent pas en valeur une exploitation connue ou de potentiels codes d'exploitation. En consultant l'entrée au niveau de l'EPSS (Exploit Prediction Scoring System), on trouve un score de 0.00049 (à date de rédaction de cet article). Cela indique que la probabilité d'exploitation de cette vulnérabilité dans les 30 prochains jours est estimée à 0,049%. C'est très bas.

Dans notre calculateur CVSS, on peut y entrer en conséquence le résultat de nos conclusions :

• Il n'existe pas de code d'exploitation public.
• La vulnérabilité a été rapportée par un institut académique et non pas par des équipes de réponse à incident.
• Il n'y a pas d'exploitation active rapportée.
• Un correctif est disponible.
• Le faisceau de preuves nous donne un bon niveau de confiance.

Le score est toujours élevé mais nous avons perdu un point en prenant en compte la réalité de la menace. Si notre priorisation était uniquement basée sur ce score nous changerions tout de même de catégorie en passant de Critical à High.

Déterminons maintenant comment une exploitation nous impacte.

L'environnement d'exploitation

La vulnérabilité affecte un système qui se trouve dans un environnement particulier. Dans notre cas, nous supposons qu'il s'agit de notre flotte d'iPhones déployés pour fournir des outils de téléphonie à notre équipe commerciale.

Par politique et parce que nous avons des mécanismes de contrôle des données en place, nous savons que ces téléphones ne contiennent aucun secret industriel appartenant à notre organisation. De la même manière, ces téléphones sont connectés à un réseau de bureautique limité et séparé des réseaux plus critiques (production, ingénierie). Ils fonctionnent également sur un mode restreint qui limite les possibilités de connexion des appareils à des réseaux inconnus.

Toutefois, nos commerciaux répondent à des acheteurs de sociétés clientes qui ont un besoin important de réactivité. Ils peuvent aussi être amenés à discuter de contrats sensibles en cours de signature. Nous considérons ces informations moyennement sensibles.

Pour déterminer si nous souhaitons prioriser l'application de ce correctif, nous devons donc déterminer la partie environnementale du score CVSS et tenir compte de ces éléments.

Nous mettons donc à jour le score CVSS avec nos nouvelles métriques :

En prenant en compte l'ensemble des éléments de contexte, notre score CVSS est maintenant fixé à 6.8 sur 10. Soit une criticité moyenne alors que nous partions d'une vulnérabilité à priori critique.

Conclusion

Nous avons procédé à la qualification d'une vulnérabilité isolée dans son propre contexte. Vous l'avez certainement remarqué, elle n'est pas seule dans la mise à jour proposée par Apple le 24 mars 2026.

Nous devrions donc reproduire ce processus autant de fois qu'il y a de vulnérabilités rapportées dans ce bulletin et uniquement pour la flotte d'iPhones. Il n'y a dans cette mise à jour pas de vulnérabilité activement exploitée et il paraît sensé d'appliquer les correctifs sur la base de notre procédure habituelle. Inutile donc d'appeler l'astreinte.

Pourtant en février, une vulnérabilité activement exploitée (la CVE-2026-20700 si vous voulez retenter l'exercice) aurait pu justifier une prise d'action rapide.

VulnPilot, notre outil de renseignement sur les vulnérabilités, collecte, agrège et réalise cette analyse pour vous et pour chacune des vulnérabilités qui peuvent affecter votre parc informatique. À la clé, un score de priorité qui tient compte de tous les éléments que nous avons évoqué aujourd'hui dans cet article :

Plus encore, ces vulnérabilités sont automatiquement regroupées en plans d'action. Ceux-ci vous permettent de bénéficier d'encore plus de clarté en vous proposant une série d'actions vous permettant de corriger de multiples vulnérabilités sans devoir les analyser individuellement.