Une vulnérabilité qui touche simultanément plusieurs éditeurs indépendants, le plus souvent via un moteur, une bibliothèque ou un protocole partagé, ne peut pas être traitée par un programme de divulgation des vulnérabilités ordinaire. La divulgation coordonnée multipartite exige une date d'embargo négociée, une structure de CVE convenue et, souvent, un coordinateur neutre, parce qu'aucun éditeur ne maîtrise seul le calendrier. Or presque tous les VDP en production aujourd'hui sont conçus pour le cas inverse : une entreprise, un rapport, un seul compteur.

Voici ce qui se passe quand cette hypothèse s'effondre, quel compteur fait réellement autorité, et pourquoi votre tableau de bord SLA peut afficher vert le matin même où une faille partagée devient publique.

## Une faille WebKit, et tous les navigateurs iOS qui passent par un proxy

Le 4 août 2026, les chercheurs de Mysk ont publié trois comportements de WebKit qui contournent le proxy configuré dans le navigateur et exposent l'adresse IP réelle de l'appareil ou ses résolveurs DNS. Les mécanismes en cause sont des fonctionnalités web tout à fait ordinaires : les indications `<link rel="dns-prefetch">`, où « une page peut intégrer dans ces balises des noms d'hôtes uniques par visiteur, puis observer les requêtes arriver sur son propre serveur DNS faisant autorité depuis le réseau réel du visiteur, et non celui du proxy » ; les Related Origin Requests de WebAuthn, où le service d'identifiants du système d'exploitation va chercher `https://<rpId>/.well-known/webauthn` hors du proxy ; et WebTransport, qui ouvre des connexions HTTP/3 QUIC directement depuis l'appareil.

Ce n'est pas le détail technique qui fait de ce cas un précédent. C'est la politique de la plateforme. Comme le résume la publication : **« Puisque la politique de l'App Store d'Apple impose à tout navigateur iOS d'utiliser WebKit, tout navigateur iOS qui s'appuie sur cette API pour son proxy est affecté, y compris tous les navigateurs Tor sur iOS et Psylo. »**

Une cause racine unique, dans une seule API de configuration de proxy, atteint d'un coup l'iCloud Private Relay d'Apple et tous les navigateurs axés vie privée distribués sur iOS, qui n'ont pourtant aucun lien entre eux. Apple est à la fois l'éditeur du moteur en amont *et* le responsable d'un produit en aval : même la réponse réflexe « on fait remonter à l'amont et on passe à autre chose » ne tranche pas qui pilote.

Regardez maintenant ce que cette divulgation ne contient pas. Aucun CVE. Aucune date d'embargo commune. Une prise de contact avec deux des parties concernées : « Nous avons contacté le Tor Project et les développeurs d'Onion Browser sur iOS au sujet de ces problèmes. »

Ce n'est pas un reproche adressé aux chercheurs, mais le portrait fidèle de ce qui arrive par défaut quand personne n'assure la coordination. Chaque éditeur concerné l'apprend à un moment différent, par une source différente, et certains l'apprennent en lisant l'article. Se retrouver dans cette dernière position [coûte cher](/blog/when-researchers-go-public-botched-disclosure).

## Qu'est-ce que la divulgation coordonnée multipartite ?

> La divulgation coordonnée multipartite (MPCVD) est le processus applicable à une vulnérabilité qui touche simultanément plusieurs éditeurs indépendants, le plus souvent via un composant, un moteur ou un protocole partagé. Contrairement à un VDP mono-éditeur, elle exige une date d'embargo négociée, une structure de CVE convenue et un coordinateur, parce qu'aucune partie ne maîtrise seule le calendrier.

Le document de référence est publié par FIRST : les **Multi-Party Vulnerability Coordination and Disclosure guidelines (v1.1)**. Il repose sur quatre piliers — des processus et des relations solides, une communication claire, la construction de la confiance, la réduction de l'exposition — et définit cinq rôles : **Finder, Vendor, Coordinator, Defender et Users/Deployers**, soit la personne qui découvre, l'éditeur, le coordinateur, le défenseur et les utilisateurs ou déployeurs. La plupart des VDP n'ont de vocabulaire que pour les deux premiers.

