Semaphore: Rechteausweitung von manager zu owner über eine Custom-Rollen-Slug-Kollision

Ein Konto mit der Projektrolle manager legt eine Custom-Rolle an, deren Slug mit der eingebauten Rolle manager kollidiert und die volle Berechtigungs-Bitmask trägt, und erlangt damit owner-Rechte auf dem gesamten Projekt.

Advisory-ID: TP-2026-042
Produkt: Semaphore (Open-Source-Weboberfläche und API zur Ausführung von Ansible-, Terraform-, OpenTofu- und Bash-Automatisierung)
Schwachstellentyp: Rechteausweitung durch fehlende Autorisierungsprüfung (CWE-269, CWE-863)
CVE: CVE-2026-73293
CVSS 3.1: 8.8 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Hersteller-Advisory: GHSA-cxvf-gvfq-36w2
Betroffene Versionen: <= 2.18.12 (PRO-Build mit Custom-Projektrollen)
Status: öffentlich gemeldet, noch kein Fix verfügbar
Gemeldet: 9. Juni 2026

Zusammenfassung

Semaphore ist eine Weboberfläche und API zur Ausführung von Automatisierung wie Ansible und Terraform und verwaltet den Zugriff über Projektrollen. Die Berechtigungsauflösung ermittelt die effektiven Rechte eines Mitglieds anhand des Rollen-Slugs und ersetzt die Bitmask der eingebauten Rolle durch eine Datenbank-Rolle mit demselben Slug. Der zugrundeliegende Resolver ignoriert die Projekt-ID und liefert jede Rolle mit passendem Slug, und die Validierung erzwingt weder eine Sperrliste der eingebauten Slugs noch eine Obergrenze für die Berechtigungen. Ein Konto mit der eingebauten Rolle manager darf über den Rollen-Endpunkt eine Custom-Rolle anlegen und wählt dafür den Slug manager mit der vollen Bitmask, sodass seine effektiven Rechte beim nächsten Request auf die einer owner-Rolle steigen. Ergebnis ist die vollständige Übernahme des Projekts durch ein gewöhnliches Manager-Konto mit einem einzigen authentifizierten Request. turingpoint hat die Kette Ende-zu-Ende live verifiziert und an den Hersteller gemeldet, der die Schwachstelle öffentlich bestätigt hat.

Ursache

ProjectMiddleware ermittelt die effektiven Rechte eines Mitglieds anhand des Rollen-Slugs und ersetzt die Bitmask der eingebauten Rolle durch eine Datenbank-Rolle mit demselben Slug (api/projects/project.go:49-53). Der zugrundeliegende Resolver GetProjectOrGlobalRoleBySlug(projectID, slug) ignoriert sein Argument projectID und führt select * from role where slug=? aus (db/sql/role.go:59-62), sodass jede Rolle mit kollidierendem Slug zurückgegeben wird. ValidateRole erzwingt weder eine Sperrliste der eingebauten Slugs (owner/manager/task_runner/guest) noch eine Obergrenze für die Berechtigungen (db/Role.go:10-15), sodass eine Custom-Rolle den Slug manager mit der vollen Bitmask beanspruchen kann. Die Erstellungsroute POST /api/project/{id}/roles ist nur durch CanManageProjectResources geschützt, das die eingebaute Rolle manager besitzt (api/router.go:294, :354), während die freigeschalteten Aktionen durch die owner-exklusiven Rechte CanUpdateProject/CanManageProjectUsers geschützt sind (api/router.go:364, :380). Die PRO-Custom-Projektrollen sind im PRO-Build standardmäßig aktiv, sodass die effektive Bitmask eines Managers von 5 (task=1, update=2, resources=4, users=8 ⇒ manager=5) auf 15 (owner) kippt, sobald er eine Rolle mit dem Slug manager und voller Bitmask angelegt hat.

Proof of Concept

Schematisch:

# Ein Konto mit der eingebauten Rolle manager (Bitmask 5) legt eine Custom-Rolle
# an, deren Slug mit der eingebauten Rolle manager kollidiert und die die volle
# Berechtigungs-Bitmask traegt:
POST /api/project/<id>/roles
{ "slug": "manager", "permissions": <volle Bitmask> }

# Beim naechsten Request loest die Berechtigungsaufloesung den Manager auf die
# volle Bitmask auf und behandelt ihn als owner.

Weil der Resolver die Rolle allein anhand des Slugs zurückgibt, die Projekt-ID ignoriert und weder eine Sperrliste noch eine Obergrenze prüft, werden die effektiven Rechte des Managers zu owner. turingpoint hat dies live auf dem offiziellen Image semaphoreui/semaphore:v2.18.12 (PRO, Custom-Rollen standardmäßig aktiv) bestätigt: Die owner-exklusiven Aufrufe PUT /api/project/{id} und POST /api/project/{id}/users lieferten für den Manager zunächst 403, nach dem Anlegen der kollidierenden Rolle jeweils 204, und der eigentliche Owner wurde zu guest herabgestuft.

Auswirkung

  • Vollständige administrative Kontrolle über das betroffene Projekt (owner-äquivalent).
  • Ändern der Projekteinstellungen und Löschen des Projekts.
  • Hinzufügen, Entfernen und Höherstufen von Projektmitgliedern.
  • Herabstufen oder Entfernen des rechtmäßigen Owners, erreichbar durch ein beliebiges Manager-Konto mit einem einzigen authentifizierten Request.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.