El proyecto curl gana su primera disputa de CVE: MITRE respalda su decisión

A CVE Dispute

El proyecto curl, como CNA (Autoridad de Numeración CVE), publicó 57 vulnerabilidades con sus CVE. En febrero de 2026 recibió su primera disputa: un reportero insistía en que un problema con un nombre de host con punto inicial (como .example.com) merecía un CVE, pero el equipo lo consideró de gravedad 'menor que LOW' por las condiciones extremadamente improbables para explotarlo. Tras tres apelaciones, MITRE dio la razón a curl en junio, confirmando que no se asignaría un CVE. El artículo detalla el proceso de evaluación y el costo de cada CVE para el ecosistema.

Cada CVE conlleva un costo enorme que no recae en nosotros y que realmente no vemos ni sentimos, pero es un costo para el ecosistema que creo que no deberíamos ignorar.
  1. ealready_value

    > Cada CVE tiene por tanto este enorme coste asociado. Un coste que no recae sobre nosotros y que realmente no vemos ni sentimos, pero un coste para el ecosistema que creo que no deberíamos ignorar.

    Aprecio mucho esta actitud hacia esto porque reconoce que hay muchos equipos de seguridad que no tienen una visión matizada de los CVE. Por ejemplo, una vez tuvimos un equipo de seguridad que nos exigió parchear un paquete de soporte de VMware que estaba instalado por defecto en Ubuntu, pero el CVE requería ejecutarse en VMware cuando estábamos corriendo en EC2. Discutir con ellos fue inútil porque no estaban interesados en determinar si el CVE nos afectaba, solo en que se arreglara.

    Muchos equipos que se supone que están a cargo de la seguridad no preguntan "¿nos afecta este CVE?", sino que simplemente trasladan la carga del parcheo hacia abajo y hacia afuera. En algunos casos, como en el caso de productos SaaS fáciles de actualizar y desplegar centralmente, esa carga es más molesta y frustrante que difícil. En otros casos, como cuando tienes un despliegue complicado o actualizaciones controladas por el cliente, esos mandatos causan una enorme carga a los equipos que no producen la decisión de parchear cada CVE de baja severidad.

  2. Aurornis

    Sería revelador ver algunas de las comunicaciones por correo electrónico que esta persona estaba enviando a MITRE mientras intentaba luchar contra este problema.

    Todos estamos familiarizados con cómo algunos usan LLMs para escribir código y enviar PRs, pero hay un problema creciente de personas que usan LLMs para luchar incansablemente contra problemas con comunicaciones como correos electrónicos e incluso sugiriendo papeleo físico también.

    Ahora que el esfuerzo para argumentar algo contra una institución se acerca a cero, más personas están teniendo la idea de hacer que su LLM y su arnés luchen algunas batallas por ellos. Siento que les cuesta muy poco, pero si hay una probabilidad no nula de ganancia personal, lo hacen. Estoy escuchando muchas historias sobre todo, desde gobiernos locales hasta oficinas administrativas universitarias, abrumados por solicitudes que no dejan de llegar de remitentes implacables que piensan que pedir cualquier cosa vale la pena intentarlo, incluso si no hay posibilidad de que se conceda.

    Creo que vamos a tener que replantearnos muchos de nuestros sistemas de comunicación y solicitud que anteriormente dependían del hecho de que la mayoría de la gente no se esforzaría en discutir por algo que no merecía. Cuando el costo de discutir se acerca a cero, la máquina puede seguir intentando obtener la probabilidad no nula de éxito por ellos.

  3. rwmj

    Los incentivos aquí son realmente malos en este momento. Tradicionalmente, tener tu nombre en un CVE contra un proyecto importante como curl tenía cierto prestigio en la comunidad. Incluso podrías aprovecharlo para obtener un aumento o un mejor trabajo, así que el dinero definitivamente era parte de esto.

    Ahora mucha gente está lanzando código contra LLMs y luego copiando y pegando lo que salga en informes de "seguridad".

    Decidimos para nuestros proyectos que cualquier informe de seguridad generado por LLM se copie simplemente a la lista pública. Todos tienen acceso a LLMs, así que presumiblemente si una instancia de LLM lo encontró, entonces todos los usuarios de LLMs ya lo han encontrado o lo encontrarán en breve. Los arreglaremos si son importantes, pero la relación señal-ruido es bastante mala.

    Creo que esto, eventualmente, resultará en servicios más seguros a medida que los problemas de bajo nivel se encuentren y se arreglen. Pero desafortunadamente no veo que la inundación de tonterías generadas por LLM termine pronto.

  4. woodruffw

    Este tipo de experiencia infernal es un gran ejemplo del sistema CVE tratando de tenerlo todo: cuando está a la ofensiva es una rica fuente de información para los defensores, y cuando está a la defensiva es solo un ID opaco para la coordinación que no implica nada sobre la calidad o corrección del informe subyacente.

  5. cynicalsecurity

    Alguien debía tener muchas ganas de poner esto en su CV.

Más de este día

2026-08-31