## Pourquoi ce cas est désormais la norme, et non l'exception

Dans un produit moderne, la majorité des vulnérabilités se logent dans du code que l'éditeur n'a pas écrit et qu'il ne peut pas corriger seul. Le rapport OSSRA 2026 de Black Duck, fondé sur « l'analyse de 947 bases de code commerciales dans 17 secteurs d'activité », établit que :

- **87 %** des bases de code auditées contenaient au moins une vulnérabilité
- **78 %** contenaient des vulnérabilités à risque élevé, dont **44 %** des problèmes à risque critique
- le nombre moyen de vulnérabilités open source par base de code « a plus que doublé, en hausse de **107 %**, pour atteindre une moyenne de **581** vulnérabilités »
- **93 %** contiennent des composants sans aucune activité de développement depuis deux ans

Le CERT Guide to Coordinated Vulnerability Disclosure nomme la cause sans détour : **« De nombreux produits ne sont plus développés par une seule organisation. Ils sont assemblés à partir de composants provenant d'autres organisations. »**

Poussez le raisonnement jusqu'au bout. Si l'essentiel de votre surface d'attaque est assemblé plutôt qu'écrit, alors l'essentiel de vos vulnérabilités est structurellement multipartite. Le rapport mono-éditeur devient le cas particulier — et c'est pour lui que votre outillage a été conçu.

## Les quatre sorties de votre file de triage, et pourquoi trois sont mauvaises

Ouvrez n'importe quelle file de réception d'un VDP et regardez les motifs de rejet. Le module CSIRT de Kit livre l'assortiment classique : `out_of_scope`, `duplicate`, `informational`, `not_reproducible`, `spam`, `other` et `ai_slop`. Chaque VDP a sa variante de cette liste et, pour un rapport portant sur une dépendance partagée, les deux sorties les plus tentantes sont l'une et l'autre mauvaises.

**`out_of_scope`** convient pour « cet actif n'est pas le nôtre ». Il ne convient pas pour « c'est bien notre produit, mais via le code d'un tiers ». Vos utilisateurs sont exposés dans les deux cas, et clore le rapport efface votre obligation sans rien changer à l'exposition. Le geste est aussi perçu comme hostile : le pilier « confiance » de FIRST rappelle qu'une escalade juridique produit « un effet dissuasif sur la recherche en sécurité que l'on cherche justement à encourager », et clore en silence un rapport de dépendance partagée relève du même registre. Le sujet est développé dans [la sphère de sécurité face aux menaces juridiques](/blog/safe-harbor-legal-threats-security-researchers-vdp).

**`duplicate`** dit précisément l'inverse de ce qu'il faudrait. Aujourd'hui, ce motif signifie « la même faille, déjà signalée chez nous », et il clôt le rapport. Un cas de dépendance partagée affirme le contraire : la même cause racine, dans le produit *de quelqu'un d'autre*. Cela doit maintenir le rapport **ouvert**, avec un second responsable et un second calendrier.

**`informational`** l'enterre. Quant à `not_reproducible`, c'est le piège classique : un éditeur en aval est souvent réellement incapable de reproduire isolément une faille venue de l'amont.

La sortie qui n'existe dans aucune taxonomie de réception courante est la cinquième : **liée**. Même cause racine, éditeur différent, calendrier coordonné, et responsabilité toujours nôtre. L'enjeu grandit à mesure que la recherche assistée par IA déverse dans les files de réception davantage de découvertes situées au niveau des dépendances, une évolution détaillée dans [l'IA et l'économie du triage des VDP](/blog/ai-cheap-vulnerability-research-vdp-triage-economics).

## Qui fixe la date d'embargo ? Personne : apprenez les plafonds

Aucune autorité ne fixe les dates d'embargo. FIRST se garde délibérément de prescrire : « En l'absence de preuve claire d'une divulgation publique antérieure (y compris une exploitation active), les parties prenantes devraient accorder aux éditeurs une période d'embargo raisonnable pour enquêter et développer des correctifs. » Lorsque plusieurs coordinateurs interviennent, « l'un d'eux doit être désigné comme chef de file ».

