Un fallo, cinco proveedores: divulgación de vulnerabilidades entre varias partes

Una vulnerabilidad que afecta a la vez a varios proveedores independientes —normalmente a través de un motor, una biblioteca o un protocolo compartidos— no se puede tramitar con un programa de divulgación de vulnerabilidades (VDP) corriente. La divulgación coordinada de vulnerabilidades entre varias partes exige una fecha de embargo negociada, una estructura de CVE acordada y, a menudo, un coordinador neutral, porque ningún proveedor controla el calendario por sí solo. Casi todos los VDP que hoy están en producción se construyeron para el caso contrario: una empresa, un informe, un reloj.

Esto es lo que pasa cuando ese supuesto falla, qué reloj manda de verdad y por qué tu panel de SLA puede aparecer en verde la mañana en que un fallo compartido se hace público.

Un fallo de WebKit, todos los navegadores con proxy de iOS

El 4 de agosto de 2026, los investigadores de Mysk publicaron tres comportamientos de WebKit que esquivan el proxy configurado en el navegador y filtran la dirección IP real del dispositivo o sus resolutores DNS. Los mecanismos son funciones corrientes de la plataforma web: las pistas <link rel="dns-prefetch">, donde «una página puede incrustar en esas etiquetas nombres de host únicos por visitante y luego ver cómo las consultas llegan a su propio servidor DNS autoritativo desde la red real del visitante, y no desde la del proxy»; las Related Origin Requests de WebAuthn, en las que el servicio de credenciales del sistema operativo descarga https://<rpId>/.well-known/webauthn fuera del proxy; y WebTransport, que abre conexiones QUIC de HTTP/3 directamente desde el dispositivo.

Lo que convierte esto en un caso de referencia no es el detalle técnico, sino la política de plataforma. Como lo expresa el análisis: «Dado que la política de la App Store de Apple obliga a todos los navegadores de iOS a usar WebKit, cualquier navegador de iOS que dependa de esta API para el proxy está afectado, incluidos todos los navegadores Tor de iOS y Psylo».

Una sola causa raíz en una sola API de configuración de proxy golpea al mismo tiempo al iCloud Private Relay de la propia Apple y a todos los navegadores de privacidad ajenos que se distribuyen en iOS. Apple es el proveedor del motor de origen y, a la vez, responsable de un producto que lo consume, así que ni siquiera la respuesta refleja de «escala al proveedor de origen y sigue con lo tuyo» aclara quién lleva la batuta.

Fíjate en lo que la divulgación no contiene. Ningún CVE. Ninguna fecha de embargo compartida. Contacto con dos de las partes afectadas: «Nos hemos puesto en contacto con el Tor Project y con los desarrolladores de Onion Browser en iOS por estos problemas».

No es una crítica a los investigadores. Es el retrato del resultado por defecto cuando nadie se encarga de la coordinación. Cada proveedor afectado se entera en un momento distinto, por una vía distinta, y algunos se enteran leyendo la entrada del blog. Estar en ese último lugar sale caro.

¿Qué es la divulgación coordinada de vulnerabilidades entre varias partes?

La divulgación coordinada de vulnerabilidades entre varias partes (MPCVD) es el proceso que se aplica a una vulnerabilidad que afecta a la vez a varios proveedores independientes, normalmente a través de un componente, un motor o un protocolo compartidos. A diferencia de un VDP de un solo proveedor, exige una fecha de embargo negociada, una estructura de CVE acordada y un coordinador, porque ninguna de las partes controla el calendario por sí sola.

FIRST publica el documento de referencia, las Multi-Party Vulnerability Coordination and Disclosure guidelines (v1.1). Se apoya en cuatro pilares (procesos y relaciones sólidos, comunicación clara, construcción de confianza y reducción de la exposición) y define cinco roles: quien descubre (Finder), el proveedor (Vendor), el coordinador (Coordinator), quien defiende (Defender) y los usuarios o implantadores (Users/Deployers). La mayoría de los VDP solo tienen vocabulario para los dos primeros.

Por qué este es ya el caso normal y no la rareza

