CISA intenta contener una filtración de datos

• Un contratista de CISA subió credenciales en texto plano de decenas de sistemas internos al perfil público de GitHub “Private-CISA”, y también dejó rastros de haber desactivado funciones de protección de GitHub
• CISA reconoció la filtración, pero no respondió cuánto tiempo estuvieron expuestos los datos, y el repositorio, creado en noviembre de 2025, mostraba un patrón de uso más parecido a un bloc de notas personal
• Legisladores como Maggie Hassan y Bennie Thompson cuestionaron las políticas internas de seguridad, la gestión de contratistas y la cultura de seguridad de CISA en un momento de crecientes amenazas a la infraestructura crítica
• Incluso una semana después de la notificación de GitGuardian, seguía en curso la rotación de algunas claves, y Dylan Ayrey, de TruffleHog, señaló que una clave privada RSA seguía activa al 20 de mayo
• Como el feed público de eventos de GitHub puede ser monitoreado tanto por defensores como por atacantes, sigue existiendo el riesgo de que secretos sensibles añadidos a fines de abril de 2026 ya hayan sido explotados

---

La filtración de CISA y las preguntas del Congreso

• Un contratista de CISA creó un perfil público de GitHub llamado “Private-CISA” mientras tenía privilegios de administrador sobre la plataforma de desarrollo de código de la agencia, y allí se incluyeron credenciales en texto plano de decenas de sistemas internos de CISA
• En el registro de commits quedaron rastros de que se desactivaron las funciones de protección integradas de GitHub que impiden publicar credenciales sensibles en repositorios públicos
• CISA reconoció la filtración, pero no respondió durante cuánto tiempo estuvieron expuestos los datos
• Expertos que revisaron el archivo del ya desaparecido Private-CISA concluyeron que el repositorio fue creado por primera vez en noviembre de 2025 y mostraba un patrón de uso más cercano a un bloc de notas personal o un mecanismo de sincronización que a un repositorio de proyecto organizado
• En una declaración escrita, CISA dijo que “no hay indicios de que datos sensibles hayan sido comprometidos como resultado de este incidente”

Preocupaciones de los legisladores sobre la cultura de seguridad

• La senadora Maggie Hassan dijo en una carta enviada el 19 de mayo al director interino de CISA, Nick Andersen, que este fallo de seguridad en una agencia que ayuda a prevenir intrusiones cibernéticas plantea serias preguntas sobre cómo pudo ocurrir
• Hassan señaló que aumentan las preocupaciones sobre las políticas y procedimientos internos de CISA en un momento en que continúan graves amenazas cibernéticas contra la infraestructura crítica de Estados Unidos
• El incidente ocurrió en medio de una gran disrupción interna en CISA, después de que la administración Trump forzara jubilaciones anticipadas, buyouts y renuncias en varias áreas, tras lo cual CISA perdió más de un tercio de su personal y a casi todos sus líderes de alto nivel
• El representante Bennie Thompson dijo en una carta del 19 de mayo que el incidente podría reflejar una cultura de seguridad debilitada o una capacidad insuficiente de CISA para gestionar el soporte de contratistas
• Thompson y la cofirmante representante Delia Ramirez consideraron que, mientras potencias adversarias como China, Rusia e Irán buscan obtener y mantener acceso a redes federales, los archivos del repositorio Private-CISA ofrecían información, acceso y una hoja de ruta

La revocación de credenciales no ha terminado

• Más de una semana después de que la firma de seguridad GitGuardian alertara por primera vez a CISA sobre la filtración, CISA seguía trabajando en invalidar y reemplazar muchas de las claves y secretos expuestos
• Dylan Ayrey, creador de TruffleHog, dijo que al 20 de mayo una clave privada RSA expuesta en el repositorio Private-CISA todavía no había sido revocada
• Esa clave privada RSA otorgaba acceso a una app de GitHub propiedad de una cuenta empresarial de CISA e instalada en la organización de GitHub CISA-IT, con acceso completo a todos los repositorios de código
• Según Ayrey, un atacante podía usar esa clave para leer el código fuente de todos los repositorios y los repositorios privados de la organización CISA-IT, registrar runners maliciosos autohospedados, comprometer el pipeline de CI/CD y acceder a los secretos de los repositorios
• Un atacante también podía modificar configuraciones administrativas del repositorio, incluidas reglas de protección de ramas, webhooks y deployment keys
• Después de que KrebsOnSecurity informara a CISA el 20 de mayo sobre el hallazgo de Ayrey, parece que CISA revocó esa clave privada RSA
• Ayrey dijo que CISA todavía no había reemplazado otras credenciales filtradas vinculadas a tecnologías clave de seguridad desplegadas en todo el portafolio tecnológico de la agencia
• CISA respondió que “está colaborando y coordinando activamente con las partes y proveedores relevantes para asegurar que las credenciales filtradas identificadas sean reemplazadas e invalidadas, y continuará tomando las medidas apropiadas para proteger la seguridad de los sistemas”

