El proyecto Curl, uno de los componentes de código abierto más críticos del ecosistema digital, ha anunciado el cierre progresivo de su programa de bug bounty en la plataforma HackerOne. La decisión se basa en el crecimiento incontrolado de reportes de baja calidad, muchos de ellos generados con herramientas de inteligencia artificial (IA), que han saturado a un equipo de seguridad muy reducido.
Importancia de Curl y libcurl para la seguridad de código abierto
Curl y su biblioteca libcurl son utilizados en millones de sistemas y aplicaciones: desde dispositivos embebidos y firmware de routers hasta servicios en la nube y grandes plataformas web. Cualquier deficiencia en su proceso de gestión y divulgación de vulnerabilidades impacta potencialmente en toda la cadena de suministro de software.
En este contexto, la retirada de Curl de una plataforma de bug bounty tan consolidada como HackerOne constituye un caso de estudio para la industria. Muestra cómo el uso masivo e indiscriminado de IA para generar reportes está empezando a poner en cuestión la viabilidad operativa de los programas de recompensas tradicionales.
Cronograma del cierre del bug bounty de Curl en HackerOne
Daniel Stenberg, fundador y principal desarrollador de Curl, ha detallado un cierre por fases. Hasta el 31 de enero de 2026 el proyecto seguirá recibiendo reportes a través de HackerOne y se compromete a revisar todos los casos abiertos hasta completarlos. A partir del 1 de febrero de 2026, Curl dejará de aceptar nuevos informes en HackerOne y migrará a un modelo de divulgación directa mediante GitHub.
Sobre carga de reportes generados con IA y caída de la tasa de validez
Los problemas con lo que Stenberg denomina “AI slop” —un flujo de informes superficiales, mal fundamentados y generados con IA— comenzaron a hacerse visibles en 2024. Según sus estimaciones, en torno a un 20% de todos los reportes ya se elaboraban con ayuda de sistemas de IA, coincidiendo con una fuerte caída de la tasa de validez.
En el último año analizado, únicamente alrededor del 5% de los reportes describían vulnerabilidades reales. El resto eran falsos positivos, malentendidos sobre el diseño del software o simples especulaciones sin prueba de concepto reproducible. Este desequilibrio rompe la economía del bug bounty: generar informes es trivial y casi gratuito, pero verificarlos consume tiempo experto escaso y costoso.
Un equipo de seguridad pequeño frente a un volumen insostenible
La realidad operativa agrava el problema. El equipo de seguridad de Curl está compuesto por solo siete personas. Cada reporte requería la intervención de 3 a 4 revisores y demandaba entre 30 minutos y tres horas para su análisis y validación.
En enero de 2026 la situación alcanzó un punto crítico: en apenas 16 horas, durante una misma semana, el proyecto recibió siete nuevos reportes vía HackerOne. A mitad de mes ya se habían procesado más de 20 informes, y ninguno resultó ser una vulnerabilidad válida. Esta dinámica desvía recursos de tareas esenciales como el mantenimiento del código, el desarrollo de mitigaciones y la coordinación de avisos de seguridad.
Eliminar el incentivo económico a los reportes basura
Stenberg subraya que el objetivo principal del cierre del programa en HackerOne es suprimir el incentivo económico que alimenta la generación de reportes de baja calidad. No importa si el informe lo escribe una persona o una IA: si no aporta valor técnico, solo añade ruido y erosiona la capacidad de respuesta de los mantenedores.
Aun así, se reconoce que abandonar HackerOne no detendrá completamente los informes débiles. Para un proyecto open source con pocos colaboradores activos, se trata de una medida necesaria para proteger la sostenibilidad del proyecto y la salud mental del equipo.
Nueva política de security.txt y cambio de expectativas
Como parte de este giro estratégico, Curl ha actualizado su archivo security.txt, el estándar que define los canales oficiales para comunicar fallos de seguridad. La nueva versión indica explícitamente que el proyecto ya no ofrece recompensas económicas por vulnerabilidades ni intermedia para que terceros paguen compensaciones.
Además, se advierte que quienes envíen reportes claramente basura podrán ser bloqueados e incluso señalados públicamente como ejemplo de malas prácticas. El mensaje busca disuadir el envío masivo de informes generados sin revisión crítica por parte de sus autores.
De HackerOne a GitHub: impacto en investigadores y ecosistema
Desde febrero de 2026, Curl propone una divulgación responsable directa a través de GitHub. Los investigadores remitirán sus hallazgos directamente a los mantenedores, sin la intermediación de una plataforma de bug bounty. Para quienes trabajan de forma ética y rigurosa, esto reduce barreras administrativas, pero elimina el componente de monetización que para muchos era un motor clave.
Entre 2019 y el cierre anunciado, a través de HackerOne e Internet Bug Bounty se habían pagado más de 90 000 dólares por 81 vulnerabilidades confirmadas en Curl y libcurl. El fin de este modelo marca un cambio de enfoque: del incentivo económico directo hacia una colaboración centrada en la resiliencia del ecosistema más que en la recompensa individual.
Lecciones para programas de bug bounty en la era de la inteligencia artificial
El caso Curl ilustra un riesgo central para los programas de bug bounty actuales: la avalancha de reportes generados con IA puede romper el equilibrio entre coste de verificación y calidad de resultados. Mientras que producir “pseudo-informes” es casi inmediato, evaluarlos requiere conocimiento especializado y procesos estructurados.
Para mitigar este riesgo, tanto empresas como proyectos de código abierto deberían implantar mecanismos de filtrado previo: formatos de reporte más estrictos, exigencia de pruebas de concepto reproducibles, criterios mínimos de severidad y, cuando proceda, programas cerrados o por invitación reservados a investigadores ya validados. Organismos como ENISA o CISA han señalado de forma reiterada la necesidad de reforzar la gestión de vulnerabilidades en el software de código abierto, y estos casos ofrecen guías prácticas sobre cómo hacerlo.
La situación de Curl recuerda lo frágiles que son los recursos de muchos proyectos críticos que sustentan Internet. Es recomendable revisar las políticas internas de responsible disclosure, adaptar los programas de bug bounty al contexto de IA generativa y formar a los equipos para que utilicen estas herramientas como apoyo al análisis, no como sustituto de la pericia técnica. Seguir de cerca la evolución de Curl y de otros proyectos similares ayudará a definir procesos de ciberseguridad más sostenibles, eficaces y alineados con la realidad tecnológica actual.