La mayoría de las vulnerabilidades de un producto moderno viven en código que el proveedor no escribió y que no puede corregir por su cuenta. El informe OSSRA 2026 de Black Duck, basado en «el análisis de 947 bases de código comerciales de 17 sectores», concluye lo siguiente:

• El 87 % de las bases de código auditadas contenía al menos una vulnerabilidad
• El 78 % contenía vulnerabilidades de alto riesgo, incluido un 44 % con problemas de riesgo crítico
• El número medio de vulnerabilidades de código abierto por base de código «se ha más que duplicado: ha subido un 107 % hasta una media de 581 vulnerabilidades»
• El 93 % incluye componentes sin actividad de desarrollo en los dos últimos años

La CERT Guide to Coordinated Vulnerability Disclosure nombra la causa sin rodeos: «Hoy muchos productos no los desarrolla una sola organización. Se ensamblan a partir de componentes obtenidos de otras organizaciones».

Sigue esas cifras hasta su conclusión lógica. Si la mayor parte de tu superficie de ataque está ensamblada y no escrita por ti, entonces la mayoría de tus vulnerabilidades son, por estructura, de varias partes. El informe de un solo proveedor es el caso especial, y tus herramientas se construyeron justo para ese.

Las cuatro salidas que ofrece tu cola de triaje, y por qué tres son erróneas

Abre cualquier cola de recepción de un VDP y mira los motivos de desestimación. El módulo Csirt de Kit trae el conjunto habitual: out_of_scope, duplicate, informational, not_reproducible, spam, other y ai_slop. Todos los VDP tienen alguna versión de esta lista y, ante un informe sobre una dependencia compartida, las dos salidas más tentadoras son justo las dos equivocadas.

out_of_scope es correcto para «ese activo no es nuestro». Es erróneo para «ese producto es nuestro, aunque el código sea de otro». Tus usuarios quedan expuestos igualmente, y cerrar el informe borra tu obligación sin tocar la exposición. Además se lee como un gesto hostil: el pilar de confianza de FIRST advierte de que la escalada legal produce «un efecto disuasorio sobre la investigación de seguridad que se quiere fomentar», y cerrar en silencio un informe sobre una dependencia compartida está en ese mismo espectro. Más sobre esa dinámica en puerto seguro y amenazas legales.

duplicate está semánticamente del revés. Hoy significa «el mismo fallo, ya nos lo habían comunicado» y cierra el informe. Un caso de dependencia compartida afirma lo contrario: la misma causa raíz, pero en el producto de otro. Eso obliga a mantener el informe abierto, con un segundo responsable y un segundo calendario.

informational lo entierra. Y not_reproducible es el que te pilla desprevenido, porque quien está al final de la cadena a menudo no puede reproducir de verdad un fallo de origen de forma aislada.

La salida que no existe en ninguna taxonomía de recepción convencional es la quinta: enlazado (linked). Misma causa raíz, otro proveedor, calendario coordinado y, aun así, seguimos siendo nosotros quienes respondemos. Esto pesa cada vez más, porque la investigación asistida por IA mete más hallazgos a nivel de dependencia en las colas de recepción, un cambio que analizamos en la IA y la economía del triaje en un VDP.

¿Quién fija la fecha de embargo? Nadie: aprende dónde están los techos

No hay ninguna autoridad que fije las fechas de embargo. FIRST es deliberadamente poco prescriptivo: «A falta de pruebas claras de una divulgación pública previa (incluida la explotación activa), las partes interesadas deberían conceder a los proveedores un periodo de embargo razonable para investigar y desarrollar correcciones». Cuando intervienen varios coordinadores, «debe elegirse a uno de ellos como responsable principal».

Así que la fecha se negocia. Lo que hace manejable esa negociación es saber qué techos rígidos vinculan ya a los demás participantes.

De esa tabla sale una sola regla, y es la regla operativa de la divulgación entre varias partes:

El embargo que manda es el reloj más corto que ya vincula a alguno de los participantes. Si alguien del caso ha acudido a distros, tienes 14 días como mucho, diga lo que diga tu propia política. Tu preferencia de 90 días es irrelevante en cuanto empieza a correr el techo de 14 días de otro.

