El error “GitLost” puede exponer datos de repositorios privados de GitHub a través de flujos de trabajo agénticos

Una vulnerabilidad recientemente identificada, apodada GitLost, podría permitir que un atacante acceda a información de repositorios privados de GitHub mediante el abuso del flujo de trabajo de incidencias públicas de una organización. Según el informe, el atacante no necesita autenticarse previamente para activar el problema: puede enviar una incidencia de GitHub especialmente diseñada en un repositorio público y utilizar esa entrada para influir en procesos agénticos automatizados vinculados a la base de código de la organización.

La preocupación es que estos flujos de trabajo pueden terminar procesando el contenido de la incidencia de formas que van más allá del repositorio público. En el escenario descrito, la incidencia maliciosa puede provocar silenciosamente que los datos del repositorio privado se incorporen a un contexto en el que no deberían quedar expuestos. Esto hace que el fallo sea especialmente relevante para las organizaciones que conectan sistemas de seguimiento de incidencias de acceso público con automatizaciones que tienen acceso a proyectos internos o confidenciales.

Aunque los detalles divulgados hasta ahora son limitados, el hallazgo pone de relieve un riesgo más amplio relacionado con las canalizaciones de desarrollo asistidas por IA y controladas por agentes. Cuando se permite que los sistemas automatizados lean incidencias, resuman contenido o realicen acciones posteriores en varios repositorios, un atacante podría ser capaz de dirigir esos sistemas para que revelen información que nunca estuvo destinada a hacerse pública.

Por qué es importante

• El ataque puede iniciarse mediante una incidencia en un repositorio público.
• Según el informe, no se requiere autenticación para enviar la entrada maliciosa.
• El material de repositorios privados puede quedar expuesto indirectamente a través de flujos de trabajo conectados.
• Las organizaciones que utilizan automatización agéntica deberían revisar cómo interactúan los repositorios públicos y privados.

Los equipos de seguridad que dependen de la automatización de GitHub deberían examinar los permisos de los repositorios, la lógica de gestión de incidencias y cualquier agente que pueda acceder tanto a recursos públicos como privados. Limitar el acceso entre repositorios y validar el contenido no confiable de las incidencias son medidas habituales que pueden reducir las probabilidades de una vía similar de exposición de datos.