La date se négocie donc. Ce qui rend la négociation praticable, c'est de connaître les plafonds fermes auxquels les autres participants sont déjà tenus.

| Compteur | Durée | Qui est lié |
|---|---|---|
| Liste de diffusion `distros` | **14 jours maximum**, moins de 7 de préférence, 1 jour minimum | Quiconque a prévenu les distributions Linux |
| CERT/CC | **45 jours** à compter du signalement, « qu'il existe ou non des correctifs ou des contournements » | Quiconque a signalé via le CERT/CC |
| Google Project Zero | **90 jours**, détails 30 jours après le correctif ; **7 jours** si la faille est activement exploitée | Tout éditeur auquel Project Zero adresse un signalement |
| HackerOne, par défaut | **30 jours** sauf objection ; garde-fou de **180 jours** côté chercheur | Les programmes hébergés sur HackerOne |
| Pré-notification OpenSSL | **2 semaines** aux distributeurs d'OS et aux projets dérivés ; **1 semaine** avant l'annonce publique | Les consommateurs d'OpenSSL en aval |

Une règle se dégage de ce tableau, et c'est la règle opérante de toute divulgation multipartite :

**L'embargo qui fait foi est le compteur le plus court auquel un participant est déjà tenu.** Si quelqu'un, dans le dossier, est passé par `distros`, vous disposez de 14 jours au maximum, quoi que dise votre propre politique. Votre préférence pour 90 jours n'a plus aucune portée dès l'instant où le plafond de 14 jours de quelqu'un d'autre s'est déclenché.

Le CERT Guide explique la raison d'être de ces plafonds : **« Plus il y a de parties impliquées dans un dossier, et plus la période d'embargo se prolonge, plus une fuite devient probable. »** Un embargo plus long n'est pas plus sûr. Il est seulement plus long.

## Un CVE ou cinq ? La décision d'identifiant que personne n'explique

Les deux conventions existent, le choix se fait dossier par dossier, et il relève de la coordination, pas de l'intendance administrative. C'est la partie la moins documentée de la divulgation multipartite, et se tromper crée du travail pour tous ceux qui se trouvent en aval de vous.

**Un CVE par faille de protocole, et de nombreux éditeurs rattachés.** Les auteurs de KRACK ont exposé la logique sans détour : « Chaque identifiant CVE représente une instanciation précise d'une attaque par réinstallation de clé. Autrement dit, chaque identifiant CVE décrit une vulnérabilité de protocole donnée, et **de nombreux éditeurs sont donc concernés par chacun d'eux**. » Les dix CVE décrivaient la faille, pas les produits.

**Un CVE par produit affecté, et la pagaille des doublons qui s'ensuit.** Dans l'affaire libwebp, un second identifiant a été créé pour la bibliothèque alors qu'il en existait déjà un pour la faille du navigateur en aval. CVE-2023-5129 est aujourd'hui officiellement mort : **« Cet identifiant CVE a été rejeté ou retiré par sa CVE Numbering Authority. Doublon de CVE-2023-4863. »** Rien n'a changé dans la vulnérabilité elle-même. C'est l'identifiant qui a changé, et il a fallu réorienter chaque avis de sécurité, chaque règle de scanner, chaque entrée de SBOM et chaque référence de ticket qui y renvoyait.

**Une approche mixte, quand le protocole et les implémentations sont fautifs l'un comme les autres.** Terrapin a donné lieu à CVE-2023-48795 pour la faille générale de protocole, à CVE-2023-46445 et CVE-2023-46446 pour des attaques propres à AsyncSSH, et à CVE-2024-41909 pour Apache MINA SSHD.

Quand l'attribution n'incombe à personne de façon évidente, la politique du CERT/CC est d'attribuer lui-même le CVE dans les dossiers multi-éditeurs où la compétence n'est pas établie : la coordination prime sur l'attente d'un arbitrage entre CNA.

La conséquence, pour un éditeur en aval, est limitée et précise : votre registre doit conserver une *référence* à un identifiant amont susceptible d'être remplacé plus tard, et non une chaîne figée collée dans un champ de description.

