El problema del parche silencioso: por qué «parcheado» no es «divulgado»

Un parche silencioso es la corrección de un fallo de seguridad que se publica sin CVE, sin un aviso de seguridad publicado y sin avisar a quien lo comunicó. Para quien defiende un sistema, un parche silencioso es indistinguible de la ausencia total de corrección: no puedes citarlo, verificarlo ni saber si la versión que ejecutas lo incluye. Una divulgación completa no es solo código fusionado. Es una compilación parcheada con un número de versión concreto, un identificador CVE, un aviso de seguridad publicado, una notificación a quien informó y un reconocimiento público. Sáltate cualquiera de esos pasos y «parcheado» pasa a ser una afirmación privada, no un resultado de seguridad.

La mayoría de los programas de divulgación de vulnerabilidades (VDP) tratan el pull request fusionado como la línea de meta. Es el punto intermedio. La mitad de informar y recompensar —recepción, triaje, recompensa— acapara toda la atención y todas las herramientas. La mitad de corregir y divulgar —la parte que empieza después de arreglar el código— es donde fracasan en silencio hasta los programas más diligentes. Esta es esa historia, contada a través del ejemplo reciente más claro de cómo se tuerce.

La corrección de Cursor que nadie pudo verificar

En julio de 2026, la cobertura mediática de una vulnerabilidad de Cursor se dividió en torno a una pregunta que jamás debería ser ambigua: ¿estaba parcheada o no?

Esto es lo que pasó. El 15 de diciembre de 2025, la empresa de seguridad de IA Mindgard comunicó un fallo de ejecución de código en Windows en el IDE de Cursor a [email protected]. El mecanismo es desagradable por lo simple: un git.exe malicioso colocado en la raíz de un repositorio clonado se ejecuta automáticamente en cuanto se abre el proyecto. Cursor ejecuta git rev-parse --show-toplevel y, como el orden de búsqueda de Windows revisa el directorio de trabajo antes que las rutas del sistema, el binario del atacante se ejecuta en lugar del Git real, con los privilegios del desarrollador y sin ninguna advertencia. Mindgard confirmó que era vulnerable hasta Cursor 3.2.16, probado el 30 de abril de 2026.

Después, el informe se quedó en silencio. Según la cronología de Mindgard, las solicitudes de actualización de febrero, marzo y abril de 2026 quedaron sin respuesta. El 1 de junio de 2026, Mindgard avisó de que lo publicaría. Lo hizo el 14 de julio de 2026: un análisis técnico completo, 213 días después del informe inicial.

Solo entonces un portavoz de Cursor declaró a Dark Reading que la empresa había «abordado el problema el 13 de julio de 2026» y que se pondría en contacto con Mindgard. Pero esa supuesta corrección no citaba ninguna versión parcheada, no incluía ningún aviso de seguridad publicado y no llevaba asociado ningún CVE. The Hacker News revisó los avisos de seguridad publicados por Cursor y no encontró ninguna entrada sobre el problema a fecha de 15 de julio. Cursor 3.11 se había publicado el 10 de julio, antes de la supuesta corrección del 13 de julio, así que la última compilación pública a la que se podía señalar no la incluía.

Por eso, medios serios describieron el fallo como aún sin parchear incluso después de que el proveedor dijera que estaba corregido. Ambas cosas eran «ciertas» porque la corrección solo existía como una afirmación imposible de verificar. Un parche que nadie puede citar, confirmar ni atribuir a una versión no es, en la práctica, un parche. Esa contradicción encierra toda la lección.

¿Qué es un parche silencioso?

Un parche silencioso es una corrección que cierra un fallo relevante para la seguridad, pero que nunca se presenta como tal: sin CVE, a menudo sin aviso de seguridad y a veces enterrado dentro de una versión sin relación aparente. El código cambia; al mundo nunca se le cuenta qué cambió ni por qué. Una divulgación completa, en cambio, tiene cinco componentes:

1. Una compilación parcheada con un número de versión concreto. «Corregido en la 3.12.0», no solo «corregido».
2. Un identificador CVE, para que el fallo tenga un nombre estable y localizable en búsquedas.
3. Un aviso de seguridad publicado que describa la vulnerabilidad, las versiones afectadas y la mitigación.
4. Una notificación a quien informó de que la corrección ya se ha publicado.
5. Reconocimiento público al investigador que lo encontró.

Sáltate cualquiera de ellos y los usuarios no podrán responder a la única pregunta que les importa: ¿estoy a salvo y en qué versión?

Por qué lo hacen los proveedores: motivos inocentes y motivos interesados

Los motivos cubren todo un abanico. En el extremo inocente: un mantenedor nunca se dio cuenta de que un fallo tenía una dimensión de seguridad, o un equipo diminuto no tiene ningún proceso para solicitar un CVE y redactar un aviso. En el extremo interesado: la resistencia a admitir públicamente que el fallo existía, el miedo a la imagen que da o la esperanza de que corregirlo en silencio haga desaparecer el problema.

La intención no cambia el resultado. Tanto si el silencio proviene de un mantenedor desbordado como de un equipo de comunicación nervioso, quien defiende el sistema aguas abajo recibe lo mismo: una corrección que no puede ver.

Por qué un parche silencioso ayuda a los atacantes, no a ti

Un parche silencioso no protege a los usuarios. Les entrega a los atacantes una ventaja sobre ellos. Esta es la parte contraintuitiva, y conviene decirla sin rodeos.

Como lo expresó Tod Beardsley, de Rapid7: «cuando parcheas en silencio, comunicas los detalles de la vulnerabilidad, en exclusiva, a atacantes criminales y expertos». Esta es la asimetría. Cuando una corrección aterriza en una base de código pública, los atacantes motivados comparan las compilaciones parcheada y sin parchear, reconstruyen el fallo a partir del cambio y lo convierten en un arma, a menudo en cuestión de días. Ese trabajo está perfectamente al alcance de cualquier adversario competente que lea el historial de commits con malas intenciones.

Quienes defienden los sistemas no hacen esto. No aplican ingeniería inversa a cada commit discreto de cada dependencia. Dependen de los avisos de seguridad para saber qué cambió y si les afecta. Así que un parche silencioso traza una línea nítida: el fallo se vuelve totalmente visible para la pequeña población dispuesta a buscarlo y permanece invisible para la gran población que habría parcheado si alguien se lo hubiera dicho. Las personas que actualizan a tiempo, que leen los avisos, que lo hacen todo bien, son justamente las que quedan expuestas, mientras que los atacantes son los «notificados».

El silencio no compra seguridad por oscuridad. Le compra al atacante una ventaja de salida.

La mitad del ciclo de vida que todo el mundo olvida

La mayoría de los equipos modelan el ciclo de vida de la divulgación así: informe → triaje → corrección. Al modelo completo se le sueldan tres pasos más al final: → CVE → aviso → notificación. Esa cola no es una cortesía. Las normas la codifican.

Las normas ISO/IEC 29147 (divulgación de vulnerabilidades) e ISO/IEC 30111 (gestión de vulnerabilidades) definen las obligaciones del proveedor, y un aviso de seguridad publicado es explícitamente una de ellas: una descripción de la vulnerabilidad, las versiones afectadas y la mitigación, idealmente en el formato legible por máquina CSAF 2.0 para que los escáneres y los equipos aguas abajo puedan consumirlo de forma automática. En la divulgación coordinada, el aviso se publica junto con la corrección o poco después. «Nunca» no es una opción que la norma contemple.

También hay relojes, y miden todo el camino hasta la divulgación pública, no solo la fusión del código:

Estos son los plazos de equidad aceptados por el sector. Medido con cualquiera de ellos, un informe acusado de recibo en diciembre y que en julio del año siguiente sigue sin aviso ni CVE no está «en curso». Va con retraso según todos los criterios publicados que existen.

Un CVE no es opcional, y los proveedores asignan los suyos