La CERT Guide explica por qué existen esos techos: «Cuantas más partes intervienen en un caso y más dura el periodo de embargo, más probable es que haya una filtración». Los embargos largos no son más seguros. Solo son más largos.

¿Un CVE o cinco? La decisión sobre el identificador que nadie explica

Existen las dos convenciones, la elección se toma caso por caso y es una decisión de coordinación, no un trámite administrativo. Es la parte peor documentada de la divulgación entre varias partes, y equivocarse genera trabajo a todos los que dependen de ti.

Un CVE por fallo de protocolo, con muchos proveedores dentro. Los autores de KRACK lo dejaron claro: «Cada identificador CVE representa una instancia concreta de un ataque de reinstalación de clave. Esto significa que cada ID de CVE describe una vulnerabilidad de protocolo concreta y, por tanto, cada ID de CVE afecta a muchos proveedores». Diez CVE describían el fallo, no los productos.

Un CVE por producto afectado, con el lío de duplicados que viene después. En el caso de libwebp se acuñó un segundo identificador para la biblioteca cuando ya existía uno para el fallo del navegador que la consumía. Hoy el CVE-2023-5129 está formalmente muerto: «Este ID de CVE ha sido rechazado o retirado por su CVE Numbering Authority. Duplicado de CVE-2023-4863». La vulnerabilidad no cambió en nada. Lo que cambió fue el identificador, y hubo que reapuntar todos los avisos, reglas de escáner, entradas de SBOM y referencias de tickets que colgaban de él.

Mixto, cuando fallan tanto el protocolo como las implementaciones. Terrapin salió con el CVE-2023-48795 para el fallo general del protocolo, junto con el CVE-2023-46445 y el CVE-2023-46446 para ataques específicos de AsyncSSH, más el CVE-2024-41909 para Apache MINA SSHD.

Cuando no hay un responsable evidente de la asignación, la política de CERT/CC es asignar el CVE por su cuenta en casos multiproveedor donde la autoridad no está clara: la coordinación pesa más que esperar a que se resuelva quién es la CNA.

La consecuencia para quien está al final de la cadena es pequeña y muy concreta: tu registro debe guardar una referencia a un identificador de origen que puede quedar sustituido más adelante, no una cadena fija pegada en un campo de descripción.

Cómo encontrar a los otros cuatro proveedores

Tres mecanismos, de menor a mayor esfuerzo.

1. security.txt (RFC 9116). Un archivo de texto plano en https://example.com/.well-known/security.txt con los campos obligatorios Contact y Expires, más los opcionales Acknowledgments, Canonical, Encryption, Hiring, Policy y Preferred-Languages. Se publicó como RFC informativo en abril de 2022 y existe para que quien descubra un fallo encuentre tu canal para informar sin tener que adivinar. También es la forma más barata de que te localice un coordinador de origen, que es la dirección que todo el mundo olvida. Montar un VDP cubre el resto de esos cimientos.
2. Un coordinador. CERT/CC gestiona VINCE (Vulnerability Information and Coordination Environment), operado por el Software Engineering Institute de la CMU y patrocinado por CISA, donde los proveedores registran contactos y coordinan casos. Es la respuesta oficial a «no sé quién más distribuye esto».
3. Contacto manual, por tandas. Que es lo que suele pasar. Los autores de Terrapin contactaron con unas 29 implementaciones de SSH en dos rondas y avisaron a CERT-Bund.

Ajusta tus expectativas con una cifra real. La nota de CERT sobre KRACK, la VU#228519, incluye una tabla de proveedores cuyo pie dice «Ver los 183 proveedores», repartidos entre Afectado, No afectado y un bloque enorme de Desconocido del que nunca llegó declaración alguna. En un caso real entre varias partes, una porción considerable de los proveedores afectados no responde jamás.

Terrapin: así es una divulgación entre varias partes bien llevada

La misma forma que el caso de WebKit, con la ejecución contraria. Un fallo de protocolo que afectaba a unas 29 implementaciones independientes de SSH, coordinado a conciencia:

• 2023-10-17: primer contacto con OpenSSH y con el autor de AsyncSSH
• 2023-11-17: primera ronda de proveedores, 17 implementaciones, más CERT-Bund
• 2023-11-21: segunda ronda, 12 más
• 2023-12-11: aviso a distros
• 2023-12-18: divulgación pública

