Lightdash: Die niedrigste Projektrolle fuehrt beliebiges SQL im Data-Warehouse aus

Die Metrik-Abfrage uebernimmt SQL aus der Anfrage, obwohl rohes SQL anderswo an Rechte gebunden ist, die diese Rolle nicht traegt.

Advisory-ID: TP-2026-093
Produkt: Lightdash (Business-Intelligence-Oberflaeche fuer dbt, TypeScript)
Schwachstellentyp: SQL-Injektion durch fehlende Rechtepruefung (CWE-89)
CVE: beantragt (GitHub CNA), Vergabe ausstehend
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
Betroffene Versionen: < 1.99.0
Hersteller-Advisory: GHSA-cvfj-75gm-6vfw
Behoben in: 1.99.0
Gemeldet: 13. Juni 2026

Zusammenfassung

Lightdash stellt kuratierte Auswertungen bereit, damit Fachnutzer Zahlen ansehen koennen, ohne selbst SQL zu schreiben. Rohes SQL ist an die Rechte manage:SqlRunner und manage:CustomSql gebunden, die das Rollenmodell nur an Entwickler und Administration vergibt. Die Endpunkte fuer Metrik-Abfragen uebernehmen jedoch die Felder customDimensions[].sql und additionalMetrics[].sql direkt aus der Anfrage in die Abfrage an das Data-Warehouse, und die einzige Pruefung auf diesem Weg ist ein Leserecht auf die Auswertung. Damit fuehrt die Rolle interactive_viewer, die niedrigste interaktive Projektrolle, beliebiges SQL gegen die Warehouse-Verbindung aus. Auf der geprueften Instanz lief diese Verbindung mit Superuser-Rechten der Datenbank.

Ursache

Der gemeinsame Compiler, der von runAsyncMetricQueryWithoutPermissionCheck aus erreicht wird, bettet die aus der Anfrage stammenden Zeichenketten customDimensions[].sql und additionalMetrics[].sql ohne jede Rechtepruefung auf ihren SQL-Inhalt in die Warehouse-Abfrage ein (packages/backend/src/services/AsyncQueryService/AsyncQueryService.ts:4026). Sowohl der aktuelle Endpunkt POST /api/v2/projects/{projectUuid}/query/metric-query als auch der veraltete, aber weiterhin eingebundene POST /api/v1/projects/{projectUuid}/explores/{exploreId}/runQuery leiten die Felder in diesen Compiler. Die einzige Autorisierung auf dem Pfad ist ein Leserecht auf das Subjekt Explore, nicht die Rechte, die rohes SQL sonst verlangt. Im Quelltext existiert eine eigene Fehlerklasse fuer genau diesen Fall, die jedoch nie aufgerufen wird, was auf eine entfernte Schranke hindeutet. Die Rollen interactive_viewer und editor erhalten Nutzer bei der normalen Einladung oder ueber den automatischen Beitritt per Mail-Domaene.

Proof of Concept

# Als Konto mit der Projektrolle interactive_viewer:
POST /api/v2/projects/<projectUuid>/query/metric-query
{
  "customDimensions": [
    {"id": "x", "name": "x", "table": "t",
     "sql": "(SELECT current_user)"}
  ],
  ...
}

# Die Zeichenkette wird unveraendert in die Warehouse-Abfrage eingebettet
# und als SQL ausgefuehrt; die Rechte manage:SqlRunner und
# manage:CustomSql werden auf diesem Weg nie geprueft.

Derselbe Inhalt wird abgelehnt, sobald er ueber den SQL-Runner eingereicht wird, denn dort greift die Rechtepruefung. Nicht betroffen sind Konten ohne Projektzugriff und die reine Rolle viewer, die keine Ad-hoc-Abfragen ausfuehren darf.

Auswirkung

  • Ausfuehrung beliebigen SQL gegen die Warehouse-Verbindung des Projekts durch die niedrigste interaktive Projektrolle.
  • Lesen jeder Tabelle, die diese Verbindung sieht, und damit Umgehung der kuratierten Auswertungen, die die Rolle gerade begrenzen sollen.
  • Schreibender Zugriff und Loeschen von Daten, soweit die Warehouse-Verbindung das zulaesst, auf der geprueften Instanz als Superuser der Datenbank.
  • Zwei Wege zur selben Luecke, da auch der veraltete v1-Endpunkt weiterhin eingebunden ist.

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.

Pentest anfragen