Qué es el subdomain takeover en GitHub Pages
Un subdomain takeover ocurre cuando un subdominio sigue apuntando por DNS a un servicio externo, pero ese recurso ya no está correctamente reclamado o activo en la plataforma. Un atacante puede crear contenido en ese servicio y asociarlo al subdominio abandonado.
En GitHub Pages, el riesgo aparece cuando un subdominio tiene un registro CNAME hacia una página de GitHub Pages, el sitio o repositorio se borra o deshabilita, y el dominio no está verificado. GitHub documenta explícitamente este riesgo en su documentación oficial: si un sitio de Pages está deshabilitado pero el dominio personalizado sigue configurado en DNS, existe riesgo de takeover.
Cómo ocurrió el incidente: caso real documentado
El autor del artículo original relata cómo su dominio fue vulnerado mediante una configuración incorrecta de DNS wildcard en GitHub Pages. Terceros pudieron crear subdominios maliciosos bajo su dominio porque:
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad- El DNS wildcard (
*.dominio.com) resolvía a GitHub Pages - El dominio no estaba verificado en GitHub
- No había control sobre qué repositorios podían usar ese dominio
Este no es un caso aislado. Mozilla documentó un caso similar en 2016 sobre *.fxosapps.org (Bugzilla #1267546), donde un registro DNS apuntaba a GitHub y el subdominio pudo ser reclamado por un atacante.
Por qué los DNS wildcard aumentan el riesgo
Un wildcard DNS puede ser conveniente para equipos técnicos, pero amplifica el impacto de un misconfiguration:
- Cualquier subdominio no previsto puede resolver a una aplicación o hosting compartido
- Si ese wildcard apunta a GitHub Pages u otro SaaS, un subdominio 'huérfano' puede ser reclamado por un tercero
- Puede facilitar phishing, robo de cookies y abuso de confianza visual
Un wildcard no crea el takeover por sí mismo. El problema aparece cuando el wildcard sigue resolviendo a un servicio que ya no tiene control fuerte sobre la asignación del subdominio o cuando el dominio no está verificado.
¿Qué significa esto para tu startup?
Si tu startup usa GitHub Pages para marketing, documentación o landing pages, este incidente tiene implicaciones directas. Un takeover en un subdominio corporativo puede usarse para phishing con apariencia legítima, distribución de malware, o captura de credenciales si el usuario confía en el subdominio.
Acciones concretas para proteger tu startup:
- Verifica tu dominio en GitHub Pages hoy mismo. Es la medida principal que recomienda GitHub. La verificación comprueba que controlas el dominio y previene que otros usuarios de GitHub lo reclamen para sus Pages.
- Elimina o corrige DNS al deshabilitar Pages. Si Pages se apaga, no dejes CNAME, A o AAAA apuntando al servicio. Actualiza DNS inmediatamente.
- Audita tus registros wildcard. Revisa
*.tudominio.com, identifica subdominios huérfanos y mapea qué servicio controla cada uno. - Mantén un inventario de subdominios. Lista de subdominios activos, responsables y propósito. Define un dueño interno para el dominio y sus subdominios.
- Crea un checklist de offboarding. Si se elimina un repo, cambia el proveedor o se migra la web, entonces se actualiza DNS y se verifica el estado de Pages.
Cómo verificar tu dominio en GitHub Pages
GitHub separa dos conceptos: configurar un dominio personalizado en Pages y verificar el dominio como control adicional. Según la documentación oficial:
- GitHub comprueba que controlas el dominio mediante un registro TXT o CNAME específico
- Los subdominios inmediatos también quedan protegidos tras la verificación
- La verificación evita que otros usuarios de GitHub usen tu dominio con sus repositorios
Proceso recomendado: accede a la configuración de tu repositorio en GitHub, ve a Pages > Custom Domain, agrega tu dominio y sigue el proceso de verificación. GitHub te indicará qué registros DNS agregar en tu proveedor de dominio.
Casos similares documentados en el ecosistema
El problema ha sido suficientemente común como para aparecer en múltiples fuentes verificables:
- Repositorio can-i-take-over-xyz (EdOverflow) recopila patrones de subdomain takeover, incluyendo GitHub Pages específicamente
- Mozilla Bugzilla #1267546 documenta un takeover real sobre
*.fxosapps.org - Múltiples writeups técnicos y guías de bug bounty incluyen GitHub Pages como vector de ataque común
No existe una estadística pública consolidada que cuente todos los incidentes de GitHub Pages takeover porque muchos se reportan en bug bounties o issues aislados. Pero el riesgo está oficialmente reconocido por GitHub en su documentación.
Recomendaciones para founders hispanohablantes
En el ecosistema startup latino y español, muchas empresas usan GitHub Pages por su gratuidad y facilidad. Pero la seguridad no puede ser un afterthought:
- Usa un dominio principal y un www controlado en lugar de depender de wildcards globales
- Documenta qué subdominios son de producto, marketing o docs
- Habilita revisiones trimestrales de DNS como parte de tu operación técnica
- Configura alertas por expiración de dominios y cambios de NS/CNAME
La mitigación más sólida es combinar verificación de dominio en GitHub Pages, limpieza de DNS al retirar servicios, inventario de subdominios y monitorización continua.
Fuentes
- https://meertens.dev/blog/github-enables-domain-abuse/ (fuente original)
- https://docs.github.com/en/pages/verifying-your-custom-domain (documentación oficial GitHub)
- https://docs.github.com/en/pages/about-custom-domains (documentación oficial GitHub)
- https://github.com/EdOverflow/can-i-take-over-xyz (repositorio de referencia)
- https://bugzilla.mozilla.org/show_bug.cgi?id=1267546 (caso Mozilla documentado)
- https://dev.to/c4ng4c31r0/github-subdomain-takeover-3j6k (análisis técnico)
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