La doble cara del feed público de eventos de GitHub

• Truffle Security monitorea claves expuestas en GitHub y otras plataformas de código, e intenta alertar a las cuentas afectadas sobre la exposición de datos sensibles
• GitHub ofrece un feed en tiempo real que incluye todos los commits y registros de cambios de repositorios públicos de código, y esa estructura hace posible detectar exposiciones
• Ayrey explicó que los ciberdelincuentes también monitorean ese feed público y buscan rápidamente claves API o claves SSH publicadas por error en commits de código
• En el repositorio de GitHub Private-CISA quedaron expuestas decenas de credenciales en texto plano para recursos críticos de CISA GovCloud
• Ayrey dijo que es muy probable que organizaciones criminales cibernéticas o potencias hostiles extranjeras también hayan visto la publicación de secretos de CISA, y que la exposición más grave parece haber ocurrido a fines de abril de 2026
• El riesgo principal sigue siendo que “cualquiera que monitoree los eventos de GitHub podría tener esta información”

Los límites de los controles técnicos

• James Wilson, del pódcast de seguridad Risky Business, señaló que las organizaciones que gestionan proyectos de código en GitHub pueden establecer políticas superiores para impedir que los empleados desactiven funciones de prevención de publicación de claves secretas y credenciales
• El copresentador Adam Boileau consideró que no está claro qué tecnología podría impedir que empleados abran cuentas personales de GitHub para guardar información sensible y propietaria
• Boileau definió este incidente como un problema humano difícil de resolver solo con controles técnicos
• Si el contratista usó GitHub para sincronizar contenido entre dispositivos de trabajo y personales, el incidente deja en evidencia la dificultad de impedir acciones fuera del alcance que CISA puede gestionar o supervisar
• La actualización del artículo agregó la declaración de CISA y corrigió un error de fecha, ya que Truffle Security indicó que algunos de los secretos más sensibles del repositorio fueron añadidos no en 2025, sino a fines de abril de 2026

[GN⁺]

Comentarios en Hacker News

• De verdad es un error ridículamente absurdo. Eso de que “coincide con un patrón de usar el repositorio más como un bloc de notas de trabajo personal o un medio de sincronización que como un repositorio de proyecto administrado”... ¿acaso lo más básico de Git no es no meter credenciales? No entiendo con qué patrón se supone que coincide

  • Esa expresión no pretende defenderlo como una forma de trabajo establecida o una buena práctica
    Decir que “muestra un patrón consistente con ~” solo describe cómo parece haberse usado el repositorio. O sea, que no era un paquete de código fuente gubernamental para un proyecto interno ni una señal de que hubiera intención de filtrar datos a gran escala
  • Ya está claramente escrito con qué patrón coincide ese uso: que se usó como una especie de cuaderno personal de trabajo
    Le estás atribuyendo más significado del que realmente tiene esa frase. Solo está describiendo lo observado
  • No fue un error para nada. El gobierno de EE. UU. está completamente infiltrado por servicios de inteligencia extranjeros, y esta “intrusión” fue totalmente intencional
  • Si me hubieran pagado 1 dólar por cada secreto subido a un repositorio público, probablemente ya podría retirarme. Claro que eso no lo justifica. También es bastante chistoso fingir que el gobierno de EE. UU. no está compuesto, al final, por gente igual que nosotros

• Unos controles técnicos más competentes deberían haber evitado de entrada una situación en la que un contratista cualquiera pudiera copiar a su computadora de casa una contraseña de mediados de 2025, y que esa contraseña siguiera funcionando no ya 30 días después, sino incluso 5 días después

  • Sí. La verdad, pensaba que el gobierno ya llevaba mucho tiempo usando smart cards y HSM bastante en serio para todo. No entiendo por qué darle a alguien credenciales que se pueden extraer, cuando podrían simplemente repartir hardware del que no se puedan sacar las credenciales
    En algunas organizaciones el costo adicional sería un problema, pero aquí no es el caso. O quizá esto sea otro síntoma del deterioro que surgió porque justo estos proyectos y estándares eran algo que CISA solía hacer, y los republicanos lo echaron a perder el año pasado. En cualquier caso, la tecnología claramente puede reducir este tipo de cosas, no es como si fuera un desastre natural inevitable
  • No manejo secretos de Estado, pero sí tengo acceso a datos sensibles o valiosos para clientes. La sola idea de descargar algo directamente a mi dispositivo me resulta difícil de entender
    Incluso bajar un archivo de logs con algo como "aws s3 cp s3://client/file - | less" me parece mala idea. Yo preferiría mucho más levantar una instancia barata y ver los datos dentro del VPC del cliente

