Kurzfassung

WACRM bis einschließlich Version 0.7.0 weist mit CVE-2026-77240 eine kritische Schwachstelle auf. Der CVSS-Basiswert liegt bei 9.9 und ist damit kritisch. Authentifizierte Nutzer können ihre eigenen Berechtigungen und die Mandantenzuordnung manipulieren oder Daten aus fremden Wissensdatenbanken auslesen.

Was ist passiert?

Betroffen ist WACRM, eine selbst betreibbare CRM-Vorlage für WhatsApp. Die Schwachstelle besteht aus zwei getrennten Fehlern in der Datenbank- und Berechtigungslogik.

Zum einen erlaubt eine Row-Level-Security-Regel angemeldeten Nutzern, ihr eigenes account_role und ihre account_id zu verändern. Damit kann sich ein Nutzer mit eigentlich niedrigen Rechten selbst hochstufen oder einem anderen Mandanten zuordnen.

Zum anderen laufen zwei Datenbankfunktionen mit erweiterten Rechten und akzeptieren eine vom Aufrufer vorgegebene account_id, ohne sauber zu prüfen, ob der Nutzer überhaupt Mitglied des betreffenden Mandanten ist. Das öffnet den Weg zu unberechtigten Lesezugriffen auf Wissensdaten anderer Mandanten.

Technische Details

Die Schwachstelle wird unter CVE-2026-77240 geführt und hat einen CVSS-3.1-Basiswert von 9.9 mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Das bedeutet: Der Angriff ist über das Netzwerk möglich, die Hürden sind niedrig, ein Angreifer benötigt lediglich ein einfaches gültiges Benutzerkonto, und ein zusätzliches Zutun anderer Nutzer ist nicht nötig.

Der Wert beschreibt die technische Schwere der Lücke, nicht automatisch deren tatsächliche Ausnutzung in freier Wildbahn.

Im ersten Teil des Problems liegt der Fehler in der Datei supabase/migrations/017_account_sharing.sql. Dort erlaubt die Richtlinie profiles_update nach den veröffentlichten Angaben, dass Nutzer ihre eigene Rollen- und Mandantenbindung ändern können. Das hebelt die Trennung zwischen Rollen und Tenants aus.

Der zweite Teil betrifft die Funktionen match_ai_knowledge_fts und match_ai_knowledge_semantic in supabase/migrations/030_ai_knowledge.sql. Sie laufen als SECURITY DEFINER, also mit erweiterten Rechten der Funktionsinhaber, und prüfen nicht, ob der aufrufende Nutzer zur übergebenen account_id gehört. Dadurch können Nicht-Mitglieder Inhalte aus fremden Knowledge-Base-Beständen lesen.

Als behobene Fassung wird ein Fix über den Commit e01f7ed37184f972ace8fb2da5c3e37e56a6050f genannt. Ob darüber hinaus ein formal versioniertes Release nach 0.7.0 bereitsteht, ist hier nicht näher benannt.

Wer ist betroffen?

Betroffen sind Installationen von WACRM in Version 0.7.0 und älter. Besonders relevant ist das für Unternehmen, Agenturen und Dienstleister, die das System mandantenfähig einsetzen oder mehreren internen Teams Zugriff geben.

Das Risiko steigt deutlich, sobald normale Benutzerkonten vorhanden sind. Die Schwachstelle setzt laut CVSS kein Administratorkonto voraus, sondern nur ein einfaches authentifiziertes Konto. In gemeinsam genutzten Umgebungen ist das ein ernstes Problem, weil die eigentliche Schutzgrenze zwischen Mandanten und Rollen versagt.

Für klassische Privatnutzer ist das kaum relevant, weil WACRM ein selbst gehostetes Business-System ist.

Empfohlene Maßnahmen

Prüfen Sie zuerst, ob WACRM in Ihrer Umgebung eingesetzt wird und welche Version läuft. Alles bis einschließlich 0.7.0 sollten Sie als akut prüfungsbedürftig behandeln.

Spielen Sie den verfügbaren Fix ein beziehungsweise aktualisieren Sie auf einen Stand, der den genannten Commit enthält. Da keine separate Hersteller-URL mit Update-Hinweisen vorliegt, müssen Admins die bereitgestellten Projektartefakte und den Code-Stand ihrer Installation direkt abgleichen.

Kontrollieren Sie anschließend sofort Benutzerkonten, Rollen und Mandantenzuordnungen. Achten Sie besonders auf unerwartete Änderungen an account_role und account_id.

Überprüfen Sie Zugriffe auf Knowledge-Base-Funktionen und Datenbankabfragen rund um die betroffenen Funktionen. Wenn Protokolle vorhanden sind, suchen Sie nach Aufrufen mit fremden account_id-Werten.

Wenn ein sofortiges Update nicht möglich ist, begrenzen Sie vorübergehend den Zugriff auf WACRM auf einen kleinen, vertrauenswürdigen Nutzerkreis. In besonders sensiblen Umgebungen ist eine temporäre Deaktivierung der betroffenen Instanz die sauberere Option.

Führen Sie nach der Korrektur einen Berechtigungs-Review durch. Gerade bei Multi-Tenant-Systemen reicht ein Patch allein nicht, wenn ein Angreifer bereits Rollen verändert oder Daten anderer Mandanten eingesehen hat.

Einschätzung von CyberSecurity-News.de

Die technische Tragweite ist hoch, weil hier nicht nur eine einzelne Funktion kippt, sondern die Mandantentrennung selbst. In SaaS-nahen oder mehrmandantenfähigen Anwendungen ist das eine der heikelsten Fehlerklassen überhaupt.

Positiv ist, dass ein konkreter Fix-Commit benannt wird. Schwächer ist die Lage bei der operativen Einordnung: Ohne klar referenzierte Release-Informationen, Migrationshinweise oder offizielle Update-Anleitung bleibt für Admins unnötig viel Prüfaufwand. Für Unternehmen im DACH-Raum mit eigener Hosting-Verantwortung zählt deshalb weniger der CVSS-Wert als die Frage, ob in der eigenen Instanz unprivilegierte Konten existieren und ob Mandanten strikt getrennt sein müssen. Wenn ja, hat das Thema hohe Priorität.

Ob die Lücke bereits aktiv ausgenutzt wird, ist nicht mitgeteilt. Diese Unsicherheit sollte nicht zu Abwarten verleiten, weil die Angriffsbedingungen vergleichsweise günstig sind.

Fazit

Wenn Sie WACRM bis Version 0.7.0 betreiben, sollten Sie die Installation umgehend prüfen und den verfügbaren Fix einspielen. Danach gehören Rollen, Mandantenzuordnungen und mögliche unberechtigte Datenzugriffe auf die Prioritätenliste. Ohne diese Nachkontrollen bleibt das Risiko unvollständig adressiert.

Quellenangabe

Weiterführende Informationen bietet der NVD-Eintrag zu CVE-2026-77240.