7 puntos por GN⁺ 2026-01-22 | 2 comentarios | Compartir por WhatsApp
  • La biblioteca de código abierto cURL puso fin a su programa de recompensas por errores para frenar el aumento de reportes de bugs sin sentido generados por IA
  • El mantenedor Daniel Stenberg explicó que la mayoría de los reportes creados por IA son "completamente falsos" y requieren mucho tiempo para ser verificados
  • cURL dejará de pagar recompensas desde finales de enero, tras haber entregado en total 101,020 dólares por 87 reportes hasta ahora
  • El investigador de seguridad Joshua Rogers ha enviado reportes realmente válidos usando herramientas de IA, pero aun así consideró esta decisión como una "medida muy sensata"
  • Señaló que la verdadera motivación no es el dinero, sino la reputación y el logro técnico, y mencionó que otros proyectos también deberían considerar medidas similares

Decisión de cURL de terminar su programa de recompensas por errores

  • La biblioteca de código abierto cURL dejará de ofrecer recompensas económicas por reportes de bugs
    • El objetivo es frenar el aumento de reportes falsos generados por IA (AI slop)
    • El mantenedor Daniel Stenberg comentó que “el AI slop y los reportes inexactos siguen aumentando, y si no detenemos esta avalancha, nos vamos a hundir”
  • cURL pondrá fin al pago de recompensas a finales de enero
    • Explicó que “se está perdiendo demasiado tiempo con hallazgos que en realidad no existen, están exagerados o fueron malinterpretados”

El problema y el impacto de los reportes generados por IA

  • cURL ha visto aumentar fuertemente su carga de trabajo por los reportes de bugs generados automáticamente por IA
    • La mayoría de estos reportes terminan siendo inútiles o incorrectos
    • El proceso de distinguirlos consume mucho tiempo y representa una gran carga para los mantenedores
  • Stenberg ya había abordado públicamente este problema en 2025 con el texto "Death by a thousand slops"

Casos positivos de reportes asistidos por IA

  • No todos los reportes generados con IA son inútiles
    • Stenberg mencionó que más de 100 reportes asistidos por IA sí llevaron a correcciones reales en el código
  • Hasta ahora, cURL ha pagado un total de 101,020 dólares en recompensas por 87 reportes de bugs
    • Sin estas recompensas, es posible que algunos reportes no se hubieran descubierto (sin análisis adicional)

La postura del investigador de seguridad Joshua Rogers

  • Joshua Rogers es un investigador que ha presentado múltiples reportes de bugs válidos a proyectos de código abierto utilizando herramientas de IA
    • Revisa los resultados del análisis de la IA y los corrige personalmente antes de enviarlos
  • Rogers calificó la decisión de cURL como una "excelente medida que debió aplicarse hace mucho tiempo"
    • También señaló que “más bien sorprende que este programa haya durado tanto tiempo”
  • Añadió que “si desaparecen las recompensas por errores, parte de la motivación se reducirá, pero los reportes importantes seguirán llegando

El desequilibrio entre recompensa y motivación

  • Rogers subrayó que la verdadera motivación es la "fama" (fame), y que la recompensa económica es secundaria
    • La recompensa máxima de cURL es de 10,000 dólares, una cantidad que no resulta tan grande para especialistas capaces de encontrar vulnerabilidades graves
  • Sin embargo, también señaló un desequilibrio económico
    • La misma recompensa puede ser muy significativa para investigadores de regiones de bajos ingresos
    • Explicó que “una recompensa que en Suecia equivale al precio de un almuerzo puede convertirse en una suma enorme en algunas regiones”

Un desafío compartido en el ecosistema open source

  • Según el artículo, otros proyectos de código abierto también están sufriendo la avalancha de reportes generados por IA
  • La decisión de cURL podría abrir una nueva discusión sobre el control de calidad y la forma de gestionar comunidades en la era de la IA (sin explicación adicional)

2 comentarios

 
xguru 2026-01-22

Se acerca la industrialización de la generación de exploits para hacking basada en LLM