La excusa más habitual para un CVE ausente —que asignarlo es difícil o está restringido— no sobrevive al contacto con el funcionamiento real del sistema. Los identificadores CVE los asignan las autoridades de numeración de CVE (CNA), y muchos proveedores son su propia CNA. Cuando un proveedor no lo es, hay CNA de terceros, CERT y plataformas como HackerOne que pueden asignarlo en su nombre. Ser proveedor no es una barrera para obtener un CVE; a menudo es el camino más fácil hacia uno.

El propio historial de Cursor lo demuestra. Otras vulnerabilidades de Cursor de 2026 sí recibieron CVE y avisos: el RCE de elusión de confianza en MCP de Check Point, los RCE de inyección de prompts sin interacción «DuneSlide» de Cato Networks y los fallos de RCE a nivel de sistema operativo que cubrió SecurityWeek. La maquinaria existía y funcionaba. Simplemente, nunca se apuntó al informe del git.exe. Eso convierte el silencio en un vacío de proceso, no de capacidad: una decisión sobre qué informes reciben el tratamiento completo y cuáles se abandonan sin ruido.

«Parcheado pero no divulgado» es un incumplimiento de SLA, no un ticket cerrado

Este es el cambio de enfoque que transforma cómo gestionas un programa. La mayoría de los VDP tienen un estado terminal que significa «lo corregimos»: resolved, fix_verified, closed, paid. Un informe lo alcanza en el momento en que el parche se fusiona, y el ticket desaparece del tablero.

Ese estado es una mentira por omisión. Un informe que está corregido pero no tiene CVE, ni aviso, ni notificación al investigador no está terminado. Está en incumplimiento: del trabajo del investigador, del derecho de los usuarios a saber que están expuestos y de las normas que definen qué significa divulgar. El informe de Cursor estaba, según el propio relato del proveedor, «abordado» el 13 de julio. Pero también estaba, al mismo tiempo, en incumplimiento en los tres frentes. Ambas cosas eran ciertas porque «abordado» y «divulgado» son estados distintos, y solo uno de ellos se seguía.

El radio de impacto hace tangible el coste. Cursor tiene más de un millón de usuarios activos diarios, más de un millón de suscriptores de pago y más de 50 000 empresas que lo utilizan. Todos ellos pasaron el periodo de silencio sin poder responder a «¿estoy a salvo y en qué versión?», porque la respuesta nunca se publicó. Un parche silencioso escala su daño al tamaño de la base de usuarios a la que silencia.

Trata «parcheado pero no divulgado» igual que ya tratas un SLA de acuse de recibo incumplido: como un incumplimiento que se enciende en rojo, no como un ticket que se cierra sin ruido.

Una lista de comprobación de divulgación que puedes construir

El hueco que ninguna cobertura del incidente rellena es el operativo: ¿cómo consigues que un parche silencioso sea imposible de archivar como terminado en tu propio programa? Aquí tienes la lista de comprobación. Está pensada a propósito para construirse sobre los mismos raíles que ya siguen la recepción y el triaje.

1. Añade un estado terminal disclosed. Un informe no termina en fix_verified; tiene que pasar por disclosed. Haz que condicione el cierre igual que hoy lo hace resolved. Sin divulgación, no hay terminado.
2. Dispara una solicitud de CVE al llegar a fix_verified. La transición a «corregido» debería solicitar o abrir automáticamente una petición de CVE —a tu CNA de proveedor o a una CNA de terceros— y guardar el identificador asignado en el informe. Sin identificador, no hay cierre.
3. Adjunta una plantilla de aviso y un paso de publicación. Reutiliza la superficie de tu política de seguridad pública para publicar un aviso —versiones afectadas, mitigación y reconocimiento—, con formato CSAF para que las máquinas puedan leerlo. La plantilla convierte «redactar un aviso» de una página en blanco en un formulario.
4. Ponle un reloj de divulgación. Añade un SLA de divulgación —«aviso publicado en un plazo de N días desde fix_verified»— y hazlo pasar por la misma maquinaria de «en riesgo» e «incumplido» que ya usas para el acuse de recibo. Superar los N días se convierte en un incumplimiento en el tablero, con aviso a la guardia, no en un ticket cerrado e invisible.
5. Agrupa reconocimiento y notificación. Vincula el reconocimiento al investigador que figura en el aviso con tu salón de la fama y tu vía de reputación, y lanza un mensaje de «tu informe ya es público» a través del registro de comunicaciones con investigadores que ya tienes. El círculo se cierra con la persona que lo abrió.

