Marimo GHSL-2026-226: TOCTOU im Test-Release-Workflow

Ein Zeitstempelrennen innerhalb derselben Sekunde ließ eine Pull-Request-Änderung die Testfreigabe eines Maintainers passieren und bis zu TestPyPI- und npm-Veröffentlichungsjobs gelangen. Der anfällige Workflow wurde gelöscht; eine CVE wurde nicht vergeben.

💡 Einfache Erklärung (ELI5)

Eine Laborleitung genehmigt eine bestimmte Probe, doch das Labor prüft nur die Sekunde auf der Uhr. Wird die Probe in derselben Sekunde ausgetauscht, wirkt der Ersatz ebenfalls genehmigt. Marimos Workflow machte diesen Fehler mit einem Pull-Request-Commit und leitete das gebaute Paket an Veröffentlichungsjobs weiter.

Kernkonzepte & Begriffe

TOCTOU: Time-of-check to time-of-use: Eine Ressource ändert sich nach einer Sicherheitsprüfung und bevor das System sie verwendet.
OIDC-Veröffentlichung: Ein CI-Job tauscht eine GitHub-Actions-Identität gegen kurzlebige Zugangsdaten für eine Paketregistrierung, statt ein dauerhaftes Passwort zu speichern.
Workflow-Artefakt: Dateibündel, das zwischen GitHub-Actions-Jobs übertragen wird. Nachgelagerte Jobs müssen Artefakte nicht vertrauenswürdiger Workflows als nicht vertrauenswürdige Eingaben behandeln.
GHSL-2026-226: Kennung des GitHub-Security-Lab-Berichts zu diesem Marimo-Workflowfehler. Der Bericht vergab keine CVE.
CWE-367 / CWE-829: Der Bericht nennt ein Zeitrennen zwischen Prüfung und Nutzung sowie die Ausführung von Funktionalität aus einem nicht vertrauenswürdigen Kontrollbereich.

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-367 CWE-829

Schritt-für-Schritt Angriffsablauf

Schritt 1

Ein Maintainer genehmigt eine Testfreigabe

Ein Maintainer kommentiert einen Pull Request und startet damit Marimos Test-Release-Workflow. Die Freigabe sollte für den geprüften Zustand des Pull Requests gelten.

Schritt 2

Der Pull-Request-Head ändert sich in derselben Sekunde

Der Workflow vergleicht pushed_at des Repositorys mit created_at des Kommentars, nachdem beide in ganze Sekunden umgerechnet wurden. Ein Push in derselben Sekunde ergibt gleiche Werte.

Schritt 3

Die anfällige Prüfung akzeptiert Gleichheit

Der gelöschte Workflow wies nur pushed_at-Werte zurück, die strikt später als der Kommentar lagen. Gleichheit bestand die Prüfung und der aktualisierte Commit wurde gespeichert.

Schritt 4

Nicht vertrauenswürdiger Code erstellt Paketartefakte

Der Job checkte diesen Commit aus und führte repositorygesteuerte Actions und Build-Skripte aus. Die Ergebnisse wurden als Artefakte hochgeladen und von nachgelagerten Veröffentlichungsjobs übernommen, ohne sie aus einem vertrauenswürdigen Commit neu zu bauen.

Schritt 5

Veröffentlichungsrechte erreichen die nicht vertrauenswürdige Ausgabe

Die TestPyPI- und npm-Jobs verwendeten OIDC-Veröffentlichungsrechte. Der Bericht beschreibt, dass das Artefakt bis zur Veröffentlichung gelangen konnte; er meldet keine tatsächliche Paketkompromittierung.

Quellcode: Verwundbar vs. Sicher

GHSL-2026-226 berichtet, dass der anfällige Workflow in PR #10765 gelöscht wurde; dies behauptet nicht, dass das Projekt den gezeigten Vergleich geändert hat. Die alte Prüfung nutzte -gt, daher bestanden gleiche Zeitstempel auf Sekundengenauigkeit. Das Beispiel -ge weist Gleichheit zurück, doch die Freigabe sollte an den exakt geprüften Commit gebunden sein. Trennen Sie nicht vertrauenswürdige Builds von OIDC-Jobs, bauen Sie aus der autorisierten SHA neu und prüfen Sie die Herkunft vor der Veröffentlichung. Kein Exploit-Payload ist enthalten.

VERWUNDBARE IMPLEMENTIERUNG

# Gelöschter marimo-bot-Workflow: Vergleich ganzer Sekunden
if [[ $(date -d "$pushed_at" +%s) -gt $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# Der ermittelte head_sha wurde ausgecheckt; Artefakte
# gingen an getrennte Veröffentlichungsjobs.

GEHÄRTETER SICHERHEITS-PATCH

# Nur ein Beispielschutz; GHSL zufolge wurde der anfällige
# Workflow gelöscht und nicht vor Ort gepatcht.
if [[ $(date -d "$pushed_at" +%s) -ge $(date -d "$COMMENT_AT" +%s) ]]; then
    exit 1
fi
# Stärkeres Design: geprüfte unveränderliche SHA autorisieren,
# in einem vertrauenswürdigen Job neu bauen und geprüfte Ausgaben veröffentlichen.

Checkliste für Engineering & Systemsicherheit

✓Entfernen oder ersetzen Sie betroffene Kopien des gelöschten marimo-bot-Workflows und prüfen Sie, dass das aktuelle Repository den anfälligen Veröffentlichungsweg nicht mehr aktiviert.
✓Binden Sie die Maintainer-Freigabe an die exakte unveränderliche Pull-Request-SHA und brechen Sie ab, wenn sich der Head vor dem Checkout ändert.
✓Verwenden Sie Zeitstempel mit Sekundengenauigkeit nicht als alleinigen Nachweis, dass ein beweglicher Branch der genehmigten Version entspricht.
✓Bauen Sie nicht vertrauenswürdige Pull Requests ohne Veröffentlichungszugangsdaten; beschränken Sie id-token: write auf einen separaten vertrauenswürdigen Veröffentlichungsjob.
✓Bauen Sie Pakete im vertrauenswürdigen Veröffentlichungsweg aus dem autorisierten Commit neu, statt Artefakte aus nicht vertrauenswürdigem Code zu übernehmen.
✓Prüfen Sie Herkunft, Quellrevision, Paketinhalt und Ziel vor einer Veröffentlichung auf TestPyPI oder npm.
✓Behandeln Sie den GHSL-Bericht als Nachweis eines anfälligen Pfads, nicht einer tatsächlichen Paketkompromittierung oder Ausnutzung.