Gültige, bisher unbekannte Meldungen aus unserem Bug-Bounty-Programm. Zusammenfassungen erscheinen nach der Behebung, solange ein bestätigter Punkt noch offen ist, oder wenn wir das Verhalten nicht ändern. Tokens, Personendaten und Exploit-Schritte veröffentlichen wir nicht.
CWE-915 · CWE-639 · CWE-22 — CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes) deckt die verworfene Read-only-Liste ab. CWE-639 (Authorization Bypass Through User-Controlled Key) deckt ab, dass uid und home nicht an das besitzende Konto gebunden waren. CWE-22 (Path Traversal) deckt ab, dass Agent und Scanner den gespeicherten Home-Pfad verarbeiteten.
PATCH /systemuser/<id>/ nahm uid und home aus dem Request-Body entgegen und speicherte sie. SystemUserSerializer deklarierte das Read-only-Tupel als read_only_field, ohne das «s». DRF liest read_only_fields und prüft unbekannte Meta-Optionen nicht, deshalb wurde das Tupel verworfen und uid und home blieben schreibbar. Ein Root-Provisioning-Agent verarbeitete beides: er setzte den Owner des Home-Verzeichnisses auf die gespeicherte uid, schrieb authorized_keys als Root in das gespeicherte home und löschte beim Löschen das in /etc/passwd vermerkte Verzeichnis. Nichts band eines der Felder an das Konto, dem der Datensatz gehörte. Der Malware-Scanner baute seinen Pfad aus home, ohne Containment-Prüfung. POST war sicher: er nutzt einen anderen Serializer, der die Option korrekt schreibt.
Bestätigt. Als Kritisch eingestuft. S:C, weil die Auswirkung als Root auf einem separaten Worker-Host landet und die Mandantengrenze in die Dateien eines anderen Kunden überschreitet — zwei verschiedene Sicherheitsautoritäten. AC:H, weil ein Angreifer das Opfer auf demselben Host braucht und dessen Home-Pfad. C:H/I:H/A:H: Übernahme der Ownership, eine als Root geschriebene Key-Datei und rekursives Löschen des Homes eines anderen Kontos. Die Schreibweise ist korrigiert, sodass uid, home, name und die übrigen Felder beim Update wieder read-only sind. Ein Feld, das sowohl an der Klasse deklariert als auch in read_only_fields gelistet ist, blieb selbst mit korrekter Schreibweise schreibbar, weil DRF diese Option nur auf generierte Felder anwendet; der gemeinsame Basis-Serializer erzwingt nun Read-only für jeden gelisteten Namen. Das schloss auch eine Schwesterlücke: ein Kunde konnte Disk- und RAM-Limits der eigenen Systemgruppe über den Plan anheben. Ein projektweiter Durchgang fand keine weitere Falschschreibung; die übrigen Fälle, in denen ein Feld deklariert und zugleich als read-only gelistet war, wurden geprüft. Follow-ups: der Agent soll home aus der zugeteilten Identität ableiten, und der Scanner-Pfad soll im eigenen Verzeichnis des Kontos bleiben. Der Fix ging am selben Tag in Produktion; eine Nachhärtung ging in 2.38.1 raus.
Kommandoinjektion in POST /systemuser/<id>/recovery/
CWE-78 · CWE-88 — CWE-78 (OS Command Injection) deckt ab, dass dst von der Login-Shell des Nodes expandiert wurde. CWE-88 (Argument Injection) deckt ab, dass ein Client-Pfad als rsync-Option oder Operand gelesen wurde.
POST /systemuser/<id>/recovery/ nahm den dst-Pfad entgegen, und der Backup-Agent übergab ihn an rsync als Remote-Operand. rsync führt die Gegenseite über die Login-Shell des Nodes aus, deshalb wurden Metazeichen in dst expandiert und auf dem Node als Root ausgeführt. Die Ausführung lag auf dem Node, dem der System-User zugeordnet ist, nicht auf dem Backup-Host. Das ist ein eigener Defekt: eine Shell-Zeichenkette aus einem vom Client gelieferten Pfad. Die Ablehnung von .. ist eine separate Kontrolle.
Bestätigt. Als Hoch eingestuft. S:U, weil Panel, Backup-Agent und Nodes eine administrative Autorität sind. Die Egress-Firewall des Nodes wies nachfolgende ausgehende Verbindungen ab, deshalb konnte keine zweite Stufe und keine interaktive Shell geöffnet werden. Das ist ein Umgebungsfaktor und ändert den Basis-Vektor nicht. Behoben. Der Pfad-Validator für Recovery, Scan und Backup lehnt nun alles ausserhalb eines strengen Zeichensatzes ab: keine Shell-Metazeichen, kein .. und kein führender Bindestrich. Das Ziel bleibt im eigenen Home des Kontos. Veröffentlicht als 2.38.10. Der Backup-Worker prüft jeden Operanden und übergibt Pfade an rsync als Argumente, mit --protect-args und einem -- Trenner. scan.path nutzt denselben Validator und erreicht keine Shell mehr.
Symlink-Verfolgung in POST /systemuser/<id>/recovery/
CWE-61 · CWE-22 — CWE-61 (UNIX Symbolic Link Following) deckt ab, dass der Snapshot einen vom Mandanten angelegten Symlink in ein fremdes Home auflöste. CWE-22 (Path Traversal) deckt ab, dass die Wiederherstellung das Verzeichnis des anfragenden Benutzers verliess.
POST /systemuser/<id>/recovery/ folgte einem Symlink, den der Mandant im eigenen Home angelegt hatte. Ein nächtlicher Snapshot erfasste diesen Link. Bei der Wiederherstellung zeigte die Quelle zurück in denselben Snapshot, aber unter das Home eines anderen Mandanten. Die Eingrenzung verlangte nur, dass der aufgelöste Pfad unter der Snapshot-Wurzel bleibt, und diese Wurzel enthält das Home jedes Mandanten. Home-Pfade sind vorhersehbar, deshalb lässt sich ein Nachbar gezielt ansprechen. Der Lesezugriff blieb auf weltweit lesbare Dateien beschränkt.
Bestätigt. Als Hoch eingestuft. S:C, weil die Daten einem anderen Kunden gehören als dem Konto, das die Anfrage stellt. Der bestätigte Effekt ist ein Lesezugriff, deshalb sind Integrität und Verfügbarkeit unberührt. Jeder Mandant erreicht ihn, ohne Interaktion. Die eigenen Dateien und die eigenen Symlinks im Home funktionieren weiter. Der Fix begrenzt die Quelle einer Wiederherstellung auf das eigene Home des anfragenden Benutzers innerhalb des Snapshots: der aufgelöste Pfad muss unter diesem Home bleiben, ein Link in ein benachbartes Home oder anderswohin wird abgelehnt. Auf den Backup-Servern ausgerollt. Zwei weitere Effekte im Bericht — das Lesen von Dateien auf dem Backup-Host selbst und das Anlegen von Root gehörenden Verzeichnissen ausserhalb des Home — liessen sich am aktuellen Code nicht reproduzieren. Härtungen zwischen dem 20. und 25. Oktober lehnen eine Quelle ab, die ausserhalb des Snapshots auflöst, und die Schreibseite der Wiederherstellung läuft nun als unprivilegierter System-User statt als Root.
Mandantenübergreifendes Anhängen von RabbitMQ-Zugangsdaten
CWE-639 · CWE-862 — CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). CWE-862 (Missing Authorization) ist die fehlende Besitzprüfung am Vhost.
POST /rabbitmquser/ prüfte nicht, ob der Aufrufer den im Request-Body genannten Vhost besitzt. Ein authentifiziertes Konto konnte deshalb selbst gewählte Zugangsdaten an jeden Vhost anhängen, dessen UUID es kannte.
Bestätigt und als Hoch akzeptiert. Den AMQPS-Schritt nehmen wir auf das Wort des Meldenden; wir mussten ihn nicht nachstellen. Intern haben wir Mittel erwogen, weil ein Angreifer eine Vhost-UUID braucht und der Bericht keinen Weg zeigt, eine zu beschaffen. Dieser zweite Punkt ist berechtigt, und wir haben ihn selbst geprüft statt ihn anzunehmen: die ID der RabbitMQ-Instanz ist eine UUID4-ID. Eine UUID4 hat 122 Bit Zufallsraum, deshalb ist Raten oder Enumerieren praktisch unmöglich, und ein fremdes RabbitMQ-Konto auf diesem Weg zu übernehmen ist sehr schwer. Der eine allgemein lesbare RabbitMQ-Endpunkt legt Cluster ohne ihre Vhosts offen, sodass wir auch keinen Disclosure-Pfad gefunden haben. Behoben: Zugangsdaten anhängen setzt voraus, dass der Aufrufer den Vhost besitzt.
Die Registrierungsbestätigung aktiviert ein vom Angreifer gewähltes Passwort
CWE-287 · CWE-640 — CWE-287 (Improper Authentication) deckt ab, dass ein Konto unter einem Passwort aktiviert wurde, das gewählt wurde, bevor der Inhaber des Postfachs es bestätigt hat. CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) deckt ab, dass die Zwei-Faktor-Authentifizierung den Login nach einem erfolgreichen Passwort-Reset weiterhin blockierte.
Eine Adresse, die noch kein Kundenkonto ist, kann zuerst registriert und unbestätigt gelassen werden, mit einem Passwort aus dieser Registrierung. Versucht die Person, der die Adresse gehört, später selbst ein Konto anzulegen, sagt die Seite, ein Bestätigungslink sei gesendet worden. Es kommt keine Mail an, und es gibt keine Möglichkeit, einen neuen Link anzufordern. Der einzige gültige Link ist der aus der ersten Registrierung. Ihn zu öffnen aktiviert das ausstehende Konto unter dem damals gesetzten Passwort. Zwei-Faktor-Authentifizierung, die auf diesem Konto eingeschaltet wurde, blockiert den Login auch nach einem abgeschlossenen Passwort-Reset des Inhabers. Eine Adresse mit bereits aktivem Konto ist nicht betroffen: diese Registrierung benachrichtigt den Inhaber und legt kein zweites ausstehendes Konto an. Die Kette kapert eine künftige Registrierung.
Bestätigt. Als Mittel eingestuft. AC:H, weil der Angreifer im Voraus wissen muss, dass eine bestimmte Person sich registrieren will, und genau diese Adresse zuerst registrieren muss. UI:R, weil diese Person den Bestätigungslink anschliessend öffnen muss. C:H/I:H, wenn die Kette gelingt, weil das Konto die gehostete Umgebung des Kunden steuert; A:N. Eine anonyme Registrierung speichert nun ein Passwort, mit dem man sich nicht anmelden kann. Das Öffnen des Bestätigungslinks setzt das Passwort und aktiviert das Konto, sodass die Person mit dem Postfach es wählt. Die Registrierung einer Adresse, die bereits aktiv ist, ändert das Passwort dieses Kontos nicht. Das Anlegen eines Reseller- oder Unterkontos im angemeldeten Zustand setzt weiterhin ein Passwort. Follow-ups, nicht nötig, um diesen Fund zu schliessen: die Adresse benachrichtigen, wenn Zwei-Faktor-Authentifizierung eingeschaltet oder geändert wird, und jemandem, der das Postfach nachgewiesen hat, einen Wiederherstellungsweg an der Zwei-Faktor-Authentifizierung vorbei geben; eine Option zum erneuten Senden, die für jede Adresse gleich antwortet und begrenzt ist; eine Adresse freigeben, die nach ihrem Bestätigungsfenster unbestätigt bleibt.
CWE-613 — CWE-613 (Insufficient Session Expiration) deckt ab, dass eine Delegations-Freigabe nach der Kontowiederherstellung des Inhabers gültig blieb.
Ein abgeschlossener Passwort-Reset beendete die interaktiven Sitzungen des Kontos, liess den delegierten Switch-User-Zugriff aber bestehen. Ein Delegierter behielt die volle Kontrolle, inklusive Anlegen eines SSH-Schlüssels auf dem Konto des Inhabers und Ersetzen eines Datenbank-Passworts. Delegation ist eine normale Produktfunktion und lässt sich nicht für ein Konto anlegen, auf das der Aufrufer keinen Zugriff hat. Weder der Reset-Ablauf noch die Bestätigungs-Mail noch die Konto-Oberfläche zeigten, dass die Freigabe noch aktiv war.
Bestätigt. Als Mittel eingestuft. AC:H, weil eine bereits bestehende Freigabe nötig ist; der realistische Fall ist ein ausgeschiedener Auftragnehmer. Die Reset-Seite und die Seite zum Passwortändern listen nun jedes Konto, das auf dieses Konto zugreifen kann, jeweils mit einem Kontrollkästchen, das standardmässig angekreuzt bleibt. Das Entfernen des Hakens und das Absenden des neuen Passworts löscht die Freigabe und setzt die umgeschalteten Tokens des Delegierten zurück. Die Bestätigungs-Mail listet, was noch Zugriff hat und was widerrufen wurde.
Passwortänderung widerruft bestehende Sitzungen nicht
CWE-613 — CWE-613 (Insufficient Session Expiration) deckt ab, dass ein Sitzungs-Token nach der Passwortänderung gültig blieb.
PATCH /user/<id>/ setzte ein neues Passwort, liess aber zuvor ausgestellte Sitzungs-Tokens für den Rest ihrer Laufzeit gültig. Ein vor der Änderung erfasstes Token lieferte danach weiterhin das Konto. Das alte Passwort funktionierte nicht mehr, die Änderung der Zugangsdaten war also real; es fehlte nur der Widerruf der Sitzung. Die API nennt eine Token-Laufzeit von sieben Tagen. Eine gestohlene Sitzung behielt damit vollen Kontozugriff, nachdem der Inhaber das Passwort geändert hatte — das übliche Gegenmittel. Panel-Konten können SSH-Schlüssel, System-User, Domains und Zahlungsmittel enthalten.
Bestätigt. Als Mittel eingestuft. Der Fehler gibt vollen Kontozugriff, aber nur jemandem, der bereits ein gültiges Sitzungs-Token besitzt. Deshalb ist er eine Schwäche der Sitzungsbindung und kein eigenständiger Einstieg; daher AC:H. Der Passwort-Reset widerrief Browser-Sitzungen bereits; die authentifizierte Passwortänderung tat das nicht. Eine erfolgreiche Passwortänderung widerruft nun jede Browser-Sitzung des Kontos ausser derjenigen, die die Änderung ausführt. Vom Nutzer erstellte API-Schlüssel bleiben erhalten, wie beim Passwort-Reset, damit Automatisierung weiterläuft; der Inhaber kann sie getrennt rotieren. Eine über den Browser-Login erstellte Sitzung überdauert die Passwortänderung nicht mehr. Veröffentlicht als 2.38.8.
CWE-640 · CWE-613 — CWE-640 (Weak Password Recovery Mechanism for Forgotten Password). CWE-613 (Insufficient Session Expiration) deckt ab, dass der Token nach erfolgreicher Änderung gültig blieb.
Gemeldet wurde, dass ein Passwort-Reset-Token nach einer erfolgreichen Passwortänderung nicht ungültig wurde und der Reset-Link für den Rest seiner zweistündigen Lebensdauer erneut verwendet werden konnte.
Reset-Tokens sind nun strikt einmalig verwendbar. Der Bericht hat uns zudem zu einer breiteren Prüfung des Passwort-Reset-Ablaufs veranlasst: Durchsetzung der Passwortrichtlinie auf diesem Pfad, Abmeldung bestehender Browser-Sitzungen beim Reset, Ungültigmachen älterer Reset-Links und Rate-Limiting am Endpunkt. Vielen Dank für eine klar geschriebene und reproduzierbare Meldung.
Gelöschte RabbitMQ-Zugangsdaten bleiben am Broker gültig
CWE-459 · CWE-613 — CWE-459 (Incomplete Cleanup). CWE-613 (Insufficient Session Expiration) deckt ab, dass gelöschte AMQP-Logins am Broker gültig bleiben.
DELETE /rabbitmquser/ entfernte die Zugangsdaten in der Verwaltungsoberfläche, widerrief sie am RabbitMQ-Broker aber nicht, sodass ein gelöschtes AMQP-Login weiter funktionieren konnte.
Hält. Als Mittel eingestuft. Das Löschen in der Verwaltungsoberfläche entfernte die Datenbankzeile und schickte nichts an den Broker. Der Broker strich Logins nur, wenn sie bei einem vollständigen Abgleich der Benutzerliste fehlten, deshalb blieb ein gelöschtes AMQP-Login gültig, bis jemand anderes auf demselben Cluster Zugangsdaten speicherte — auf einem ruhigen Cluster kann das lange dauern. PR:H, weil der Angreifer bereits ein funktionierendes Login für genau diesen Vhost gehabt haben muss; der Fehler ist, dass der Widerruf nicht greift, nicht dass jemand Zugriff erhielt, den er nie hatte. AC:H, weil der nächste vollständige Sync des Clusters es entfernt, eine Bedingung ausserhalb seiner Kontrolle. Solange es dauert, hat das Login volles Lesen, Schreiben und Löschen auf dem Vhost. Eine andere Ursache als der erste Fund, deshalb kein Duplikat. Eine spätere Meldung auf Vhost-Ebene hat dieselbe Ursache und denselben Fix und wird nicht extra bewertet. Ein Löschen gleicht nun die Benutzerliste des Clusters ab, sodass das Login am Broker widerrufen wird.
Kostenpflichtige Ressourcen werden vor der Zahlung bereitgestellt
CWE-840 · CWE-862 — CWE-840 (Business Logic Errors) deckt ab, dass das Konto bereitgestellt wurde, bevor der Abrechnungsstatus das erlaubte. CWE-862 (Missing Authorization) deckt die fehlende Prüfung auf Zahlung ab.
Ein System-User für ein Produkt, das noch auf die Aktivierung wartete, erhielt sofort eine funktionierende Shell sowie Live-Logins für MySQL und PostgreSQL. Der Abrechnungssatz blieb ehrlich: inaktiv, unbezahlt und schreibgeschützt, mit dem Status „Wartet auf Aktivierung“. Deaktiviert wurde das Konto erst durch den Abrechnungs-Sweep, ein Fenster von etwa 15 bis 20 Minuten. Die Auswirkung ist unbezahlte Nutzung der Produktiv-Infrastruktur. Sie erreicht keine Daten anderer Kunden und ist kein lokales Root.
Bestätigt. Als Mittel eingestuft. Ein System-User, dessen Produkt noch auf die Aktivierung wartet, wird auf dem Node nun deaktiviert angelegt, mit einer Shell ohne Login, und wird erst nutzbar, wenn das Produkt bezahlt ist. Veröffentlicht als 2.38.15. Das Formular für kostenlose Testkonten bleibt aus, solange es nicht ausdrücklich eingeschaltet wird. MySQL- und PostgreSQL-Logins entstehen erst, wenn das Produkt bezahlt ist (2.38.16). Dieselbe Zurückhaltung gilt für gekündigte und überfällige Konten, deren Datenbank-Logins ebenfalls entfernt werden (2.38.17).
Ein bekanntes Passwort verschiebt die Login-Adresse
CWE-640 · CWE-287 — CWE-640 (Weak Password Recovery Mechanism for Forgotten Password) deckt ab, dass die Passwort-Reset-Mail der umgeschriebenen Login-Adresse folgt. CWE-287 (Improper Authentication) deckt ab, dass eine Adressänderung das Passwort verlangt hat und keinen Code von einem aktiven MFA-Gerät.
Mit dem Kontopasswort haben zwei Wege die Login-Adresse an Ort und Stelle umgeschrieben. PATCH /user/<id>/ mit einem neuen Benutzernamen tat das bis 2.39.0. PATCH /email/<id>/ auf der Login-Adresse tat es weiterhin: die Adresse der Zeile wurde sofort die neue, der Benutzername folgte, und die Bestätigungsmail ging an diese neue Adresse. Die bisherige Adresse fiel vom Konto und wurde nicht benachrichtigt. Passwort-Reset-Mails gehen nur an die bestätigten Adressen des Kontos, deshalb ging nach der Bestätigung der neuen Adresse jeder Reset nur noch dorthin. Ein aktives MFA-Gerät hat einen späteren Login weiterhin gestoppt: der Reset lief durch, das Gerät blieb, und der Login verlangte den Code. Sitzungen und API-Keys bleiben bei einem Adresswechsel absichtlich gültig.
Bestätigt. Als Mittel eingestuft. PR:H, weil der Angreifer das Kontopasswort und eine Sitzung braucht, auf einem Konto ohne aktives MFA-Gerät. C:N, weil dieses Passwort das Konto bereits lesen lässt. I:H, weil die Änderung die Adresse übernimmt, an die Passwort-Resets gehen. A:H, weil der Inhaber das Konto über diese Adresse nicht mehr wiederherstellen kann und nicht benachrichtigt wird. Behoben in 2.46.0. Bevor die Login-Adresse ersetzt, entfernt oder verlassen wird, wird eine bestätigte Adresse benachrichtigt. Die Mail sagt, woher die Anfrage kam, und bittet den Inhaber, uns zu kontaktieren, wenn er die Änderung nicht selbst gemacht hat. Eine nie bestätigte Adresse wird nicht benachrichtigt, weil sie ein Tippfehler sein kann. Das Hinzufügen oder Ändern einer E-Mail-Adresse, das Speichern des Benutzerformulars und das Löschen des Kontos verlangen von einem MFA-Benutzer nun zusätzlich einen Code nach dem Passwort. Das Passwort wird zuerst geprüft, deshalb verbraucht ein falsches Passwort keinen Code. Ein Code an ein E-Mail-Gerät geht an die eigenen Adressen des Kontos, höchstens einmal pro Minute, und lässt sich nicht zum Login oder zum Einrichten eines Geräts verwenden. Konten ohne MFA bleiben unverändert. Die meisten Konten werden gefragt, weil neue Konten seit 2.38.25 standardmässig eine E-Mail-Zwei-Faktor-Authentifizierung haben. Ein Skript, das eine E-Mail-Adresse ändert, das Benutzerformular speichert oder ein MFA-Konto löscht, sendet nun den Code. Sitzungen und API-Keys bleiben erhalten: sie zu beenden würde den Inhaber abmelden, der die Änderung nicht selbst macht, und die Automatisierung der Kunden unterbrechen. Die Mail an die bisherige Adresse informiert den Inhaber. Ein separater Fund, informativ: sobald eine Adresse bereits bestätigt war, antwortete ihr Bestätigungslink auf jeden Code mit Erfolg und nannte die Adresse der Person, die den Link hatte. Er änderte keinen Zustand und gehört nicht zu dieser Kette. Der Link antwortet nun nur noch, dass die Adresse bereits bestätigt ist, und der Code wird beim Bestätigen der Adresse gewechselt. Follow-ups: PATCH /email/ auf der Login-Adresse setzt den Benutzernamen weiterhin sofort auf die neue Adresse, bevor diese bestätigt ist, anders als PATCH /user/ seit 2.39.0. DELETE /email/<id>/ verlangt weiterhin kein Passwort. Das Einrichten eines neuen MFA-Geräts verlangt weiterhin nur das Passwort.
Eine DNS-Zone kann angelegt werden, bevor die Domain delegiert ist
CWE-284 — CWE-284 (Improper Access Control) deckt ab, dass eine Zone für einen Namen angelegt werden kann, den das Konto nicht besitzt.
Ein Konto kann eine DNS-Zone und darin Einträge für einen Namen anlegen, den es nicht besitzt. Unsere autoritativen Nameserver beantworten die Zone. Ein Resolver verwendet diese Antwort erst, wenn der Registrar die Domain an ns1.wservices.ch, ns2.wservices.ch und ns3.wservices.ch delegiert. Bis dahin ändert die Zone nichts an einer Domain, die woanders delegiert ist.
Bestätigt. Als Mittel eingestuft. PR:L, weil ein Konto nötig ist. C:N. I:H, weil eine Zone, die tatsächlich delegiert ist, als DNS dieses Namens ausgeliefert wird. A:N. Wir fügen keine Besitzprüfung hinzu. Zuerst die Zone anzulegen und danach den Registrar auf unsere Nameserver zu richten, ist der normale Hosting-Ablauf. Eine TXT-Aufgabe oder eine WHOIS-E-Mail, bevor eine Zone existieren darf, würde diese Reihenfolge unterbrechen. Das nehmen wir als Abwägung hin. Eine Kante ist real: wenn der Registrar bereits auf unsere Nameserver zeigt und die Zone hier fehlt, etwa weil ein geschlossenes Konto die Delegation stehen liess, könnte jemand anders die Zone anlegen, und sie würde ausgeliefert. Wir prüfen eine Kontrolle für diesen Fall, die den normalen Ablauf vor der Delegation nicht stört. Seit dem 21. Okt. 2026 braucht das Anlegen einer Domain ein aktives Hosting-Produkt oder eine echte Zahlung, deshalb genügt ein Wegwerfkonto nicht. Das ist kein Besitzbeweis. Eine Punycode-Ähnlichkeit ist keine Kollision mit einer bestehenden Zone und keine Übernahme. Die Prüfung des dekodierten Labels gegen IDNA2008 ist eine Härtung mit niedriger Priorität und getrennt von dieser Entscheidung.
Fehlendes Rate-Limiting bei Registrierung und Passwort-Reset
CWE-770 · CWE-799 — CWE-770 (Allocation of Resources Without Limits or Throttling). CWE-799 (Improper Control of Interaction Frequency) ist die frequenzbezogene Sicht derselben Lücke.
Der Login ist begrenzt, Registrierung und Passwort-Reset waren es nicht. Die Registrierung konnte Konten anlegen und Willkommensmails ohne Limit senden; Passwort-Reset sandte bei jeder Anfrage eine Mail, sodass ein Postfach geflutet werden konnte.
Als Mittel akzeptiert. Der gemeldete Vektor bleibt unverändert. Der Schaden liegt bei Mail-Volumen und Absender-Reputation, was CVSS schlecht abbildet, weil die Auswirkung das Postfach Dritter trifft und nicht unser eigenes System; das ändert die Bewertung nicht. Der Fix ist ausgerollt. Die Registrierung kann eine einzelne Adresse nicht bombardieren — eine Willkommensmail pro Adresse — konnte aber an viele verschiedene Adressen senden; Passwort-Reset konnte ein Postfach fluten. Beide Endpunkte haben nun Rate-Limits, inklusive einer Begrenzung pro Zieladresse beim Reset, sodass IP-Rotation gegen ein Postfach nicht mehr greift. Reset-Tokens bleiben unabhängig davon strikt einmalig. Vielen Dank für eine klare, reproduzierbare Meldung; sie hat uns bewogen, die ganze unauthentifizierte Fläche um Registrierung und Passwort-Reset zu prüfen.
CWE-312 · CWE-522 — CWE-312 (Cleartext Storage of Sensitive Information) deckt ab, dass der geheime Key nach dem Anlegen zurückgegeben wurde. CWE-522 (Insufficiently Protected Credentials) deckt ab, dass dieser Key als das Konto nutzbar blieb.
API-Tokens bleiben bei einem Passwort-Reset absichtlich gültig, damit die Automatisierung der Kunden nicht bricht. GET /token/ lieferte den Key bei späteren Abrufen im Klartext, sodass das Passwort genügte, um die überlebenden, nicht ablaufenden Keys zu lesen und weiter zu nutzen. Das Token authentifiziert als das Konto und konnte Hosting-Objekte ändern.
Bestätigt. Als Mittel eingestuft. Der geheime Key wird einmal gezeigt, in der Antwort beim Anlegen, und bei jedem späteren Abruf maskiert. Eine Standard-Laufzeit und eine Möglichkeit, dass ein Token sich selbst widerruft, bleiben in Prüfung, weil sie bestehende Automatisierung betreffen.
Die eigenen Ressourcenlimits eines Systembenutzers überstimmten den bezahlten Plan
CWE-602 · CWE-770 — CWE-602 (Client-Side Enforcement of Server-Side Security) deckt Limits ab, die nur die Schieberegler im Panel im Plan hielten. CWE-770 (Allocation of Resources Without Limits or Throttling) deckt die Ressourcen ab, die vergeben wurden.
POST /systemuser/ und PATCH /systemuser/<id>/ übernahmen RAM, Speicherplatz und Prozesslimits eines Systembenutzers aus der Anfrage. Geprüft wurde nur gegen feste Grenzen, oder gar nicht, wenn ein Benutzer zu einer bestehenden Gruppe kam. Die Schieberegler im Panel enden beim Plan der Gruppe. Die API tat das nicht. Der Server wandte die eigenen Werte des Benutzers an. Bei einem X12-Plan, 2 GB RAM, 400 Prozesse und 50 GB, erhielt ein Benutzer ein Speicherlimit von 16 GiB, der Obergrenze des Agenten, 2050 Prozesse und ein Kontingent von 500 GB.
Bestätigt. Als Mittel eingestuft. PR:L, weil ein Konto mit einer Systemgruppe nötig ist. C:N. I:L, weil der Plan diese Ressourcen nicht bezahlt. A:L, weil auf einem gemeinsamen Server der Speicher und die Prozesse anderen Kunden entzogen werden. Behoben in 2.40.2. Die API lehnt ein Benutzerlimit über dem der Gruppe ab, und der Server erhält nie mehr als die Limits der Gruppe, auch für früher gespeicherte Werte. 2.46.4 erweitert das auf das Verschieben eines Benutzers in eine andere Gruppe und auf einen kleineren Plan und prüft dabei jeweils die Anzahl der Benutzer.
Konto-Endpunkte ignorierten die Berechtigungsmatrix des API-Keys
CWE-863 — CWE-863 (Incorrect Authorization) deckt ab, dass eine Zugehörigkeitsprüfung die Berechtigungsmatrix des Keys ignorierte.
Die Berechtigungsmatrix eines API-Keys galt nur für Infrastruktur-Ressourcen. Konto-Endpunkte prüften nur die Zugehörigkeit und lasen die Matrix nie, deshalb konnte ein Key mit allen Rechten auf falsch weiterhin einen SSH-Schlüssel anlegen, Profil, E-Mail-Adressen und die MFA-Geräteliste lesen, Ticket-Kategorien auflisten und Tickets öffnen. Der Ticket-Schalter stand in der Matrix und hatte keine Wirkung. OTP-Geheimnisse wurden nicht zurückgegeben. Alles Erreichte gehörte zum eigenen Konto des Key-Inhabers.
Bestätigt. Als Mittel eingestuft. Die Vertraulichkeit ist niedrig, weil ein eingeschränkter Key nur das eigene Konto seines Inhabers erreichte. Die Integrität besteht darin, dass ein heruntergestufter Key weiterhin einen SSH-Schlüssel hinterlegen und Tickets öffnen konnte. Ein Key mit Berechtigungsmatrix ist nun auf jedem Endpunkt standardmässig verweigert, einmal pro Anfrage durchgesetzt. Er erreicht eine Ressource nur, wenn die Matrix die Aktion erlaubt: einen SSH-Schlüssel anlegen braucht sshkey/add, das Profil lesen braucht profile/view. sshkey, profile, email, otpdevice, ticketcategory und ticket gehören zur Matrix, und der Ticket-Schalter greift nun. Ein Key ohne Einschränkungen und die Browser-Sitzung bleiben unverändert. Das Panel hat einen Editor für die Matrix.
Der WebSocket akzeptierte ein Browser-Token ohne das zugehörige Cookie
MittelBehobenwcenter / djangoeurope-API
Danu Fandiyana
CVSS 3.1 5.3, Mittel
CWE-287 — CWE-287 (Improper Authentication) deckt ab, dass der WebSocket ein Browser-Sitzungs-Token ohne das Cookie annahm, das REST verlangt.
Ein Browser-Login ist an zwei Geheimnisse gebunden: das API-Token und ein HttpOnly-Cookie, das zusammen damit ausgegeben wird. Die REST-Schnittstelle verlangt beide. Eine Anfrage, die ein Browser-Sitzungs-Token ohne dieses Cookie sendet, gilt als entwendetes Token, und die Sitzung wird widerrufen. Der Inhaber meldet sich erneut an. Dieser Widerruf ist beabsichtigt. Der WebSocket auf demselben Host hat ihn nicht erzwungen. Das Token allein, in der Abfragezeichenfolge oder im Subprotokoll, hat den Socket geöffnet. Der Kanal trägt Benachrichtigungen zu Support-Nachrichten dieser Sitzung. Das Token wird gegen die eigene Sitzungs-ID geprüft, deshalb wird die ID eines anderen Kontos abgewiesen. Ein vom Benutzer angelegter API-Key hat kein zugehöriges Cookie und authentifiziert sich nur über den Key, deshalb ist er nicht betroffen.
Bestätigt. Als Mittel eingestuft. Der Aufrufer muss das Browser-Sitzungs-Token bereits besitzen. Der zusätzliche Zugriff sind die Benachrichtigungen zu Support-Nachrichten dieser Sitzung, nicht die REST-Schnittstelle und nicht das Konto eines anderen. Behoben. Ein Browser-Sitzungs-Token braucht beim Handshake nun das zugehörige Cookie, dieselbe Regel wie REST. Der Browser sendet dieses Cookie bereits. Ein Token-Wert allein kann den Kanal nicht mehr öffnen. Das Token bleibt ausserdem aus der WebSocket-URL draussen, weil ein Geheimnis in einer Abfragezeichenfolge in Zugriffsprotokollen landet. Das Subprotokoll, das das Panel bereits sendet, trägt es. Das Token-Cookie des Panels bleibt für das eigene Skript des Panels lesbar, das den Authorization-Header setzen und den Socket öffnen muss. Ohne eine Stelle, an der sich Skript einschleusen lässt, ist das kein eigener Fund.
Anti-Bot-Prüfung bei der Registrierung nur clientseitig
MittelBehobendjangoeurope-Registrierung, Passwort-Reset, Testkonten und Kontaktformular
CWE-602 · CWE-804 — CWE-602 (Client-Side Enforcement of Server-Side Security). CWE-804 (Guessable CAPTCHA) ist die treffendere Zuordnung und wird zusätzlich genannt.
Die Anti-Spam-Prüfung der Registrierung liess sich vollständig im Client berechnen — kein Server-Secret, kein Nonce, kein Ablauf — und hat automatisierte Kontoerstellung nicht verhindert.
Vollständig akzeptiert. Registrierung, Passwort-Reset, Testkonto-Erstellung und das Kontaktformular verlangen nun eine serverseitig ausgestellte Proof-of-Work-Challenge, gebunden an die Anfrage: von unserer eigenen Infrastruktur signiert und scoped, mit Ablauf, einmalig verwendbar und nicht offline fälschbar. Wir nutzen selbst gehostetes Proof-of-Work statt eines Drittanbieter-CAPTCHA, also keinen zusätzlichen Auftragsverarbeiter, kein Cookie und kein Fingerprinting. Proof-of-Work ist keine harte Barriere; Rate-Limits bleiben die eigentliche Obergrenze gegen Missbrauch. Die alte clientseitige Prüfung wird in einem gestuften Schritt entfernt, sobald das neue Verfahren stabil ist. Vielen Dank für eine saubere, korrekte Meldung, die ein lange offenes Thema behoben hat.
Der Registrierungs-Endpunkt lieferte unterschiedliche Fehlermeldungen für bereits registrierte und unbekannte E-Mail-Adressen. So konnte ohne Login bestätigt werden, welche Adressen Kunden sind.
Das Orakel ist geschlossen. Anonyme Registrierung antwortet nun gleich, ob die Adresse neu oder bereits Kunde ist; ein Duplikat legt nichts an. Der Adressinhaber kann einen Hinweis erhalten, dass bereits ein Konto existiert, mit Link zur Passwort-Reset-Seite ohne Reset-Token. Vielen Dank für die Meldung zusammen mit dem Rate-Limiting-Fund.
Ein kostenloses Produkt schaltete die Domain-Erstellung frei
CWE-863 — CWE-863 (Incorrect Authorization) deckt ab, dass jedes aktive Produkt genügte, wo ein Hosting-Produkt nötig war.
Die Domain-Erstellung prüfte nur, ob irgendein aktives Produkt existierte, nicht ob es ein Hosting-Produkt war. Ein abgerechneter RabbitMQ-Vhost-Plan zum Preis null schaltete Domain-Objekte, DNS-Einträge und Mail-Weiterleitungen für einen Namen frei, zu dem das Konto keine Beziehung hatte. Die erzeugten Zonen wurden nicht ausgeliefert. Websites, Datenbanken und Postfächer verlangten weiterhin einen aktivierten Hosting-System-User.
Bestätigt. Als Niedrig eingestuft. Die Prüfung verlangt nun eine aktive SSH-Gruppe oder einen System-User, oder eine echte Zahlung mit hinterlegter Zahlungsmethode. Eine Null-Abrechnung zählt nicht mehr.
Unauthentifizierte Profilfotos mit EXIF-Standortdaten
CWE-552 · CWE-212 · CWE-459 — CWE-552 (Files or Directories Accessible to External Parties). CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer) deckt ab, dass EXIF-Standort auf der Datei blieb. CWE-459 (Incomplete Cleanup) deckt ab, dass die Datei nach dem Entfernen im Profil liegen blieb.
Profilfotos wurden unter dem Originaldateinamen gespeichert und ohne Login ausgeliefert. EXIF-Standortdaten blieben auf der Datei. Das Entfernen des Fotos im Profil löschte die Datei nicht, sodass sie erreichbar blieb.
Behoben. Als Niedrig eingestuft. Im Frontend gab es kein Formular zum Hochladen eines Profilfotos, deshalb erforderte der Upload-Pfad mehr als die Nutzung des Produkts wie ausgeliefert (AC:H). Fotos werden unter einem nicht erratbaren Namen gespeichert, EXIF-Standortdaten werden beim Upload entfernt, und das Entfernen eines Fotos im Profil löscht die gespeicherte Datei.
Kontoinhaber kann eingeschränkte API-Keys nicht widerrufen
CWE-863 · CWE-284 — CWE-863 (Incorrect Authorization) deckt ab, dass die Fähigkeiten des Ziel-Keys statt die des Aufrufers geprüft wurden. CWE-284 (Improper Access Control) deckt die Lücke im Token-Lebenszyklus ab, inklusive des Ablauf-PATCH, der gespeicherte Permissions ignorierte.
DELETE und PATCH /token/<id>/ prüften, ob der zu ändernde Key API-Keys verwalten darf, statt ob der Aufrufer das darf. Ein Key mit einem Permissions-Objekt hat dieses Flag nie, deshalb wurde der Inhaber für jeden eingeschränkten Key abgewiesen. Nur Keys mit vollem Zugriff liessen sich ändern oder löschen. Die Keys blieben nach diesen Versuchen nutzbar. Die Auswirkung blieb im zugewiesenen Scope des Keys: der Inhaber konnte ein kompromittiertes eingeschränktes Credential nicht beenden.
Bestätigt. Als Niedrig eingestuft. AC:H, weil der Angreifer bereits einen auf einem anderen Weg geleakten Key haben muss; der Bug hielt nur ein Leck offen, das der Inhaber selbst nicht schliessen konnte. Der Support konnte weiterhin jeden Key auf Anfrage löschen. Hinter dem 403 sass ein zweiter Defekt: selbst mit korrigierter Prüfung wäre ein PATCH, der nur ein neues Ablaufdatum trägt, mit "Permission option required." abgewiesen worden, weil die gespeicherten Permissions nicht berücksichtigt wurden. Beides ist behoben. Der Inhaber kann nun jeden eigenen Key ändern und löschen, unabhängig davon, was der Key selbst darf. Eingeschränkte Keys können weiterhin keine Keys verwalten. Die Regressionstests decken eingeschränkte Keys und Keys mit vollem Zugriff ab, mit und ohne Ablauf, can_manage_tokens wahr und falsch, sowie die Gegenrichtung (ein eingeschränkter Key kann Keys nicht löschen, erweitern oder anlegen). API-Keys bleiben bei einem Passwort-Reset absichtlich gültig, damit ein routinemässiges Passwort-Vergessen die Automatisierung der Kunden nicht bricht; die Mail zur Passwortänderung listet die verbleibenden Keys und bittet, unbekannte zu löschen. Für eingeschränkte Keys war genau dieses Löschen der Schritt, den dieser Fund als kaputt zeigte. Der Fix geht mit dem nächsten Release raus.
Die Backup-Liste enthielt Sicherungen von vor dem Benutzer
CWE-200 — CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) deckt ab, dass die Liste Sicherungen und nicht abgeschlossene Läufe zeigte, die das Konto nicht brauchte.
GET /backup/ lieferte jede Sicherung des gemeinsamen Servers des Aufrufers. Eine serverweite Sicherung ist der Wiederherstellungspunkt für das eigene Home eines Kunden, deshalb gehören diese Zeilen zum Konto. Die Liste enthielt ausserdem Sicherungen aus der Zeit, bevor die Benutzer des Aufrufers auf diesem Server existierten, und Läufe, die nicht zu Ende gingen. Die Liste selbst öffnet keine Sicherung.
Bestätigt. Als Niedrig eingestuft. PR:L, weil ein Konto auf diesem Server nötig ist. C:L sind die zusätzlichen Zeilen: Läufe, die nicht zu Ende gingen, und Sicherungen aus der Zeit, bevor die Benutzer des Kontos auf dem Server waren. Das Konto hatte dafür keine Verwendung. Zeitpunkte und Laufzustände von Sicherungen sind für sich genommen wenig wert, deshalb ist die Anforderung an die Vertraulichkeit niedrig. Der Basiswert ist 4.3 und der Umgebungswert ist 3.6. I:N und A:N. Der Server in der Liste ist der eigene Server des Kunden. Behoben in 2.46.4. GET /backup/ listet nun, was dieses Konto öffnen kann: die eigenen Sicherungen des Benutzers und serverweite Sicherungen, seit der Benutzer auf diesen Server kam. Eine Sicherung von davor erscheint nicht. Ein Lauf, der noch nicht zu Ende ist, kann weiterhin erscheinen. Die Zustände, die das Panel zeigt, sind abgeschlossen und unvollständig.
RAM- und Prozesslimits gelten pro SSH-Benutzer, nicht pro SSH-Gruppe
NiedrigNoch nicht behobenwcenter / djangoeurope-SSH-Hosting
CWE-770 — CWE-770 (Allocation of Resources Without Limits or Throttling) deckt ab, dass die Benutzer einer Gruppe zusammen mehr nutzen, als der Plan der Gruppe vorsieht.
Ein Plan setzt RAM und Prozesszahl einer SSH-Gruppe, und eine Gruppe kann mehrere SSH-Benutzer haben, fünf bei X12. Der Server hält jeden Benutzer für sich an die Werte des Plans. RAM ist das Speicherlimit der eigenen cgroup-Slice des Benutzers, Prozesse sind das eigene Prozesslimit des Benutzers. Nichts hält die Benutzer einer Gruppe gemeinsam, deshalb können die fünf Benutzer einer X12-Gruppe je 2 GB RAM und 400 Prozesse nutzen.
Bestätigt. Als Niedrig eingestuft. Es braucht ein Konto mit einem Plan für mehrere Benutzer. Die Gruppe nutzt mehr RAM und Prozesse, als ihr Plan bezahlt, und auf einem gemeinsamen Server kommt das von anderen Kunden. Jeder Benutzer bleibt für sich an den Werten des Plans. Noch nicht behoben, und es gibt keine schnelle Behebung. Auf unseren Servern gibt systemd jedem Benutzer eine eigene cgroup-Slice, und es gibt keine unterstützte übergeordnete cgroup, die die Benutzer einer Gruppe gemeinsam hält. Ihre Prozesse in eine einzige zu verschieben würde die eigenen Dienste der Benutzer unterbrechen. Den Plan auf die Benutzer aufzuteilen würde jedem von fünf X12-Benutzern etwa 400 MB lassen, was Kunden weit mehr schaden würde, als es jemanden schützt. Wir suchen einen Weg, eine Gruppe als Ganzes an ihren Plan zu halten, deshalb kann das in Zukunft behoben werden. Bis dahin bleibt jeder Benutzer innerhalb der Werte des Plans. Der Gesamtverbrauch jeder Gruppe wird alle 10 Minuten gemessen, und die Benutzer der Gruppe erhalten eine informierende Mail, wenn er sich einem Limit nähert oder es überschreitet. Speicherplatz ist ein Kontingent für die ganze Gruppe und ist nicht betroffen. Eigene Limits eines Benutzers über dem Plan waren ein eigener Fund, behoben in 2.40.2.
CWE-639 · CWE-472 — CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR). CWE-472 (External Control of Assumed-Immutable Web Parameter) deckt ab, dass CID und Referenz aus der URL übernommen wurden.
Die Banküberweisungsseite zeigte CID und Zahlungsreferenz aus der URL-Query, ohne zu prüfen, ob sie zum eingeloggten Konto gehören. Ein präparierter Link konnte einem eingeloggten Kunden fremde Referenz und CID anzeigen, die er auf eine echte Überweisung setzen würde.
Hält. Als Niedrig akzeptiert, nicht als Mittel. Banküberweisungen werden von Hand zugeordnet, deshalb leitet eine falsche Referenz für sich nichts um. Damit der Angriff aufgeht, müsste ein Kunde einem präparierten Link folgen und wirklich überweisen, und wir müssten den Betrag einem Konto gutschreiben, dessen Inhaber nicht zum Absender passt. Selbst dann erhält der Angreifer Guthaben im Panel, kein Geld, und die erste Reklamation über eine fehlende Zahlung deckt es auf und macht es rückgängig. I:H ist nicht haltbar: der Angreifer schreibt nirgends etwas. AC:H, weil der Erfolg von dieser manuellen Buchung abhängt — einer Bedingung ausserhalb seiner Kontrolle. Die Seite zeigt Referenz und CID nur noch, wenn sie aus einem der eigenen Rechnungsdatensätze des Users stammen; ein präparierter Link kann nichts mehr anzeigen, was der User nicht schon sehen dürfte. Vielen Dank für einen sorgfältigen Bericht, der ehrlich sagt, was er nicht sehen konnte.
CWE-201 — CWE-201 (Insertion of Sensitive Information Into Sent Data) deckt ab, dass das gesendete Passwort in die Antwort kopiert wurde.
PATCH /user/<id>/ lieferte das gerade gesendete current_password im Antwortkörper zurück. Beim Lesen desselben Objekts fehlt das Feld, deshalb hat nur der Schreibweg es gespiegelt. Das Passwort konnte danach überall liegen, wo Antwortkörper aufbewahrt werden: Server- oder Proxy-Protokolle, ein Monitor für die Anwendungsleistung oder ein Fehler-Tracker, oder ein Browser-Cache.
Bestätigt. Als Niedrig eingestuft. AC:H und PR:H, weil ein Benutzer sein Passwort auf PATCH /user/ senden musste, solange das live war, und das Zurücklesen Zugang zu diesen aufbewahrten Körpern braucht, was normalerweise Betreiberzugang zum Protokollspeicher bedeutet. C:L ist auf das begrenzt, was erfasst wurde. I:N und A:N. Behoben. Das Feld ist nur zum Schreiben und wird nie zurückgegeben.
Unauthentifiziertes GET /server/ lieferte jeden Shared Server
CWE-862 · CWE-863 — CWE-862 (Missing Authorization). CWE-863 (Incorrect Authorization) deckt ab, dass is_public als kosmetischer Filter statt als Zugriffsprüfung behandelt wurde.
Abgemeldet wandte GET /server/ die is_public-Auswahl der Startseite nur an, wenn die Query danach fragte; ohne Parameter kamen alle Shared Server. GET /server/<id>/ antwortete für einen Server, den der Picker nicht listet. ?is_public=0 lieferte die öffentliche Menge, weil der Wert nur darauf geprüft wurde, ob er wahr ist. Schreibzugriffe auf /server/ gaben bereits 401.
Hält als Bug. Als Niedrig eingestuft. Die veröffentlichten Daten enthalten Host-Key-Fingerprints sowie phpMyAdmin- und phpPgAdmin-URLs; diese Daten sind bereits öffentlich. Host-Key-Fingerprints sind von Design öffentlich: sshd schickt die Host-Keys jedem, der verbindet, und ein Fingerprint hilft einem Man-in-the-Middle nicht, einen passenden Key zu erzeugen. phpMyAdmin- und phpPgAdmin-URLs sind Login-Seiten der Kunden auf öffentlichen DNS-Namen, geschützt durch Datenbank-Zugangsdaten. Rechenzentren und Anbieter sind aus IP-Whois lesbar. Hardware, OS und Paketversionen werden Kunden gezeigt. Eine Server-ID gibt keinen Zugriff. Eingeloggte Kunden sehen von Design jeden Shared Server; die Kontoeröffnung ist offen, deshalb sparte der Bug eine Anmeldung. Der Bug umging die Auswahl der Startseite, keine Zugriffskontrolle um Informationen. Vertraulichkeit ist none (C:N): nichts in der Antwort ist eingeschränkt. Wir stufen es dennoch als Niedrig im Programm ein, weil der Endpunkt nicht tat, was der Code wollte, und der is_public=0-Fehler ein echter Defekt war. Behoben: abgemeldet sind Liste und Detail auf die Server der Startseite beschränkt; die ID eines nicht gelisteten Servers gibt 404. Eingeloggt ändert sich nichts. Beide Flags werden als Boolean gelesen. Es wurden keine Serializer-Felder entfernt. Der Fix geht mit dem nächsten Release raus.