62 días, cuatro CVE, una sola fecha. Fíjate en las dos últimas entradas: se entró en distros exactamente 7 días antes de la publicación, dentro de la ventana preferida de esa lista y no pegado a su techo de 14 días. Así se nota que alguien ha hecho las cuentas a propósito.

El rango de los embargos reales entre varias partes es amplio. Cloudflare, Google y AWS resolvieron HTTP/2 Rapid Reset en unos 46 días, y bajo explotación activa: desde la detección el 25 de agosto de 2023 hasta la entrada de divulgación de Google el 10 de octubre de 2023. KRACK duró unos 94 días. Meltdown y Spectre, 216: Project Zero informó a Intel, AMD y ARM el 1 de junio de 2017 y publicó el 3 de enero de 2018.

De 46 a 216 días. Ningún SLA cubre esa horquilla, y ahí está la clave. En un caso entre varias partes, la fecha es un dato de entrada, no el resultado de tu política.

El problema del reloj: por qué tu SLA marca verde cuando ya vas tarde

Este es el modo de fallo que nadie ha puesto por escrito, y es cuestión de aritmética, no de negligencia.

Los relojes de SLA de una sola parte se anclan al momento en que el informe llegó a ti. En Kit, Csirt::Report::SlaTrackable calcula todos los plazos a partir de submitted_at, que es el diseño correcto y habitual. Los valores por defecto de Kit son igual de convencionales: 72 horas para acusar recibo y, después, objetivos de resolución de 24 horas para súper crítico, 72 para crítico, 168 para alto, 336 para medio y 720 para bajo o informativo.

Ahora pon esos valores por defecto al lado de los techos de embargo.

336 horas son exactamente 14 días, justo el embargo máximo aceptable de la lista distros. 720 horas son 30 días, más del doble de cualquier embargo que las distribuciones de Linux vayan a respetar.

Un fallo en una dependencia compartida clasificado como medio o inferior seguirá, por defecto, holgadamente dentro de su propio SLA la mañana en que expira el embargo y el fallo se hace público. El panel marca verde. El informe va en plazo. Y la corrección no está publicada, el aviso no está redactado y tus usuarios se enteran por la entrada de blog de otro.

Hay dos cosas rotas a la vez. El ancla está mal, porque el reloj que manda arrancó antes, cuando alguien informó a otro proveedor. Y la fecha final está mal, porque la fijó una negociación entre partes a las que quizá ni conozcas.

Es un fallo distinto de los problemas de equidad en los SLA que surgen en los programas bilaterales. Aquellos son disputas sobre si se respetó el reloj. Este es un reloj respetado a la perfección que aun así acaba llegando tarde.

Lo que de verdad necesita tu registro: una divulgación enlazada

La solución es un solo registro, y la mayoría de las herramientas de VDP ya tienen todos los elementos básicos para construirlo.

Una divulgación enlazada es una conexión de primer nivel entre un informe de tu registro y una divulgación externa que ocurre en otro sitio. Lleva consigo:

• Un rol. upstream, downstream o peer. Es el campo que convierte un «informe inclasificable» en un «caso en el que ocupas una posición definida».
• Una referencia externa. El CVE de origen o la URL del aviso, más una referencia del caso ante el coordinador: un número VU de CERT/CC o un hilo de distros.
• Dos fechas, no una. upstream_reported_at, el arranque real del reloj, y embargo_at, la fecha pública acordada.
• Una regla. Manda la que expire primero. Esa única línea es toda la solución.

Todo lo demás es reutilización. Los niveles de SLA de Kit ya hablan el vocabulario correcto (breached, at_risk, on_track, no_sla); solo les falta un segundo predicado que evaluar, para que un informe diga «acuse de recibo: en plazo; embargo: 3 días» en lugar de una simple marca verde. Csirt::TrackerIssue ya mantiene vínculos gestionados y sincronizados por estado con sistemas externos, que es exactamente lo que necesita un aviso de origen cuando ese aviso puede quedar rechazado más adelante, como le pasó al CVE-2023-5129. Y Csirt::Report::Shareable ya genera enlaces externos redactados, con caducidad y acceso restringido por correo. Su propio comentario en el código lo delata: «desestimar (“fuera de alcance, el fallo es del proveedor de origen”) es justo el momento en que un equipo reenvía la copia redactada a ese proveedor». El canal hacia los proveedores homólogos ya está construido. Simplemente no está modelado como coordinación, así que la lista de destinatarios se queda en un reenvío sin rastro en vez de formar parte del registro del caso.

