Git
4 artículos con esta etiqueta
GitLab CVE-2026-110264 (CVSS 10.0) y la CVE-2026-97229 explotada: cómo comprobar y actualizar un GitLab autogestionado
El 21 de octubre de 2026, GitLab publicó las versiones de parche crítico 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 y 18.11.13 para Community Edition (CE) y Enterprise Edition (EE). La falla más grave, CVE-2026-110264 (CVSS 10.0), es un desbordamiento de entero al compilar una expresión regular especialmente diseñada que, bajo ciertas condiciones, podría permitir a un usuario no autenticado ejecutar código arbitrario en el servidor de GitLab. Casi todas las versiones desde la 7.0 están afectadas. El 29 de octubre, CISA añadió una falla hermana, CVE-2026-97229 (CVSS 10.0, CWE-190), a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), con fecha límite del 1 de noviembre. Es el mismo tipo de fallo (un desbordamiento de entero en el compilador de expresiones regulares de CI/CD, alcanzable por un usuario no autenticado); GitLab la corrigió antes, el 12 de octubre, en 19.4.2, 19.3.5 y 19.2.8, y afecta solo a 19.2.0 a 19.2.7, 19.3.0 a 19.3.4 y 19.4.0 a 19.4.1. Quien siga por debajo de 19.4.2, 19.3.5 o 19.2.8 está expuesto a una falla explotada. Actualizar a las versiones recomendadas aquí (19.5.1, 19.4.3, 19.3.6, 19.2.9) también corrige CVE-2026-97229. GitLab.com ya está parcheado; las instalaciones autogestionadas deben actualizarse. La misma versión del 21 de octubre corrige dos fallas de gravedad alta (CVSS 8.2 y 7.5) y otras, pero esas correcciones solo llegan en las líneas 19.3.6, 19.4.3 y 19.5.1. La causa raíz está en el motor de expresiones regulares de Ruby (Onigmo), y Ruby publicó 4.0.9, 3.4.12 y 3.3.13 el 23 de octubre. Las aplicaciones que compilan una regexp a partir de cadenas controladas por un atacante están afectadas, y Regexp.timeout no protege contra estos fallos. Los avisos de GitLab no dicen que CVE-2026-110264 se haya explotado, y no figura en KEV a 30 de octubre. Alpine Linux informó de un intento de ataque contra su propio GitLab mediante CVE-2026-97229 el 20 y 21 de octubre, y de que actualizar solo GitLab (a la 19.3.6) no cerró la falla porque la corrección también necesitaba un Ruby parcheado; reconstruyó la instancia y no encontró pruebas de que se ejecutara código del atacante. Conclusión de este sitio: actualice hoy el GitLab autogestionado tras revisar las paradas obligatorias de actualización, termine en la 19.3.6 o posterior y, si compila GitLab usted mismo o usa su propio Ruby, compruebe que ese Ruby sea también 3.3.13, 3.4.12 o 4.0.9 o posterior. Las aplicaciones Ruby deben pasar a un Ruby corregido y dejar de construir regexps a partir de la entrada del usuario.
Configurar la autenticación en dos pasos (2FA) de GitHub: app de autenticación, llaves de acceso, códigos de recuperación y qué hacer si pierdes el móvil
Guía para configurar la autenticación en dos pasos (2FA) en GitHub y no quedarte fuera. Desde marzo de 2023, GitHub exige el 2FA, grupo a grupo, a los usuarios que contribuyen código en GitHub.com; una vez seleccionado, tienes un periodo de inscripción de 45 días y un periodo de gracia de 7 días, tras el cual no puedes usar GitHub.com hasta activar el 2FA. GitHub Docs recomienda una app de autenticación TOTP como método principal y una llave de acceso (passkey) o una llave de seguridad como respaldo (las llaves de acceso, las llaves de seguridad y GitHub Mobile solo se pueden añadir después de configurar TOTP o SMS). La opinión de este sitio: el fallo habitual del 2FA en GitHub no es que te roben la cuenta, sino quedarte fuera tú mismo, y el soporte de GitHub no puede restaurar una cuenta cuyas credenciales de 2FA y métodos de recuperación se han perdido todos. Guarda los 16 códigos de recuperación en un gestor de contraseñas y registra un segundo método el mismo día. Ya que estás, pasa a tokens fine-grained con caducidad, depura las apps autorizadas y las claves SSH, y revisa la push protection y las alertas de Dependabot.
Detén los secretos antes de hacerles commit con gitleaks: atrapa fugas de claves de API antes del push
Los secretos no se pueden «borrar después de que se filtran». Una vez con commit, un secreto se queda en el historial de Git, y una vez con push debe tratarse como filtrado — la clave necesita revocarse/rotarse. gitleaks es una herramienta gratuita que escanea todo el repo y el historial de commits con regex/entropía para encontrar claves de API, claves privadas y tokens. El núcleo de la defensa son dos comprobaciones: un hook de pre-commit que lo detiene localmente antes del push, y CI/cron que atrapa lo que se cuela. .gitignore solo evita el nuevo seguimiento — no puede detectar, así que aún necesitas un escáner.
Git autoalojado vs GitHub: ¿cuál es realmente más seguro?
Autoalojar Git no te hace 'más seguro' — reubica el riesgo. La clase de exposición pública accidental desaparece, pero parchear el servidor, las copias de seguridad y la detección de secretos pre-commit pasan a ti. La decisión correcta si sigues haciendo ese trabajo; peor que GitHub si lo descuidas. La visión de este sitio: el autoalojamiento solo funciona acompañado de sus controles compensatorios.