GitHub notificó por correo a usuarios afectados por un bug en su plataforma de webhooks que expuso por error los secrets de verificación de algunas integraciones en headers HTTP enviados a endpoints receptores, según un mensaje revisado por EstadoRed. En el aviso, la empresa señaló que el fallo estuvo presente entre el 11 de septiembre y el 10 de diciembre de 2025, con una breve reaparición el 5 de enero de 2026, y que fue corregido el 26 de enero. GitHub aseguró además que no se trató de una intrusión general a cuentas ni de una filtración adicional de credenciales, aunque pidió a los usuarios afectados rotar de inmediato los secrets comprometidos y revisar si esos valores quedaron registrados en logs de los sistemas receptores.
El incidente afecta una pieza muy específica de la infraestructura de integración. En GitHub, el secret de un webhook no es una contraseña de cuenta ni un secret de Actions, sino una clave usada para verificar que una entrega proviene realmente de la plataforma y que no fue alterada en tránsito. GitHub recomienda validar esas entregas mediante el encabezado X-Hub-Signature-256, generado con HMAC-SHA256 a partir del secret configurado para cada webhook.
El problema, sin embargo, no termina en el bug. El correo enviado por GitHub advierte que el secret quedó incluido por error en un header HTTP accesible al endpoint receptor, lo que abre una ruta de exposición menos visible pero cada vez más común: la observabilidad. Si el sistema que recibía los webhooks almacenaba headers completos en logs, ese valor pudo haber quedado registrado y disponible para cualquiera con acceso a esos registros. Las propias guías de GitHub recomiendan usar webhook secrets precisamente para autenticar las entregas y evitar confiar en el origen sin verificación criptográfica.
Más allá del caso puntual, el episodio ilustra un problema estructural que empieza a repetirse en los servicios conectados por automatizaciones. La seguridad ya no depende solo de proteger una cuenta humana, sino de administrar una red de identidades de máquina: webhook secrets, tokens OAuth, claves efímeras, apps conectadas y sistemas que ejecutan acciones de manera automática. Cuando uno de esos elementos queda expuesto, aunque sea por unos minutos o en un campo no previsto, el riesgo puede desplazarse hacia logs, pipelines de despliegue, contenedores, integraciones SaaS o repositorios enlazados entre sí. GitHub, de hecho, insiste en que los webhooks deben configurarse con secrets aleatorios y verificarse del lado del receptor, mientras que para otras integraciones recomienda prácticas de permisos más finos y autenticación más acotada.
La pregunta que queda abierta no es solo por qué ocurrió el bug, sino por qué la notificación pública a los usuarios afectados llegó meses después de la ventana principal del incidente y tres meses después de la corrección. Con la información disponible, no hay evidencia para afirmar una intrusión general o una toma de cuentas, pero sí para concluir que el caso revela un punto débil en la arquitectura actual de servicios conectados: una sola credencial técnica, incluso una diseñada solo para verificación, puede convertirse en una vía de riesgo si queda expuesta en sistemas que registran, replican o reutilizan información de forma automática.
