Curl rompe con HackerOne: fin a las recompensas y la avalancha de informes generados por IA

El responsable principal de curl, la popular herramienta de línea de comandos y su biblioteca asociada, ha decidido terminar con el programa de recompensas gestionado a través de HackerOne. Según la documentación del proyecto, el cese se hará efectivo al final de enero de 2026 y la decisión responde a una avalancha de informes de seguridad de muy baja calidad, muchos de ellos aparentemente generados por herramientas de inteligencia artificial.

Curl es una pieza crítica del ecosistema web: se usa para transferir datos a través de multitud de protocolos y su biblioteca libcurl permite integrar esa funcionalidad en aplicaciones. Si quieres consultar la documentación oficial, el proyecto mantiene su sitio en curl.se y explica la integración con libcurl en su tutorial libcurl tutorial.

Desde 2019, el equipo de curl había recurrido a canales externos —entre ellos HackerOne y el Internet Bug Bounty— para incentivar la divulgación responsable a cambio de una compensación económica. Sin embargo, en las últimas semanas el proyecto ha ido documentando un aumento sostenido de reportes que consumen tiempo de los mantenedores sin aportar hallazgos reales: falsos positivos, descripciones vagas o informes que parecen “lucir bien” a nivel de redacción pero no señalan vulnerabilidades reproducibles.

Daniel Stenberg, fundador y desarrollador principal de curl, explicó en su lista de correo personal los motivos detrás del cambio y detalló cómo ese tipo de envíos está sobrecargando al pequeño equipo que mantiene el proyecto. Puedes leer su mensaje en la lista pública en esta entrada. Además, Stenberg ha compartido ejemplos lo bastante ilustrativos como para entender qué tipo de reportes están motivando la decisión; hay una recopilación pública de esos ejemplos en su Gist, y sus comentarios en redes sociales pueden consultarse en su publicación en Mastodon.

El cambio se está formalizando en la documentación del repositorio: una actualización pendiente en el archivo de políticas de recompensas de curl (BUG-BOUNTY.md) elimina las referencias al programa de HackerOne y aclara que, a partir de la fecha indicada, el proyecto no ofrece compensaciones económicas por vulnerabilidades reportadas ni mediará para obtener pagos de terceros. La transición técnica y de procesos está descrita en el pull request que introduce esos cambios, disponible en GitHub.

¿Qué significa esto en la práctica? Hasta el 31 de enero de 2026 el proyecto seguirá aceptando y procesando envíos hechos a través de HackerOne; los informes ya iniciados continuarán su tramitación. A partir del 1 de febrero, sin embargo, curl pedirá que los hallazgos se comuniquen directamente por GitHub y mantendrá una postura explícita de no otorgar pagos. El equipo también ha actualizado sus archivos de seguridad indicando que las contribuciones de baja calidad serán sancionadas y que el objetivo es reducir el ruido que distrae a los mantenedores.

La explicación oficial destaca dos puntos íntimamente relacionados: por un lado, la escasez de manos activas que sostienen proyectos de código abierto y, por otro, la llegada masiva de contenido automático que simula reportes válidos. Ese fenómeno, a veces descrito como la inundación de contenido generado por IA que aporta poco valor, obliga a dedicar horas de triage a clasificar y rechazar envíos en vez de corregir fallos reales. Stenberg ha señalado que la presión sobre la salud mental y la sostenibilidad del mantenimiento fue determinante para tomar la decisión.

Este caso plantea preguntas más amplias sobre cómo financiar y asegurar proyectos de software libre en la era de la automatización. Los programas de recompensa ofrecen incentivos claros para quien encuentre vulnerabilidades, pero también introducen una economía que puede atraer volumen de envíos de diversa calidad. Si la automatización permite generar solicitudes y reproches en masa, los mantenedores tienen que diseñar filtros y procesos de triage que, a su vez, consumen recursos que muchos repositorios pequeños no tienen.

Es posible que la retirada de curl de HackerOne no detenga por completo la llegada de reportes espurios, algo que el propio equipo reconoce; el cambio aspira, eso sí, a cortar un incentivo económico que estaba amplificando el problema. La comunidad de seguridad y los proyectos de código abierto tendrán que seguir explorando soluciones: desde mejorar la priorización y el filtrado automatizado hasta buscar modelos sostenibles de financiación comunitaria o institucional para la triage remunerada.

¿Qué pueden hacer investigadores y usuarios ahora? Para quienes encuentren problemas legítimos en curl o libcurl, la vía indicada será la presentación directa en el repositorio de GitHub del proyecto, y conviene documentar con claridad cómo reproducir el fallo y su impacto. Para la comunidad en general, el episodio sirve como un recordatorio de que la calidad de las comunicaciones técnicas es tan importante como la propia vulnerabilidad: un informe bien redactado y verificable sigue siendo la mejor forma de colaborar.

Daniel Stenberg anunció que publicará un artículo más detallado acerca del cambio y las razones que lo sustentan; hasta entonces, las fuentes primarias del movimiento están disponibles públicamente y son la referencia más fiable para entender los matices. Para consultar la política actual y el historial del proyecto, revisa el repositorio oficial en GitHub y las entradas señaladas anteriormente.