El parche de GitLab vivía en Ruby: Alpine actualizó y siguió vulnerable

Interpretación: en estos tres casos la corrección existe, pero vive en una capa que el operador no actualiza al aplicar 'el' parche: el Ruby empaquetado de GitLab, el bundle de certificados que leen las herramientas de macOS y el firmware de cada fabricante. No comparten causa ni incidente; lo común es el hueco entre publicar una corrección y comprobar que llega a la capa que se ejecuta. La métrica útil es qué versión de cada componente corre de verdad. Muestra una forma de fallo que el aviso de actualizar a la última versión no cubre. El operador hizo una actualización documentada, subió a 19.3.6, y siguió vulnerable porque la corrección no estaba en el código de GitLab sino en un componente que el paquete oficial parcheaba y su imagen no. Interpretación: para quienes alojan su propio GitLab, repositorios, secretos de CI y tokens están en juego, y el trabajo real es verificar qué versión de cada dependencia ejecuta el sistema. Qué vigilar: Antes del 2026-11-12, comprobar tres cosas: si GitLab actualiza sus notas o documentación para quienes compilan desde fuente y deben actualizar Ruby, y si CISA añade CVE-2026-97229 al catálogo KEV; si Alpine reabre GitLab y completa su verificación hasta el 27 de octubre; y si aparece una versión estable de EDK II con el PR 13302 y una actualización de macOS que corrija /etc/ssl/cert.pem. Descodificado: hay noticias, y luego está lo que significan. Sigue Descodificado en tu plataforma para recibir el próximo episodio.