• Si reduces una organización experta, parece obvio que vas a perder muchas capacidades, incluida la seguridad operativa
  En 2020, Chris Krebs refutó las afirmaciones de fraude electoral. En 2025, Trump despidió a Krebs y le revocó la autorización de seguridad, dejando a CISA sin director. https://en.wikipedia.org/wiki/Chris_Krebs
  En marzo de 2025 empezaron los recortes. https://techcrunch.com/2025/03/11/doge-axes-cisa-red-team-st...
  En 2026 seguía sin director y operando casi al límite. https://techcrunch.com/2026/02/25/us-cybersecurity-agency-ci...
  Todo este rumbo coincide con debilitar deliberadamente desde dentro las defensas de un país y sembrar caos

  • Si una potencia extranjera hostil estuviera a cargo, ¿seríamos capaces de notar la diferencia?
  • Si soy sincero, esto encaja más directamente con incompetencia agresiva y contrataciones/despidos basados en lealtad. Reconozco que cómo esos idiotas llegaron a tener poder para contratar y despedir ya es una cuestión más compleja
  • Krebs no fue despedido en 2025, sino en 2020

• CISA perdió más de un tercio de su personal y a la mayoría de sus líderes de alto nivel después de que la administración Trump impulsara jubilaciones anticipadas, buyouts y renuncias en varias dependencias

• Al parecer, senadores preguntaron por qué CISA está reduciendo sus esfuerzos relacionados con la seguridad electoral[1]. El momento de la renuncia de Tulsi hoy también parece coincidir de forma curiosa con el momento en que esto se hizo público
  [1]https://www.padilla.senate.gov/newsroom/press-releases/padil...

  • No entiendo por qué los senadores de EE. UU. hacen tanto escándalo. Trump fue muy claro al presentar su presupuesto: quería recortar drásticamente el presupuesto de CISA, y también dio la orden directa de cerrar la oficina de seguridad electoral de CISA
    Esto es el meme de “¿quién mató a Hannibal?”. Si Padilla y Warner no sabían esto, entonces ellos también son incompetentes. Sobre todo porque ya lo habían tratado en un comunicado de prensa el año pasado:
    https://www.padilla.senate.gov/newsroom/news-coverage/cnn-tr...
    Padilla, ¿por qué olvidaste que esto pasó?

• Me recuerda a la nctificación del transporte público. Recortas el presupuesto, baja la calidad del servicio y luego llega la opinión pública negativa
  Al final, ese camino puede llevar a una mayor privatización a través de contratistas de seguridad

  • Quien filtró las credenciales fue precisamente un contratista de seguridad. Así que en cierto sentido ya estamos en la etapa final de esa mayor privatización

• Me acuerdo de cuando se filtró 1 millón de formularios SF-86. Ya saben, ese formulario donde uno mete una cantidad brutal de información personal para que decidan si de verdad se te puede confiar información sensible

  • Eso no fue una filtración, fue una intrusión. Lo hizo un organismo de seguridad del Estado chino
  • ¿Eso no fue OPM y no CISA?

• Los legisladores quieren respuestas, pero ellos mismos no dan respuestas. Eso de quién vigila a los vigilantes... La corrupción de los legisladores ocurre a gran escala, ¿pero por una sola llave expuesta te cortan la cabeza? Hasta gente muy inteligente expone llaves por error con frecuencia
  ¿Nunca han ejecutado rm -rf *? ¿Nunca han borrado una base de datos de producción? ¿Nunca han apagado el servidor equivocado? Todos lo han hecho

  • Su vigilancia no busca el cuidado, sino el control. Es discretamente hostil, y el “cuidado” no es más que un pretexto, no la realidad

• Si estas personas, que se supone deberían ser expertas, no pueden mantenerse seguras correctamente en internet, no sé cómo podría estar seguro cualquier otro en internet

  • Esto es después de Doge. Doge hizo bien su trabajo. Tristemente, mucha otra gente repitió las mentiras de Doge tal cual

• El verdadero punto clave no es solo la llave de AWS GovCloud filtrada, sino que el contratista desactivó manualmente la protección de escaneo de secretos de GitHub