Pon eso en marcha y un informe no podrá llegar físicamente a «terminado» mientras sea un parche silencioso. El tablero de estados obliga a divulgar igual que ya obliga a hacer triaje.

Cómo Kit mantiene los parches silenciosos fuera del tablero

La vertical de CSIRT de Kit ya ejecuta la mitad de informar y recompensar de un VDP sobre raíles de SLA, y ese es exactamente el sustrato que necesita la mitad de corregir y divulgar. Para dejar claro qué está disponible frente a lo que propone este artículo: los SLA de acuse de recibo y de resolución por nivel de severidad, la maquinaria de estados «en riesgo» e «incumplido», el escalado a la guardia, las transiciones de estado auditables, la sincronización de cumplimiento aguas abajo y la vía de reconocimiento del salón de la fama son todas funciones disponibles. Kit no tuvo nada que ver con el fallo de Cursor, y ninguna herramienta impide que un proveedor escriba código defectuoso.

Lo que la arquitectura de Kit sí aporta es el sustrato que hace que un parche silencioso sea, por su propia estructura, difícil de ocultar:

• Relojes de SLA con estados «en riesgo» e «incumplido», ya aplicados a los objetivos de acuse de recibo y de resolución por nivel de severidad. Un SLA de divulgación funciona sobre ese mismo mecanismo de reloj: «aviso publicado en un plazo de N días» recorre la ruta de incumplimiento idéntica.
• Escalado a la guardia, para que un reloj que se retrasa avise a una persona en lugar de envejecer en silencio: la diferencia entre el informe de Cursor, que languideció sin respuesta durante meses, y un incumplimiento que sale a la superficie.
• Transiciones de estado auditables por informe, de modo que añadir un estado disclosed que condicione el cierre es una extensión del ciclo de vida existente, no un sistema nuevo.
• Sincronización de cumplimiento aguas abajo y una vía de reconocimiento del salón de la fama, para que el reconocimiento al investigador que figura en un aviso y la notificación de «ya eres público» circulen por raíles que ya existen.

Un parche silencioso es, estructuralmente, un incumplimiento de SLA que ninguna herramienta actual mide. Kit ya mide los incumplimientos de SLA. Apuntar esa misma disciplina hacia la divulgación es la jugada, y le corresponde estar en el mismo tablero que sigue el acuse de recibo y el triaje.

La conclusión: divulgar es una transición de estado, no una fusión

Un programa de divulgación de vulnerabilidades no termina cuando se publica el parche. «Parcheado pero no divulgado» es un incumplimiento del informe, del trabajo del investigador y del derecho de los usuarios a saber, y debería encenderse en rojo en el mismo tablero que sigue el acuse de recibo y el triaje.

La historia de Cursor no es un escándalo aislado. Es el modo de fallo por defecto de todo programa cuyo ciclo de vida termina discretamente en «fusionado». La solución no es más diligencia a la hora de corregir; esos equipos ya corrigen con diligencia. Es tratar el CVE, el aviso, la notificación y el reconocimiento como transiciones de estado obligatorias por las que un informe debe pasar antes de poder considerarse terminado.

Si estás montando la parte de recepción, empieza por cómo poner en marcha un programa de divulgación de vulnerabilidades. Para lo que ocurre cuando la relación se rompe antes de la corrección, consulta cuándo los investigadores lo hacen público y nuestra opinión sobre los SLA de pago de recompensas y la equidad. Y si vendes en Europa, las obligaciones de divulgación del Cyber Resilience Act de la UE convierten el paso del aviso, de buena práctica, en ley. Este es el capítulo final de todas ellas: el informe no está terminado hasta que se divulga.