Marimo GHSL-2026-226: TOCTOU en el flujo de versiones de prueba

Una carrera de marcas de tiempo en el mismo segundo permitía que una actualización de pull request superara la aprobación de prueba del mantenedor y llegara a los trabajos de publicación de TestPyPI y npm. El workflow vulnerable se eliminó; no se asignó un CVE.

💡 Explicación en Lenguaje Sencillo (ELI5)

Un responsable de laboratorio aprueba una muestra, pero el laboratorio solo comprueba el segundo del reloj. Si alguien cambia la muestra durante ese mismo segundo, la sustituta parece aprobada. El workflow de Marimo cometió ese error con un commit de pull request y llevó el paquete compilado a trabajos de publicación.

Conceptos Clave y Términos

TOCTOU: Time-of-check to time-of-use: un recurso cambia después de una comprobación de seguridad y antes de utilizarse.
Publicación mediante OIDC: Un trabajo de CI intercambia una identidad de GitHub Actions por credenciales temporales del registro de paquetes, sin guardar una contraseña de larga duración.
Artefacto del workflow: Conjunto de archivos transferido entre trabajos de GitHub Actions. Un trabajo posterior debe tratar como entrada no confiable los artefactos de workflows no confiables.
GHSL-2026-226: Identificador del advisory de GitHub Security Lab para este fallo del workflow de Marimo. El advisory no asignó un CVE.
CWE-367 / CWE-829: El advisory identifica una carrera de comprobación y uso y la ejecución de funcionalidad de una esfera de control no confiable.

Mapeos de marcos

Referencia CWE para la debilidad descrita en esta guía: CWE-367 CWE-829

Flujo de Ataque Paso a Paso

Paso 1

Un mantenedor autoriza una versión de prueba

Un mantenedor comenta en un pull request para iniciar el workflow de versiones de prueba de Marimo. La autorización debía corresponder al estado revisado del pull request.

Paso 2

El head del pull request cambia en el mismo segundo

El workflow compara pushed_at del repositorio con created_at del comentario después de convertir ambos a segundos enteros. Un push en el mismo segundo produce valores iguales.

Paso 3

La comprobación vulnerable acepta la igualdad

El workflow eliminado solo rechazaba pushed_at estrictamente posterior a la hora del comentario. La igualdad pasaba y se registraba el commit actualizado.

Paso 4

Código no confiable compila artefactos de paquete

El trabajo hacía checkout de ese commit y ejecutaba actions y scripts de compilación controlados por el repositorio. Los resultados se subían como artefactos y los consumían trabajos posteriores de publicación sin reconstruirlos desde un commit de confianza.

Paso 5

La autoridad de publicación alcanza la salida no confiable

Los trabajos de TestPyPI y npm usaban permisos de publicación OIDC. El advisory explica que el artefacto podía llegar a publicarse; no informa de que se comprometiera un paquete real.

Código Fuente: Vulnerable vs. Seguro

GHSL-2026-226 indica que el workflow vulnerable se eliminó en la PR #10765; esto no afirma que el proyecto aplicara el cambio de comparador mostrado. La comprobación anterior usaba -gt, por lo que aceptaba marcas de tiempo enteras iguales. El control ilustrativo -ge rechaza la igualdad, pero es más sólido vincular la aprobación al commit exacto revisado. Separe las compilaciones no confiables de los trabajos OIDC, reconstruya desde el SHA autorizado y valide la procedencia antes de publicar. No se incluye ningún payload de explotación.

IMPLEMENTACIÓN VULNERABLE

# Workflow marimo-bot eliminado: comparación en segundos enteros
if [[ $(date -d "$pushed_at" +%s) -gt $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# Se comprobaba el head_sha resultante y los artefactos
# pasaban a trabajos de publicación separados.

PARCHE SEGURO Y ROBUSTO

# Control ilustrativo; GHSL informa que se eliminó
# el workflow vulnerable en vez de parchearlo.
if [[ $(date -d "$pushed_at" +%s) -ge $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# Diseño más sólido: autorizar un SHA inmutable revisado, compilar
# desde él en un trabajo de confianza y publicar salidas verificadas.

Lista de Verificación de Seguridad para Ingeniería

✓Elimine o sustituya las copias afectadas del workflow marimo bot y confirme que el repositorio actual no habilita el flujo vulnerable de publicación.
✓Vincule la aprobación del mantenedor al SHA inmutable exacto del pull request y falle si cambia antes del checkout.
✓No use marcas de tiempo en segundos enteros como única prueba de que una rama mutable es la versión aprobada.
✓Compile pull requests no confiables sin credenciales de publicación; limite id-token: write a un trabajo de publicación confiable separado.
✓Reconstruya los paquetes desde el commit autorizado en el flujo confiable en lugar de promover artefactos creados por código no confiable.
✓Verifique procedencia, revisión de origen, contenido del paquete y destino antes de publicar en TestPyPI o npm.
✓Trate el advisory GHSL como evidencia de un flujo vulnerable, no como prueba de compromiso o explotación real de un paquete.