## Comment retrouver les quatre autres éditeurs

Trois mécanismes, par effort croissant.

1. **`security.txt` (RFC 9116).** Un fichier texte à l'adresse `https://example.com/.well-known/security.txt`, avec les champs obligatoires `Contact` et `Expires`, plus les champs facultatifs `Acknowledgments`, `Canonical`, `Encryption`, `Hiring`, `Policy` et `Preferred-Languages`. Publié comme RFC informationnelle en avril 2022, il existe pour qu'une personne ayant découvert une faille trouve votre canal de signalement sans avoir à deviner. C'est aussi le moyen le moins coûteux de vous rendre repérable *par un coordinateur en amont*, un sens de circulation que tout le monde oublie. [Mettre en place un VDP](/blog/how-to-set-up-vulnerability-disclosure-program) couvre le reste de ce travail de fond.
2. **Un coordinateur.** Le CERT/CC exploite VINCE (Vulnerability Information and Coordination Environment), opéré par le Software Engineering Institute de Carnegie Mellon et financé par la CISA, où les éditeurs enregistrent leurs contacts et coordonnent les dossiers. C'est la réponse officielle à « je ne sais pas qui d'autre distribue ce composant ».
3. **La prise de contact manuelle, par lots.** C'est ce qui se passe en pratique. Les auteurs de Terrapin ont contacté environ 29 implémentations SSH en deux tours et prévenu le CERT-Bund.

Calibrez vos attentes sur un chiffre réel. La note KRACK du CERT, VU#228519, comporte un tableau d'éditeurs dont le pied de page indique **« Voir les 183 éditeurs »**, répartis entre Affected, Not Affected et un vaste bloc Unknown dont aucune déclaration n'est jamais parvenue. Dans un vrai dossier multipartite, une part importante des éditeurs concernés ne répond jamais.

## Terrapin : à quoi ressemble une divulgation multipartite bien menée

Même configuration que le cas WebKit, exécution opposée. Une faille de protocole touchant environ 29 implémentations SSH indépendantes, coordonnée de manière délibérée :

- **17 octobre 2023** : premier contact avec OpenSSH et l'auteur d'AsyncSSH
- **17 novembre 2023** : premier tour de notification, 17 implémentations, plus le CERT-Bund
- **21 novembre 2023** : deuxième tour, 12 de plus
- **11 décembre 2023** : notification à `distros`
- **18 décembre 2023** : divulgation publique

**62 jours, quatre CVE, une seule date.** Regardez les deux dernières lignes : `distros` a été saisi exactement 7 jours avant la publication, dans la fenêtre *recommandée* de cette liste plutôt qu'au ras de son plafond de 14 jours. Voilà à quoi ressemble un calendrier calculé de bout en bout.

L'éventail des embargos multipartites réels est très étendu. Cloudflare, Google et AWS ont mené HTTP/2 Rapid Reset en 46 jours environ, sous exploitation active, de la détection le 25 août 2023 à la publication de Google le 10 octobre 2023. KRACK a duré environ 94 jours. Meltdown et Spectre, 216 : Project Zero a signalé la faille à Intel, AMD et ARM le 1ᵉʳ juin 2017 et publié le 3 janvier 2018.

De 46 à 216 jours. Aucun SLA ne couvre un tel écart, et c'est bien là le fond du problème. **Dans un dossier multipartite, la date est une donnée d'entrée, pas le résultat de votre politique.**

## Le problème du compteur : pourquoi votre SLA affiche vert alors que vous êtes en retard

Le mode de défaillance qui suit n'a jamais été écrit noir sur blanc, et il relève de l'arithmétique, pas de la négligence.

Les compteurs SLA à un seul acteur sont ancrés à l'instant où le rapport *vous* est parvenu. Le module `Csirt::Report::SlaTrackable` de Kit calcule toutes les échéances à partir de `submitted_at`, ce qui est le choix correct et conventionnel. Les valeurs par défaut de Kit le sont tout autant : 72 heures pour l'accusé de réception, puis des objectifs de résolution de 24 heures en super critique, 72 en critique, 168 en élevée, 336 en moyenne et 720 pour les niveaux faible et informatif.