Junto con esto, parece que se acerca el momento en que no queda otra que aplicar LLM en varias áreas.
Aunque sea para frenar a los hackers que usan LLM, habrá que encargarle a los propios LLM la verificación de seguridad.

 
GN⁺ 2026-01-22
Comentarios de Hacker News
  • Parece que se podría frenar rápido este problema si se implementara una cuota de participación reembolsable cuando el bug resulte ser realmente importante.
    Una vez reporté una vulnerabilidad en un sistema de inicio de sesión bancario que permitía cambiar de contraseña+PIN a solo PIN, y lo cerraron diciendo que era “comportamiento esperado”.
    Aprendí que las instituciones altamente reguladas, como hospitales o bancos, suelen enfocarse más en “cumplir con compliance” que en la seguridad real.
    Si los organizadores de un bug bounty operan de buena fe, este tipo de barrera de entrada o penalización podría ayudar a filtrar a quienes envían reportes maliciosos.

    • Los bug bounty tienen una estructura riesgosa para quien reporta.
      Muchas veces el revisor malinterpreta el contenido o las reglas son ambiguas.
      Si además cobran una cuota de participación, ese riesgo aumenta.
      Cuando yo estaba del lado de la organización, ya llegaban demasiados reportes desastrosos, y ahora con la IA probablemente esté todavía peor.
      Desde la perspectiva del participante, tampoco es fácil garantizar una evaluación justa, y además es muy probable que el reporte termine siendo duplicado.
    • Es una realidad triste que muchas instituciones fuertemente reguladas busquen mantener solo el mínimo necesario para que no las atrapen, en vez de priorizar la seguridad.
      Una vez un banco de la UE solo permitía inicio de sesión con firma electrónica compatible con SHA-1, un algoritmo descartado desde hacía ya 10 años.
      El software del proveedor de identidad certificado por el gobierno simplemente se caía si había una YubiKey conectada.
      Era un dispositivo que seguía el estándar, pero el desarrollador había hecho supuestos fuera del estándar.
      Reporté el bug, pero solo me respondieron “no es nuestro problema”.
    • La esencia de un bug bounty es incentivar a reportar vulnerabilidades a los desarrolladores.
      Pero si para reportarlas hay que pagar, y además no hay certeza de reembolso ni recompensa, entonces venderlas en otro lado puede parecer una opción más atractiva.
    • Un sistema de cuota de participación aumenta mucho la complejidad operativa.
      Daniel, de cURL, ya había evaluado esta idea varias veces, pero finalmente concluyó que no era viable.
    • Yo también llegué a la misma conclusión al ver el caso de GrapheneOS.
      Los dispositivos certificados pero inseguros pueden usar todas las funciones de la app, mientras que GrapheneOS, que es el sistema operativo más seguro, tiene funciones limitadas porque “no está certificado”.
      Al final, el problema no es la seguridad sino el sistema de certificación.
  • Parece que el open source es quien más está sufriendo por culpa de la IA.
    El código abierto se usó para entrenar modelos, y ahora esos modelos llenan de spam a los proyectos open source.
    Además, la IA implementa funciones de pago y erosiona el modelo de negocio del open source, e incluso podría terminar reemplazando al propio código abierto.

    • La IA está matando todos los motores del open source.
      Elimina las ganas de contribuir, mantener, aprender, colaborar y construir negocios.
      Incluso destruye la forma tradicional de empleo basada en trabajar con código cerrado.
      Al final, todo se reduce a tres empresas estadounidenses compitiendo por revender como suscripción nuestro trabajo pasado.
    • Desde la llegada de la IA, hubo una explosión de gente que realmente no entiende código pero quiere conseguir insignias de contribuidor en repositorios grandes.
      Antes también existía este tipo de contribución presumida, pero ahora la escala es completamente distinta.
    • Si esta tendencia sigue, programas como Google Summer of Code probablemente necesiten una reforma profunda.
      Antes los estudiantes encontraban proyectos y contribuían directamente, y ese proceso ya filtraba de manera natural.
      Si la IA lo hace por ellos, ese filtro desaparece.
    • Es triste que la IA desestabilice el modelo de negocio del open source, pero nadie tiene derechos sobre un modelo de negocio.
      Si el mundo compite, es natural que los modelos basados en open core terminen debilitándose.
    • Los modelos no se entrenaron solo con código open source.
      También incluyeron libros, clases y documentación oficial.
      Una vez le pedí a Claude que agregara funciones de GUI para recuperar datos de un dispositivo Android viejo, y funcionó bastante bien.
      Como el código terminó alejándose de la dirección original del proyecto, no lo volví a subir a GitHub.
  • Desde la perspectiva de un hacker white hat, la recompensa de un bug bounty no suele ser grande, pero participar tiene un valor como decisión moral.
    En cambio, si se trata de una vulnerabilidad explotable, también podría venderse a creadores de malware que paguen más.

    • Pero en la práctica negociar con creadores de malware es casi imposible.
      Como no hay confianza entre las partes, hacen falta procedimientos complejos como escrow en criptomonedas, lavado, etc.
      Además, hacer este tipo de transacciones sin aprobación gubernamental implica riesgos legales.
      Por eso, cuesta creer que ese mercado funcione de manera real.
    • Quizá los propios creadores de malware también estén sufriendo para filtrar los reportes basura generados por IA.
  • Hackerone tiene un sistema de reputación para hackers.
    Sería lógico operarlo como programas privados donde solo inviten a hackers verificados; no entiendo por qué no lo hacen.

    • Pero si todos los proyectos hicieran eso, los hackers nuevos perderían oportunidades de demostrar su capacidad.
      Al final, la barrera de entrada al ecosistema podría volverse demasiado alta.
  • Además de la recompensa monetaria, también existen motivaciones como el prestigio o conseguir un CVE.
    Stenberg ha tratado varias veces en su blog casos de vulnerabilidades exageradas, y algunas parecían infladas intencionalmente por motivos de reputación.
    Ese tipo de incentivos es difícil de manejar con el diseño de incentivos.

  • Hay un video que muestra el contexto de este problema → enlace de YouTube

    • Intenté verlo, pero hoy en día el tono y los gestos exagerados estilo YouTube me cansan demasiado y lo quité casi de inmediato.
      Ese micrófono enorme, los gestos excesivos y expresiones exageradas como “awesome” o “insane” dominando toda la conversación se sienten agotadores.
  • La idea de que “una recompensa equivalente al almuerzo en Suecia ya es mucho dinero para personas de países de bajos ingresos” suena como una afirmación exagerada.
    Un almuerzo en el centro de Estocolmo cuesta unas 200 coronas, y es difícil creer que alguien con esas capacidades técnicas lo vea como “mucho dinero”.

    • Pero desde la perspectiva de un país en desarrollo, un tope de 10,000 dólares podría equivaler a varios años de salario mínimo.
      Aunque haya exageración, sigue siendo una diferencia que no se puede ignorar.
  • El bug bounty de nuestra empresa en la práctica es solo una dirección de correo de seguridad, pero recibimos más de 100 mensajes de spam al día.
    La mayoría son reportes falsos de pentest generados por IA, llenos de vulnerabilidades inventadas e información incorrecta.
    Incluso un vendedor quiso agendar una reunión de 3 horas, pero en el reporte aparecían bugs de IIS que no existían y direcciones IP imposibles.
    En ese momento de verdad me quedé sin palabras.

  • Antes encontrar bugs era lento y difícil, así que hacían falta incentivos, pero ahora lo más difícil pasó a ser separar los bugs reales.
    Hay incluso un chiste sobre los cazadores de bugs con IA: “de 100, encuentran 3 de verdad”.

    • Aun así, la búsqueda de vulnerabilidades graves sigue siendo terreno humano.
      La IA todavía no puede encontrar vulnerabilidades en una base de código como la de cURL ni hacer exploits binarios.
    • Al final, el proceso de distinguir bugs reales sigue siendo lento y pesado.
  • Está publicada una lista de reportes basura generados por IA que recibió cURL → enlace al gist

    • En el segundo reporte, Daniel intentó conversar amablemente, pero la otra parte ni siquiera escribió bien su nombre.
      Fue en diciembre de 2023, así que seguro ya estaba muy cansado.
    • Leí algunos, y cuesta distinguir si los escribió una IA o un estudiante principiante.
      Aun así, el LLM suena más convincente.
    • Me dio risa ver la frase “busqué esta vulnerabilidad en Bard”.
      Se siente curioso ver que mencionan a Bard como si fuera el LLM de referencia.
    • Todos son claramente textos escritos por IA, así que hasta resulta extraño que el staff responda con seriedad.
    • Sinceramente, leerlos ya resulta irritante.
      Sorprende que cURL haya aguantado y respondido durante tanto tiempo.