El paso de triaje con IA es donde debería aterrizar todo esto. Cuando una herramienta de primera pasada marca «esto parece un fallo de una dependencia, no nuestro», el resultado correcto es una derivación, no un cierre.

Eso amplía el argumento de el problema del parche silencioso: la divulgación es una etapa con seguimiento, no un estado final. El caso de varias partes añade una cosa. Esa etapa tiene a veces otros cuatro participantes, y tu registro tiene que saber cómo se llaman.

El regulador no espera al embargo

Según la Ley de Ciberresiliencia de la UE, a partir del 11 de septiembre de 2026 los fabricantes tendrán que comunicar las vulnerabilidades explotadas activamente a través de la plataforma única de notificación de ENISA: una alerta temprana en 24 horas, la notificación completa en 72 horas y un informe final en los 14 días siguientes a una medida correctora.

Ese reloj se ancla a tu conocimiento del problema, no al embargo entre varias partes. Si en el día 3 de un embargo sectorial de 90 días te enteras de que el fallo compartido se está explotando, tu obligación de 24 horas empieza en ese mismo instante. Nada en un acuerdo de embargo la excusa, y ningún otro participante puede renunciar a ella en tu nombre. La guía de Kit sobre la Ley de Ciberresiliencia de la UE cubre la obligación al completo; aquí solo toca señalar el choque. Un registro de coordinación que guarde las dos fechas es además el documento que demuestra que cumpliste el plazo del regulador mientras el embargo del sector seguía vigente.

El manual para un informe que no es solo tuyo

Cuando un informe dice que el fallo es compartido, recorre esta lista antes de tocar ningún motivo de desestimación.

1. No lo cierres. Ni out_of_scope ni duplicate. Márcalo como enlazado y mantenlo abierto.
2. Hazle tres preguntas a quien informa. ¿A quién más se lo has contado? ¿Cuándo lo hiciste? ¿Ha llegado esto a alguna lista de correo o a algún coordinador?
3. Localiza el reloj más corto que ya esté corriendo. Si alguna de las respuestas anteriores es distros, tu techo son 14 días. Si es CERT/CC, 45. Apunta la fecha.
4. Decide si lideras o sigues. Si el proveedor de origen está coordinando, tú vas detrás y sigues su fecha. Si no lo hace nadie, escala a un coordinador en lugar de inventarte uno tú.
5. Acuerda pronto la estructura de identificadores. ¿Un CVE para el fallo o uno por producto? Pregúntalo antes de que se redacten los avisos, no después.
6. Publica un security.txt. Para que el próximo coordinador de origen te encuentre sin tener que buscarte en LinkedIn.
7. Anota las dos fechas en el informe. La de entrada para tu SLA y la del embargo para la realidad. Muestra las dos.
8. Parte de que el reloj de la CRA es independiente. Si se confirma la explotación, la obligación de 24 horas corre al margen del embargo.
9. Deja rastro de lo que compartes con otros proveedores. Si reenvías una copia redactada a otro proveedor, ese destinatario forma parte del caso, no es una nota al pie en la carpeta de enviados de alguien.
10. Prepárate para el silencio. Buena parte de los proveedores contactados no responde nunca. El consejo de la CERT Guide es presumir buena fe y seguir intentando restablecer el contacto. Ser el proveedor que se queda callado es la forma de acabar mencionado en la entrada de divulgación de otro.

Nada de esto exige un PSIRT de doce personas. Exige un registro capaz de expresar una frase que tus herramientas actuales seguramente no pueden: este informe es uno de cinco. Añade el vínculo, añade el reloj del embargo, aplica la regla del reloj más corto y el informe deja de ser un fallo que no sabes clasificar para convertirse en un caso que sí puedes gestionar.