Mettez maintenant ces valeurs par défaut en regard des plafonds d'embargo.

**336 heures font exactement 14 jours**, soit précisément l'embargo maximal accepté par la liste `distros`. **720 heures font 30 jours**, plus du double de tout embargo que les distributions Linux accepteront de respecter.

Une faille de dépendance partagée classée en sévérité moyenne ou inférieure sera donc, par défaut, encore confortablement dans les clous de son propre SLA le matin où l'embargo expire et où la faille devient publique. Le tableau de bord est au vert. Le rapport est dans les temps. Et le correctif n'est pas livré, l'avis de sécurité n'est pas rédigé, et vos utilisateurs l'apprennent par l'article de quelqu'un d'autre.

Deux choses sont cassées en même temps. L'ancrage est faux, parce que le compteur qui fait foi a démarré plus tôt, le jour où une personne a signalé la faille à un autre éditeur. Et la date de fin est fausse, parce qu'elle a été fixée par une négociation entre des parties que vous n'avez peut-être jamais rencontrées.

Cette défaillance diffère des [problèmes d'équité des SLA](/blog/bug-bounty-payout-disputes-resolution-sla-fairness) que l'on rencontre dans les programmes bilatéraux. Ceux-là portent sur le respect du compteur. Ici, le compteur est parfaitement respecté et le résultat arrive quand même trop tard.

## Ce dont votre registre a réellement besoin : une fiche de divulgation liée

Le correctif tient en une fiche, et la plupart des outils de VDP disposent déjà de toutes les briques nécessaires pour la construire.

Une **divulgation liée** est un lien à part entière entre un rapport de votre registre et une divulgation externe menée ailleurs. Elle porte :

- **Un rôle.** `upstream`, `downstream` ou `peer`. C'est le champ qui transforme un « rapport inclassable » en « dossier dans lequel vous occupez une position définie ».
- **Une référence externe.** Le CVE amont ou l'URL de l'avis de sécurité, ainsi qu'une référence de dossier chez le coordinateur : un numéro VU du CERT/CC, un fil `distros`.
- **Deux dates, pas une.** `upstream_reported_at`, le véritable départ du compteur, et `embargo_at`, la date publique convenue.
- **Une règle.** La première échéance qui expire fait foi. Cette seule ligne constitue tout le correctif.

Tout le reste relève de la réutilisation. Les niveaux de SLA de Kit parlent déjà le bon vocabulaire (`breached`, `at_risk`, `on_track`, `no_sla`) ; il leur manque un second prédicat à évaluer, pour qu'un rapport affiche *« accusé de réception : dans les temps, embargo : 3 jours »* au lieu d'une simple pastille verte. `Csirt::TrackerIssue` entretient déjà des liens gérés et synchronisés en statut vers des systèmes externes, ce qui correspond exactement au besoin d'un avis de sécurité amont susceptible d'être rejeté plus tard, comme l'a été CVE-2023-5129. Et `Csirt::Report::Shareable` génère déjà des partages externes caviardés, à durée limitée et protégés par adresse e-mail. Le commentaire de son propre code vend la mèche : *« le rejet (“hors périmètre, c'est la faille de l'éditeur amont”) correspond exactement au moment où une équipe transmet la copie caviardée à cet éditeur. »* Le canal vers les éditeurs pairs existe déjà. Il n'est simplement pas modélisé comme de la coordination : la liste des destinataires reste un transfert non suivi au lieu de faire partie du dossier.

L'étape de triage par IA est l'endroit naturel pour cela. Quand un outil de premier passage signale « on dirait une faille de dépendance, pas la nôtre », la bonne issue est un aiguillage, pas une clôture.

Cela prolonge l'argument développé dans [le problème du correctif silencieux](/blog/silent-patch-broken-vulnerability-disclosure-cve) : la divulgation est une étape suivie, pas un état terminal. Le cas multipartite y ajoute une chose. Cette étape compte parfois quatre autres participants, et votre registre doit connaître leurs noms.

<div class="blog-inline-cta">
  <p><strong>Vous gérez un VDP avec un vrai registre ?</strong> Le module CSIRT de Kit suit au même endroit les rapports, les niveaux de SLA, les partages caviardés entre pairs et les liens vers les outils de suivi externes : le dossier de coordination vit à côté du rapport, et non dans votre boîte de réception.</p>
  <p><a href="/users/sign_up">Démarrez votre essai gratuit</a></p>
</div>

## Le régulateur, lui, n'attend pas la fin de l'embargo

En vertu du règlement européen sur la cyberrésilience (Cyber Resilience Act), à compter du **11 septembre 2026**, les fabricants devront signaler les vulnérabilités activement exploitées via la plateforme de signalement unique de l'ENISA : une alerte précoce sous **24 heures**, une notification complète sous **72 heures** et un rapport final dans les **14 jours** suivant une mesure corrective.

Ce compteur est indexé sur *votre* prise de connaissance, pas sur l'embargo multipartite. Apprenez au troisième jour d'un embargo sectoriel de 90 jours que la faille partagée est activement exploitée, et votre obligation des 24 heures démarre aussitôt. Aucun accord d'embargo ne vous en dispense, et aucun autre participant ne peut y renoncer en votre nom. Le [guide de Kit consacré au règlement européen sur la cyberrésilience](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) traite l'obligation en détail ; l'objet ici est simplement de nommer la collision. Une fiche de coordination qui porte les deux dates est aussi la pièce qui prouve que vous avez respecté le compteur du régulateur alors que l'embargo sectoriel courait encore.

## Le mode opératoire d'un rapport qui n'est pas que le vôtre

Quand un rapport indique que la faille est partagée, déroulez cette liste avant de toucher au moindre motif de rejet.

1. **Ne le clôturez pas.** Ni en `out_of_scope`, ni en `duplicate`. Marquez-le comme lié et laissez-le ouvert.
2. **Posez trois questions à l'auteur du signalement.** Qui d'autre avez-vous prévenu, quand l'avez-vous fait, et le sujet est-il passé par une liste de diffusion ou un coordinateur ?
3. **Identifiez le compteur le plus court déjà en cours.** Si l'une des réponses est `distros`, votre plafond est de 14 jours. Si c'est le CERT/CC, 45. Notez la date.
4. **Décidez si vous pilotez ou si vous suivez.** Si l'éditeur amont coordonne, vous êtes en aval et vous vous alignez sur sa date. Si personne ne coordonne, faites remonter le dossier à un coordinateur plutôt que d'en improviser un.
5. **Faites acter tôt la structure des identifiants.** Un CVE pour la faille, ou un par produit ? Posez la question avant la rédaction des avis de sécurité, pas après.
6. **Publiez un `security.txt`.** Pour que le prochain coordinateur amont vous trouve sans passer par une recherche LinkedIn.
7. **Consignez les deux dates sur le rapport.** La date de réception pour votre SLA, la date d'embargo pour la réalité. Affichez les deux.
8. **Considérez le compteur du CRA comme indépendant.** Si l'exploitation est confirmée, l'obligation des 24 heures court quel que soit l'embargo.
9. **Gardez la trace du partage entre pairs.** Si vous transmettez une copie caviardée à un autre éditeur, ce destinataire fait partie du dossier, et non d'une note de bas de page perdue dans les messages envoyés.
10. **Attendez-vous au silence.** Une bonne part des éditeurs contactés ne répond jamais. Le CERT Guide conseille de présumer la bonne foi et de continuer à tenter de rétablir le contact. Devenir l'éditeur qui ne répond plus, c'est finir cité dans la publication de divulgation d'un autre.

Rien de tout cela n'exige un PSIRT de douze personnes. Il faut un registre capable d'exprimer une phrase que votre outillage actuel ne sait probablement pas dire : **ce rapport est l'un des cinq.** Ajoutez le lien, ajoutez le compteur d'embargo, appliquez la règle du compteur le plus court, et le rapport cesse d'être une faille que vous n'arrivez pas à classer pour devenir un dossier que vous pouvez mener.