August 2026

August 2026

Administratoren und Kontoinhaberschaft

  • Inhaber und Administratoren können die Rolle Admin nun im Rollendialog unter Kontobenutzer vergeben und entziehen, der zuvor alle Systemrollen sperrte. Die Rolle Basic bleibt fest, da jedes Mitglied sie automatisch hält.
  • Ein Konto behält immer einen Administrator: der letzten verbleibenden Administratorin die Rolle Admin zu entziehen, wird abgelehnt. Ihre eigene dürfen Sie abgeben, solange ein weiterer Administrator bleibt, und Sie werden vorher gewarnt, dass Sie sie nicht selbst zurückholen können.
  • Der Kontoinhaber kann die Inhaberschaft unter Kontobenutzer an ein anderes Mitglied übertragen und bestätigt dabei zuerst seine Identität. Der neue Inhaber erhält zugleich die Rolle Admin, und nur er kann sie zurückübertragen.
  • Ein Konto kann nicht mehr ohne Inhaber bleiben. Ein Benutzer, der eines besitzt, kann daraus nicht entfernt und nicht gelöscht werden, bis die Inhaberschaft an jemand anderen übertragen wurde.
  • Der Entzug einer Rolle schränkt nun sofort alle von der betreffenden Person erstellten API- und MCP-Tokens ein, weil die Berechtigungen eines Tokens gegen den aktuellen Besitz ihres Inhabers geprüft werden und nicht gegen den Stand bei der Erstellung.
  • Löscht ein Kontoinhaber sein Konto und bleibt kein weiteres Mitglied übrig, wird das Konto nun deaktiviert und offene Einladungen werden zurückgezogen, anstatt aktiv und leer zurückzubleiben.

Help Desk

  • Beim Erstellen eines Tickets aus einer E-Mail wird die Formatierung der E-Mail nun übernommen. Überschriften, Listen, Fettschrift, Links und Bilder kamen zuvor als reiner Text an.
  • Beim Erstellen eines Vorgangs aus einem Ticket bleibt die Formatierung der Ticketbeschreibung auf die gleiche Weise erhalten.
  • Beide Beschreibungsfelder sind nun vollwertige Rich-Text-Editoren, mit Werkzeugleiste, Tabellen, Medienbibliothek, Bild-Upload per Drag-and-drop oder Einfügen und KI-Unterstützung. Beide Dialoge sind breiter, sodass die Werkzeugleiste bequem hineinpasst.
  • Für bestehende Tickets und Vorgänge ändert sich nichts, und es ist kein Zutun erforderlich.

Ticket-Gesprächsverlauf und Sichtbarkeit im Board

  • E-Mail-Antworten von Anfragenden erscheinen nun direkt im Gesprächsverlauf des Tickets. Eine neue Workflow-Aktion, E-Mail zum Gesprächsverlauf hinzufügen, hängt die eingehende Antwort an den Verlauf des zugehörigen Tickets an, sodass Sie das Gesagte der Reihe nach neben Ihren eigenen Antworten lesen, anstatt eine verknüpfte E-Mail zu öffnen. Fügen Sie die Aktion in einem E-Mail-Workflow nach Ticket-Referenzen extrahieren ein; sie braucht keine eigene Konfiguration.
  • Jeder Eintrag wird der Person zugeordnet, die ihn gesendet hat, sodass der Verlauf deren Namen anstelle von System zeigt, und beim ersten Schreiben einer unbekannten Adresse wird automatisch ein Kontakt angelegt. Dieselbe E-Mail zweimal zu verarbeiten erzeugt niemals einen doppelten Eintrag.
  • Eine eingehende Antwort erfüllt das Ziel der Erstreaktion in Ihrem SLA nicht, denn ein Anfragender, der schreibt, ist keine Agentin, die antwortet, und der Ticketstatus ändert sich dadurch ebenfalls nicht. Wie mit Antworten umgegangen wird, legen Sie weiterhin selbst über Workflows fest.
  • Tickets, die auf Ihr Team warten, fallen jetzt im Kanban-Board auf. Antwortet ein Anfragender, erhält die Karte eine farbige Markierung und den Hinweis Anfragender hat geantwortet samt der Wartezeit dieser Antwort, sodass zwei Stunden Wartezeit anders aussehen als zwei Tage.
  • Diese Karten rücken an den Anfang ihrer Spalte, wodurch eine offene Antwort beim Überfliegen des Boards kaum zu übersehen ist. Ihre gewählte Sortierung gilt innerhalb jeder Gruppe weiterhin, sodass dieses Vorziehen Ihre Sortierung einer Spalte nie überschreibt.
  • Ein neuer Filter Antwort ausstehend beschränkt das Board darauf, was auf Ihr Team oder auf den Anfragenden wartet, und die Sortierung Letzte Antwort ordnet Tickets nach der neuesten Aktivität im Gesprächsverlauf. Beides steht auch in der Ticketliste und ihren Exporten bereit.
  • Interne Notizen gelten nicht als Antwort an den Anfragenden, sodass eine Notiz das Ticket weiterhin als offen markiert lässt. Von der Automatisierung gesendete Antworten, etwa eine vorformulierte Antwort aus einem Workflow, zählen hingegen. Bestehende Tickets wurden einbezogen, sodass das Board den tatsächlichen Stand des Gesprächsverlaufs sofort widerspiegelt.
  • Behoben, dass Tickets aus dem Kanban-Board verschwanden. Das Board lud nur die zehn neuesten Tickets und verteilte sie auf alle sechs Spalten, sodass Karten scheinbar zufällig verschwanden, sobald ein Ticket erstellt wurde oder sich die Sortierung änderte. Das Board lädt nun seinen vollen Bestand, und die Auswahl der Seitengröße in der Ticketliste wirkt, anstatt immer zehn Zeilen zu liefern. Tickets werden standardmäßig zu dreißig pro Seite angezeigt.

KI-Schreibassistent

  • Eine neue Aktion Neu formatieren im Tab Überarbeiten bringt die Darstellung Ihres Inhalts in Ordnung, ohne ein einziges Wort zu ändern. Sie teilt einen Textblock in Absätze, macht aus einer Aufzählung eine echte Liste, wandelt Zeilen, die als Abschnittstitel gelesen werden, in Überschriften um und räumt lose Formatierung auf.
  • Alle anderen Überarbeitungsaktionen verändern Ihre Worte, ob durch Kürzen, Erweitern oder Anpassen des Tons. Neu formatieren ist deshalb die Aktion, zu der Sie greifen, nachdem Sie Inhalte von anderswo eingefügt haben.
  • Die bestehenden Überarbeitungsaktionen bleiben unverändert, und Neu formatieren steht überall dort zur Verfügung, wo das KI-Unterstützungsfenster erscheint, auf Englisch, Spanisch und Deutsch.

Datenaufbewahrung (neu)

  • Unter Compliance steht nun eine Richtlinie zur Datenaufbewahrung und Entsorgung bereit, die für Geschäftsunterlagen eine Grundfrist von sieben Jahren festlegt, mit kürzeren Fristen, wo eine kürzere Frist begründet ist.

Notizen, Aufgaben und Kontakte

  • Notizen, Aufgaben und Kontakte erfassen nun, wer sie erstellt hat. Die Listen der Notizen und der Kontakte zeigen eine Spalte Erstellt von, und der CSV-Export aller drei enthält sie.
  • Ein neuer Filter Erstellt von beschränkt diese drei Listen auf die Datensätze einer einzelnen Person, mit der Option System für alles, was von einem Workflow, von einer geplanten Aufgabe oder aus einer eingehenden E-Mail stammt und nicht von einem Mitglied Ihres Teams.
  • Notizen lassen sich nun gesammelt löschen. Eine ganze Auswahl zu entfernen ist ein einzelner Vorgang, während zuvor jede Notiz einzeln gelöscht wurde.
  • Datensätze, die vor dieser Version erstellt wurden, zeigen System als Ersteller, weil damals nicht erfasst wurde, wer sie erstellt hat. An diesen Datensätzen ändert sich nichts, und es ist kein Zutun erforderlich.

Verbesserungen

  • Sammelaktionen sagen Ihnen nun, wie weit sie gekommen sind. Muss eine Aktion auf jeden Datensatz einzeln angewendet werden, bricht sie nicht mehr beim ersten Problem mit einer einzigen allgemeinen Fehlermeldung ab. Sie arbeitet die übrige Auswahl weiter ab und nennt, wie viele Datensätze verarbeitet wurden. Hat ein erreichtes Limit sie gestoppt, nennt sie zudem, wie viele übrig sind, damit Sie sie für den Rest erneut ausführen können.
  • Das gesammelte Löschen von Features und User Stories ist nun eine einzelne Anfrage statt einer pro Datensatz, was es bei einer großen Auswahl deutlich schneller macht.
  • Sie können sich nun selbst aus der Sperre wegen nicht verifizierter E-Mail befreien. Ist die Verifizierungs-E-Mail nie angekommen oder ihr Link abgelaufen, führt die Anmeldung mit E-Mail-Adresse und Passwort auf eine Seite, die anbietet, eine neue zu senden, mit Ihrer Adresse bereits eingetragen, anstatt Sie ohne Handlungsmöglichkeit auf der Anmeldeseite zurückzulassen. Ein neuer Link kann einmal pro Minute und bis zu dreimal pro Stunde angefordert werden. Beachten Sie, dass das Zurücksetzen des Passworts die Sperre nicht aufhebt, nutzen Sie also das erneute Senden statt Passwort vergessen?. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Behoben, dass Notizen nach einer Aktualisierung durch eine Automatisierung aus der Suche verschwanden. Ein Workflow, der den Inhalt einer Notiz änderte, aktualisierte den Text nicht, der für die Suche und für CSV- und PDF-Exporte verwendet wird. Eine Notiz konnte deshalb bei einer Suche nach Wörtern, die sie offensichtlich enthielt, nicht mehr gefunden werden, und ein Export konnte Text aus einer früheren Fassung zeigen. Betroffene Notizen werden beim Upgrade korrigiert.
  • Klarere Grenzen im Registrierungsformular. Die Felder Vollständiger Name und Firmenname enden nun bei 255 Zeichen und weisen darauf hin, wenn die Grenze erreicht ist, anstatt einen langen Wert anzunehmen und beim Absenden mit einer allgemeinen Fehlermeldung zu scheitern. Dieselbe Grenze gilt nun auch bei der Registrierung in der mobilen App. Bereits gespeicherte Namen sind nicht betroffen, und bestehende Nutzer müssen nichts tun.
  • Der Dialog Benutzer hinzufügen zeigt Ihnen nun vor dem Ausfüllen, wo Sie stehen. Er weist aus, welcher Teil des Benutzerkontingents Ihres Kontos belegt ist, und sagt es, sobald das Kontingent erreicht ist, samt Hinweis darauf, was dann zu tun ist, anstatt das Formular anzunehmen und erst beim Absenden abzulehnen.
  • Behoben, dass Sie abgemeldet wurden, wenn Sie nach der Registrierung mit Google Ihr erstes Passwort festlegen wollten. Ein über Google erstelltes Konto hat kein Passwort, und um eines festzulegen, werden Sie zuerst gebeten, Ihr Google-Konto zu bestätigen. Die Rückkehr von Google beendete die gerade erst erstellte Sitzung und führte Sie zurück auf die Anmeldeseite. Sich erneut anzumelden und die Schritte zu wiederholen funktionierte, weshalb es sporadisch wirkte. Konten, die per Registrierung mit Google erstellt werden, erhalten nun genau dieselbe Sitzung wie bei jeder anderen Anmeldung.
  • Behoben, dass das Verknüpfen eines Google-Kontos in den Sicherheitseinstellungen Sie erneut anmeldete, anstatt etwas zu verknüpfen. Die Auswahl Google-Konto verknüpfen führt Sie nun zu Google, fragt, welches Konto Sie verbinden möchten, anstatt das bereits angemeldete anzunehmen, und meldet nach der Rückkehr das Ergebnis. Ist Ihrem Profil bereits ein Google-Konto zugeordnet, erfahren Sie das vor dem Weg zu Google und nicht erst danach.

Sicherheit

  • Eine Rechteausweitung in der Konto- und Rollenverwaltung wurde behoben. Berechtigungen bei Anfragen auf Kontoebene wurden gegen das als aktiv markierte Konto geprüft und nicht gegen das Konto, an das sich die Anfrage tatsächlich richtete. Wer mehr als einer Organisation angehörte, konnte über eine davon administrativen Zugriff auf eine andere erlangen und sich dort sogar die Rolle Admin selbst zuweisen. Berechtigungen werden nun stets gegen das in der Anfrage genannte Konto geprüft, und Sie müssen Mitglied dieses Kontos sein. Uns extern mit einem klaren, reproduzierbaren Proof of Concept gemeldet.
  • Niemand kann mehr Befugnisse vergeben, als er selbst besitzt. Eine Rolle zuzuweisen, eine Rolle zu erstellen oder einer bestehenden Rolle Berechtigungen hinzuzufügen, wird abgelehnt, wenn dabei eine Berechtigung vergeben würde, die Sie in diesem Konto nicht haben. Eine Rolle umzubenennen oder zu beschneiden, die weiter reicht als Ihr eigener Zugriff, funktioniert weiterhin.
  • Anfragen an ein deaktiviertes Konto werden nun auch dann abgelehnt, wenn Ihr eigenes aktives Konto in Ordnung ist.
  • Behoben, dass Zahlen im Dashboard ohne die Berechtigung für den zugehörigen Bereich lesbar waren. Welche Karten im Dashboard erschienen, entschied allein der Browser, sodass die Zahlen hinter einer Karte auch von einem Mitglied gelesen werden konnten, das keinen Zugriff auf diesen Teil des Produkts hat. Jede Karte wird nun auf dem Server gegen dieselbe Berechtigung geprüft, die für den Bereich selbst gilt. Für alle, deren Rolle die Bereiche ihres Dashboards ohnehin abdeckte, ändert sich nichts. Uns extern mit einem klaren, reproduzierbaren Proof of Concept gemeldet.
  • Ein Mitglied, das einige Bereiche erreicht und andere nicht, erhält weiterhin ein funktionierendes Dashboard, das die zulässigen Teile zeigt, statt die Seite ganz zu verweigern. Karten eines abgeschalteten Bereichs liefern ebenfalls nichts mehr zurück.
  • Kontoeinladungen sind nun ratenbegrenzt, pro Administrator und pro Konto, sowohl beim Senden einer neuen Einladung als auch beim erneuten Senden einer bestehenden. Damit ist ein Weg geschlossen, auf dem das Einladungssystem für große Mengen unerwünschter E-Mails hätte genutzt werden können. Einladungen in normalem Tempo sind nicht betroffen. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Es gibt nun eine Obergrenze dafür, wie viele Benutzer ein Konto halten kann, wobei gesendete und noch unbeantwortete Einladungen mitzählen. Konten mit einem aktiven Abonnement gilt eine hohe Grenze, die kein reales Team erreicht, weil jeder hinzugefügte Benutzer ohnehin abgerechnet wird. Für Konten ohne Abonnement gilt eine deutlich niedrigere Grenze, und ein Abonnement hebt sie sofort an, ohne dass etwas angefragt werden muss. Eine Ratenbegrenzung allein begrenzte, wie schnell Benutzer hinzugefügt werden konnten, nicht aber wie viele, sodass ein Konto sie unbegrenzt anhäufen konnte. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Bestehendes ist von dieser Obergrenze nicht betroffen. Ein Konto, das bereits über seiner Grenze liegt, behält alle Mitglieder und alle Daten und kann lediglich keine weiteren hinzufügen. Erreichen Sie die Grenze, während Sie Ihr Team hinzufügen, nennt die Meldung, ob ein Abonnement nötig ist oder Sie sich an uns wenden sollten.
  • Die Anzahl der Organisationen, die eine einzelne Person anlegen kann, ist nun begrenzt, und das Anlegen ist zusätzlich ratenbegrenzt. Ohne dies hätte sich die obige Benutzerobergrenze umgehen lassen, indem eine weitere Organisation angelegt wird, anstatt die aktuelle zu füllen.
  • Die Anzahl aktiver API-Tokens, die ein Konto halten kann, ist nun begrenzt, und die MCP-Anfragelimits gelten jetzt zusätzlich pro Konto und nicht nur pro Token. Bisher hatte jedes Token sein eigenes Kontingent, sodass mehr Tokens die Gesamtmenge erhöhten, die ein Konto senden konnte. Widerrufen Sie ein nicht mehr genutztes Token, um Platz für ein neues zu schaffen.
  • Das Arbeiten in einer Organisation setzt nun ein aktives Abonnement voraus. Läuft eine kostenlose Testphase ab, oder erreicht ein gekündigtes Abonnement das Ende seines bezahlten Zeitraums, werden Anfragen nach den Datensätzen dieser Organisation abgewiesen, bis wieder ein Abonnement besteht. Bisher behielt eine abgelaufene Testphase unbegrenzt vollen Zugriff, sodass die obigen Obergrenzen zwar begrenzten, wie groß ein nicht abgerechnetes Konto werden konnte, es aber nichts zum Abschluss brachte.
  • Dabei wird nichts gelöscht. Ihre Issues, Tests, Dokumente und die Historie bleiben genau so, wie sie waren, und sind alle wieder da, sobald Sie abonnieren.
  • Was Sie brauchen, um die Lage zu klären oder zu gehen, bleibt offen: die Anmeldung, die Abrechnungsseiten und Ihr Rechnungsverlauf, der Wechsel zu einer anderen Organisation, der Sie angehören, das Ansehen und Annehmen von Einladungen, Ihr eigenes Profil und Ihre Sicherheitseinstellungen, ein vollständiger Datenexport und das Löschen des Kontos. So wird niemand von der einen Seite ausgeschlossen, die die Organisation zurückbringt, und keine Organisation muss zahlen, um an ihre Daten zu kommen. Andere Organisationen, denen Sie angehören, bleiben unberührt, denn die Sperre gilt für eine Organisation und nie für Ihren Benutzer.
  • Eine fehlgeschlagene Zahlung, die Stripe noch wiederholt, sperrt niemanden aus. Ihre Organisation arbeitet während der gesamten Kulanzfrist normal weiter, und genau das ist das Zeitfenster, um die Karte zu aktualisieren. Erst erschöpfte Wiederholungsversuche beenden den Zugang.
  • Für API-Tokens und MCP-Clients gilt dieselbe Regel mit einer Feinheit: Sie können weiterhin die ihnen verfügbaren Werkzeuge auflisten und Datensätze lesen, doch alles, was anlegen, aktualisieren oder löschen würde, wird mit einer Antwort “Zahlung erforderlich” abgewiesen. Eine Integration nennt damit klar den Grund, anstatt defekt zu wirken, und schreibt wieder, sobald das Abonnement aktiv ist, ohne dass auf ihrer Seite etwas geändert werden muss.
  • Die gesamte API hat nun ein Gesamtlimit für Anfragen pro Minute, angewendet pro angemeldetem Benutzer statt pro Standort, sodass die Aktivität einer Person eine Kollegin nicht verdrängen kann. Das Limit liegt weit über der normalen Nutzung, und die Verwaltungskonsole und die mobile App kommen ihm nie nahe. Wer eine eigene Integration entwickelt und es überschreitet, erhält einen entsprechenden Hinweis samt Wartezeit. Eingehende Webhooks von Stripe, Google Calendar und Ihren eigenen Chat- und Workflow-Integrationen sind nicht betroffen, und der MCP-Server behält sein bestehendes Limit pro Token.
  • Anfragen, die anlegen, ändern oder löschen, haben nun eigene Limits, pro Benutzer und pro Konto, zusätzlich zu diesem Gesamtlimit. Das Gesamtlimit war auf das Lesevolumen der Verwaltungskonsole ausgelegt, wodurch es als einzige Grenze für das Schreiben viel zu großzügig war: ein Skript konnte beliebig lange Datensätze anlegen, ohne es je zu erreichen. Das Lesen ist nicht betroffen, und die neuen Limits liegen weit über allem, was die Konsole oder die mobile App tun, einschließlich des Löschens einer vollen Seite von Datensätzen auf einmal. Zu erfassen, wer eine Notiz, eine Aufgabe oder einen Kontakt erstellt hat, und das neue gesammelte Löschen von Notizen gehören zur selben Arbeit: zusammen machen sie eine große Menge unerwünschter Datensätze leicht auffindbar und entfernbar, anstatt sie einzeln beseitigen zu müssen. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Es gibt nun eine Obergrenze für die Anzahl persönlicher Kalender, die Sie in einer Organisation halten können, sowie ein Tempolimit für das Anlegen von Kalendern und Terminen. Das Anlegen von Kalendern in normalem Tempo ist nie betroffen, und der Kontokalender sowie aus Google verbundene Kalender zählen nicht mit. Bisher war dies unbegrenzt, sodass ein einzelnes Konto so viele Kalender anhäufen konnte, dass die eigene Kalender-Seitenleiste nur noch langsam lud. Über unser Programm zur Offenlegung von Schwachstellen gemeldet.
  • Wir haben nach einem Hinweis über unser Programm zur Offenlegung von Schwachstellen verschärft, wie hochgeladene Dateien an den Browser ausgeliefert werden. Nur Bilder und PDFs werden nun inline angezeigt. Jeder andere Dateityp wird als Download ausgeliefert, und Dateitypen, die ein Browser als Seite oder Skript ausführen kann, etwa HTML und JavaScript, werden nicht mehr als Anhang akzeptiert. Das schließt ein Risiko für gespeichertes Cross-Site-Scripting, bei dem ein manipulierter Anhang Code im Browser ausführen konnte, und verhindert zugleich, dass von Angreifern kontrollierte Seiten für Phishing unter einer ISO Mate-Adresse gehostet werden. Die Vorschau von Bildern und PDFs sowie das Herunterladen jedes Anhangs funktionieren genau wie bisher. Wenn Sie eine Webseite oder ein Skript teilen möchten, packen Sie es in ein ZIP-Archiv.
  • Derselbe Dateischutz gilt überall dort, wo ISO Mate eine hochgeladene Datei ausliefert, einschließlich Vorgangsanhängen, Chat-Anhängen, Compliance-Nachweisen, Bildern der Medienbibliothek, E-Mail-Anhängen, Ticketanhängen und Anhängen von Testausführungen. Zuvor hochgeladene Dateien sind ebenfalls abgedeckt, weil die Einschränkung im Moment der Auslieferung greift.
  • Datei- und Bildlinks enthalten nicht mehr Ihr Zugriffstoken. Bisher schrieb das Öffnen einer Anhangsvorschau oder das Anzeigen Ihres Kontologos eine Zugangsinformation in die Adresse, wo sie im Browserverlauf und in Serverprotokollen verbleiben konnte. Die Verwaltungskonsole und die mobile App rufen die Datei nun über eine authentifizierte Verbindung ab, und die Möglichkeit, sich über einen Link anzumelden, wurde vollständig aus der API entfernt. Anhangsvorschauen, Bildanzeige und Ihr Kontologo funktionieren wie bisher.
  • Die Definitionen der Systemrollen sind über die API schreibgeschützt. Die Rollen Admin und Basic können über die API nicht mehr umbenannt werden und ihre Berechtigungen nicht mehr geändert werden, entsprechend der Einschränkung, die in der Konsole bereits galt. Diese Rollen einem Benutzer zuzuweisen, ist eine eigene Aktion und nun erlaubt.
  • Die Abrechnungsverwaltung lässt sich nicht mehr an ein API- oder MCP-Token binden. Sie war in der Berechtigungsauswahl bereits ausgeblendet und wird nun auch beim Erstellen eines Tokens abgelehnt.
  • Eine Umgehung der E-Mail-Verifizierung bei der Anmeldung mit Google wurde behoben. Die Anmeldung mit Google gewährte vollen Zugriff auf ein Konto, dessen E-Mail-Adresse nie bestätigt worden war, obwohl die Anmeldung mit Passwort dies korrekt verweigerte. Da Google die Adresse bestätigt, bevor sie an uns übergeben wird, gilt eine übereinstimmende Adresse nun als Nachweis, dass die Adresse Ihnen gehört, und das Konto wird als verifiziert erfasst. Ab diesem Zeitpunkt funktioniert auch die Anmeldung mit Passwort. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Ein Passwort, das für ein Konto mit nie bestätigter Adresse festgelegt wurde, wird nun verworfen, sobald Google diese Adresse bestätigt. Bei der Registrierung kann jeder die E-Mail-Adresse einer anderen Person eingeben, daher lässt sich ein vor der Bestätigung festgelegtes Passwort nicht der Person zuordnen, der die Adresse gehört. Falls Sie betroffen sind, bleiben Sie über Google angemeldet und werden gebeten, in den Sicherheitseinstellungen ein neues Passwort festzulegen. Betroffen sind sehr wenige, denn der Fall tritt nur auf, wenn ein Konto mit Passwort registriert, nie bestätigt und später mit Google angemeldet wurde.
  • Konten, die per Registrierung mit Google erstellt wurden, wurden als nicht verifiziert erfasst, weil der Verifizierungsvermerk beim Anlegen des Kontos verworfen wurde. Bestehende Konten wurden korrigiert und neue werden korrekt erfasst, sodass der angezeigte Verifizierungsstatus nun der Realität entspricht.
  • Ein Konto, das seine E-Mail-Adresse nicht bestätigt hat, erreicht keinen Teil der API mehr. Bisher wurde die Verifizierung nur bei der Anmeldung geprüft, dies fügt also bei jeder Anfrage eine zweite, unabhängige Prüfung hinzu. Das Abmelden und das Abrufen des eigenen Anmeldestatus funktionieren weiterhin, sodass ein unbestätigtes Konto nie blockiert bleibt.
  • Die Anmeldung mit Google ist nun an das konkrete Google-Konto gebunden, das mit Ihrem Profil verknüpft ist. Wird ein anderes Google-Konto verwendet, wird die Anmeldung abgelehnt, selbst wenn dessen Adresse mit der Adresse Ihres ISO Mate-Kontos übereinstimmt. Zuvor ließ sich das Profil mit beiden öffnen, sodass zwei verschiedene Google-Identitäten dasselbe Konto erreichen konnten, während nur eine davon als verknüpft erfasst war. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Das Ändern Ihrer E-Mail-Adresse löst nun die Verknüpfung eines Google-Kontos, das mit der verlassenen Adresse verknüpft war, und beendet Ihre übrigen Sitzungen. Diese Verknüpfung überdauerte bisher die Änderung, sodass das alte Google-Konto unbegrenzt weiter funktionierte. Am wichtigsten ist das, wenn eine Arbeitsadresse nach Ihrem Ausscheiden aus einer Organisation an jemand anderen übergeht, denn der neue Inhaber dieser Adresse könnte sich sonst weiterhin in Ihrem ISO Mate-Konto anmelden. Der Zugang über Ihr Passwort bleibt erhalten, und Sie können Google in den Sicherheitseinstellungen jederzeit erneut verknüpfen. Ein Google-Konto, das Sie absichtlich unter einer anderen Adresse verknüpft haben, bleibt unberührt.
  • Um das mit Ihrem Profil verknüpfte Google-Konto zu wechseln, muss die bestehende Verknüpfung nun zuerst gelöst werden, wofür entweder Ihr Passwort oder eine an Ihre E-Mail-Adresse gesendete Bestätigung nötig ist. Zuvor konnte die Verknüpfung ohne beides auf ein anderes Google-Konto umgestellt werden.
  • Strengere Filterung von formatiertem Text. Rich-Text wird beim Speichern nun gegen eine strikte Positivliste aus Tags, Attributen und Stilen geprüft. Die bisherige Prüfung entfernte unerwartete Tags, sah sich aber nicht an, was an den beibehaltenen Tags hing. Das betrifft jede Stelle, an der formatierter Text eingegeben wird, einschließlich Notizen, Vorgangsbeschreibungen und Kommentaren, Vorgangsvorlagen, Compliance-Richtlinien und Compliance-Verfahren, Tickets, Ticketantworten und vorformulierten Antworten. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Formatierter Inhalt wird nun ein zweites Mal im Moment der Anzeige gefiltert, einschließlich der Antworten des KI-Assistenten. Einige Ansichten zeigten gespeicherten Inhalt bisher direkt an, sodass es nun sowohl beim Speichern als auch bei der Anzeige eine unabhängige Prüfung gibt.
  • Inhalte, die vor dieser Version gespeichert wurden, werden beim Upgrade automatisch erneut geprüft. Formatierung, Bilder, Links und Tabellen bleiben erhalten, und die Bereinigung ändert keine Änderungsdaten und löst keine Benachrichtigungen oder Automatisierungen aus. Möglicherweise verschwindet dabei ungewöhnliches Markup aus älteren Datensätzen.
  • Formatierter Text, den automatisierte Workflows schreiben, wird nun genauso gefiltert. Die vorstehenden Prüfungen griffen, wenn eine Person Inhalte tippte oder einfügte, doch die Automatisierungs-Engine setzte Feldwerte direkt und umging sie, sodass ein Workflow Markup speichern konnte, das andernfalls entfernt worden wäre. Das war relevant, weil ein Workflow Werte aus dem auslösenden Datensatz übernimmt. Inhalte, die über ein öffentliches Formular eingereicht wurden oder von jemandem stammten, der lediglich die Berechtigung zum Erstellen dieses Datensatzes hatte, konnten so ungeprüft in ein formatiertes Feld gelangen. Offengelegt wurde dabei nichts, weil die Prüfung bei der Anzeige es weiterhin bereinigte, doch der Schutz greift nun unabhängig davon, woher der Inhalt kommt. Von Automatisierungen vor dieser Version geschriebene Inhalte werden beim Upgrade erneut geprüft, mit derselben Rücksicht darauf, keine Änderungsdaten zu verändern und keine Benachrichtigungen auszulösen.
  • Risikobeschreibungen und Behandlungspläne werden nun ebenfalls gefiltert. Beide werden im Rich-Text-Editor geschrieben, wurden aber beim Speichern auf keinem Weg geprüft.
  • Links in formatiertem Inhalt, die in einem neuen Tab öffnen, erhalten nun übliche Schutzattribute, sodass die geöffnete Seite nicht auf den ISO Mate-Tab verweisen kann, aus dem sie geöffnet wurde. An ihrer Funktion für Sie ändert sich nichts.
  • Textausrichtung, Farben, Tabellenbreiten und Bildgrößen funktionieren weiterhin wie bisher. Stilregeln, die externe Ressourcen laden oder Elemente über andere Teile der Seite legen könnten, werden nicht mehr akzeptiert.
  • Eine offene Weiterleitung bei unverschlüsselten HTTP-Anfragen wurde behoben. Eine Anfrage an eine isomate.io-Adresse mit einem gefälschten Hostnamen wurde mit einer Weiterleitung auf genau diesen Namen beantwortet, sodass ein Link, der auf unserer Domain begann, einen Besucher auf der Website einer anderen Person landen lassen konnte. Unbekannte Hostnamen werden nun ohne Weiteres abgelehnt. Gewöhnliche HTTP-Anfragen wechseln weiterhin genau wie bisher zu HTTPS und behalten dabei die aufgerufene Seite samt Abfrage, sodass keine Lesezeichen oder Links betroffen sind und Sie nichts tun müssen. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Die API akzeptiert keinen vom Aufrufer weitergegebenen Hostnamen mehr. Zuvor konnte eine Anfrage in dem Header, den unser Load Balancer prüft, eine Adresse nennen und in einem Header, dem die API vertraute, eine andere, sodass die API mit einer vom Aufrufer gewählten Adresse arbeitete. Die API entnimmt die Adresse nun ausschließlich Quellen, denen sie vertrauen kann, und lehnt eine Anfrage ab, die eine unbekannte nennt. Damit ist dieselbe Art von Problem wie bei der Weiterleitung oben auf einem zweiten, unabhängigen Weg geschlossen.
  • Das Zurücksetzen oder Ändern Ihres Passworts beendet nun alle anderen Sitzungen, und Sie können wählen, ob dabei auch Ihre API-Tokens widerrufen werden. Sitzungen und API-Tokens sind zwei verschiedene Dinge: eine Sitzung bedeutet, dass Sie angemeldet sind, während ein API-Token eine dauerhafte Zugangsberechtigung ist, die eine Integration oder ein MCP-Client verwendet. Da ein Widerruf alles unterbricht, was das Token nutzt, bleiben Tokens unberührt, sofern Sie das Kästchen im Passwortformular nicht ankreuzen. Kreuzen Sie es an, wenn Sie das Passwort zurücksetzen, weil jemand anderes Zugriff gehabt haben könnte.
  • Bleiben nach einem Zurücksetzen des Passworts API-Tokens aktiv, erfahren Sie nun, wie viele noch gültig sind, und werden gebeten, sie zu prüfen, damit ein Token, das Sie nicht erstellt haben, ein Zurücksetzen nicht unbemerkt überdauert.
  • Das Deaktivieren eines Benutzers oder eines Kontos sperrt nun auch den Zugang über API und MCP. Zuvor wurde die betreffende Person nur aus der Konsole und der mobilen App abgemeldet, während jedes von ihr gehaltene API-Token weiter funktionierte, sodass eine scheinbare Sperre nur halb wirkte. Tokens werden außerdem grundsätzlich abgelehnt, solange der Benutzer oder das Konto deaktiviert ist, sodass nur eine erneute Aktivierung den Zugang zurückbringt. Wird ein Benutzer im Rahmen einer Datenanfrage gelöscht, werden nun auch seine API-Tokens entfernt.
  • Das Erstellen eines API-Tokens erfolgt nicht mehr unbemerkt. Sie erhalten eine E-Mail, die den Namen des Tokens, seine Möglichkeiten und den Ablaufzeitpunkt nennt, dazu eine Benachrichtigung in der App und einen Eintrag im Prüfprotokoll Ihres Kontos. Ein Widerruf wird auf dieselbe Weise protokolliert und gemeldet. Ein Token gewährt dauerhaften Zugriff ohne Passwort, deshalb wird es nun mindestens so deutlich gemeldet wie eine Passwortänderung. Am wichtigsten ist die E-Mail: Wer Zugriff auf Ihr Konto erlangt hat, könnte eine Benachrichtigung in der App verwerfen, eine Nachricht in Ihrem Postfach jedoch nicht.
  • Gemeldet über unser Programm zur Offenlegung von Schwachstellen. Der ursprüngliche Bericht betraf Sitzungen, die ein Zurücksetzen des Passworts überdauerten, was bereits behoben war. Bei der Untersuchung zeigte sich die Lücke in der Handhabung dauerhafter API-Zugangsdaten, und genau diese schließen die beschriebenen Änderungen.
  • Die Zugangsinformation, die Sie angemeldet hält, liegt nicht mehr im Browserspeicher. Sie wird nun in einem Cookie übertragen, das JavaScript nicht lesen kann, und das Token für API-Anfragen ist kurzlebig und wird ausschließlich im Speicher gehalten. Damit gibt es nichts mehr, was einen Seitenaufruf überdauert und für Code in der Seite lesbar wäre. Das schließt einen Weg, auf dem ein Fehler an anderer Stelle in der Seite oder eine kompromittierte Fremdkomponente eine gültige Zugangsinformation hätte auslesen können. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Sitzungsberechtigungen werden nun rotiert. Jede Erneuerung stellt eine neue aus und zieht die vorherige zurück, und wird eine zurückgezogene erneut vorgelegt, gilt das als Hinweis auf eine angefertigte Kopie und beendet die gesamte Sitzung statt nur dieser einen Berechtigung.
  • Wie lange Sie angemeldet bleiben, ändert sich nicht. Eine Sitzung überdauert weiterhin rund dreieinhalb Tage ohne Nutzung, sodass Sie nach einem Freitagabend am Montag nicht erneut angemeldet werden müssen, und das Abmelden funktioniert auch dann, wenn ein Tab tagelang unbenutzt offen stand. Nach dieser Version müssen Sie sich einmal neu anmelden, weil zuvor bestehende Sitzungen in der alten Form gehalten wurden.
  • Sicherheitsheader werden nun auch auf Dateien angewendet, die unsere Website direkt ausliefert, einschließlich Theme-Dateien, WordPress-Kerndateien und hochgeladener Medien. Vom System erzeugte Seiten trugen sie bereits, direkt von der Festplatte ausgelieferte Dateien jedoch nicht, weil diese Anfragen nie die Schicht durchlaufen, die sie hinzufügte. Der praktische Gewinn liegt bei hochgeladenen Medien, die nun einen Schutz des MIME-Typs tragen, sodass ein Browser eine Datei nicht als etwas anderes behandeln kann als den Typ, mit dem sie deklariert wurde. Angestoßen durch einen Hinweis über unser Programm zur Offenlegung von Schwachstellen.
  • SVG-Bilder werden nun nicht nur von Skripten, sondern auch von Links befreit. Bei einem hochgeladenen SVG wurden Skripte und Ereignishandler bereits entfernt, ein Link darin überlebte jedoch, sodass das Bild weiterhin ein Ziel auf der Website einer anderen Person tragen konnte. ISO Mate zeigt ein SVG nie so an, dass ein solcher Link gefolgt werden kann, es wurde also nichts offengelegt, doch der Link überlebt das Speichern nicht mehr. Gewöhnliche Grafiken sind nicht betroffen: interne Verweise und eingebettete Fotos funktionieren weiterhin, und Ihre Logos und Diagramme sehen genau wie bisher aus. Angestoßen durch einen Hinweis über unser Programm zur Offenlegung von Schwachstellen.
  • Für Ticketanhänge im Help Desk gelten nun dieselben Regeln zu zulässigen Dateitypen wie für Vorgangsanhänge. Dateitypen, die ein Browser als Seite oder Skript ausführen kann, etwa HTML und JavaScript, werden bei einer Antwort und bei einer internen Notiz nicht mehr akzeptiert. Bilder, Dokumente, Tabellen, Text und Archive sind nicht betroffen. Wenn Sie einem Anfragenden eine Webseite oder ein Skript senden möchten, packen Sie es in ein ZIP-Archiv. Zuvor hinzugefügte Anhänge bleiben unberührt.
  • Downloads von E-Mail-Anhängen durchlaufen nun dieselben Schutzmaßnahmen wie jede andere Datei, die ISO Mate ausliefert. Ein Weg, der beim ersten Abruf eines Anhangs aus einem verbundenen Google-Postfach genutzt wurde, lieferte die Datei ohne sie aus. Das Herunterladen eines Anhangs funktioniert genau wie bisher.
  • Ein Google-Konto mit Ihrem Profil zu verknüpfen, geschieht nun ausschließlich innerhalb Ihrer eigenen angemeldeten Sitzung. Der Schritt, der eine Verknüpfung abschloss, war ohne Anmeldung erreichbar und vertraute der in der Anfrage genannten Identität, anstatt zu bestätigen, wer fragt. Damit hätte jemand sein eigenes Google-Konto mit dem Profil einer anderen Person verknüpfen und sich anschließend als diese anmelden können. Praktisch war der Weg nie erreichbar, weil eine separate fehlerhafte Prüfung verhinderte, dass eine solche Anfrage überhaupt begonnen werden konnte, doch das war ein Zufall und keine bewusste Ablehnung. Der nicht authentifizierte Weg wurde vollständig entfernt, und das Verknüpfen läuft nun über eine Route, die bestätigt, dass die Anfrage von Ihnen stammt.
  • Das Abmelden widerruft Ihre Sitzung nun auch dann, wenn ein Client nichts als sein kurzlebiges Zugriffstoken sendet. Aus der Verwaltungskonsole und der mobilen App funktionierte das Abmelden bereits korrekt, weil beide die Zugangsinformation vorlegen, die die Sitzung identifiziert. Einem Client, der ausschließlich das Zugriffstoken sendete, wurde jedoch ein erfolgreiches Abmelden gemeldet, während die Sitzung tatsächlich für die restlichen fünfzehn Minuten Lebensdauer dieses Tokens aktiv blieb. Dieser Weg widerruft nun alle Tokens der Sitzung und hält das Abmelden im Prüfprotokoll Ihres Kontos fest. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Das Anmeldefenster wurde gegen die Seite gehärtet, die es öffnet. Die Browseranweisung, die die Verwaltungskonsole von jeder Seite isoliert, die sie geöffnet hat, lieferte unser Content-Netzwerk bereits aus, und die Konsole prüft es nun auch selbst, auf der Anmelde- und der Registrierungsseite, und verweigert den Start des Google-Anmeldevorgangs, wenn sie von einer Seite einer anderen Website geöffnet wurde. Die API sendet dieselbe Isolationsanweisung wie die Konsole. Der Schutz beruht damit nicht mehr auf einem einzigen Infrastrukturbaustein und greift auch auf Oberflächen, die nicht hinter dem Content-Netzwerk liegen. Angestoßen durch einen Hinweis über unser Programm zur Offenlegung von Schwachstellen, der eine Kontoübernahme beschreibt, die sich bei ISO Mate nicht reproduzieren lässt, gerade weil diese Anweisung bereits vorhanden ist.
  • Links, die in einem neuen Tab öffnen, sind nun überall gehärtet, nicht nur innerhalb formatierter Inhalte. Jeder Link, den die Verwaltungskonsole zu einem externen Ziel öffnet, etwa das Abrechnungsportal, eine Rechnung oder ein Google Meet, wird nun so geöffnet, dass der neue Tab keinen Verweis auf den ISO Mate-Tab behält, der ihn geöffnet hat. Aktuelle Browser tun das bei gewöhnlichen Links bereits, nicht aber bei Fenstern, die eine Anwendung selbst öffnet, und genau diese Lücke wird hier geschlossen. An ihrer Funktion für Sie ändert sich nichts. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Unsere Website sendet nun die Browseranweisung, die eine Seite von jeder anderen Seite isoliert, die sie geöffnet hat oder die sie öffnet. Die Verwaltungskonsole und die API sendeten sie bereits, sodass nun alle drei übereinstimmen. Links auf der Website, die in einem neuen Tab öffnen, tragen zudem wieder die Schutzattribute, die WordPress in einer neueren Version nicht mehr automatisch hinzufügt.
  • Antworten der API werden nicht mehr in den eigenen Cache des Browsers geschrieben. Aus gemeinsam genutzten Caches und Proxys wurden sie bereits herausgehalten, doch ein Browser konnte weiterhin eine Kopie auf der Festplatte behalten. Datensätze mit personenbezogenen Angaben konnten so nach dem Ende der Sitzung auf einem Gerät verbleiben und von jedem mit Zugriff auf dieses Gerät wiederhergestellt werden. Jede API-Antwort weist nun das Speichern zurück, während das bewusste Zwischenspeichern von Downloads, Exporten und des öffentlichen Anfragendenportals unberührt bleibt. Die Verwaltungskonsole prüft außerdem erneut, ob Sie noch angemeldet sind, wenn der Browser eine Seite aus seinem Vor- und Zurück-Cache wiederherstellt. Angestoßen durch einen Hinweis über unser Programm zur Offenlegung von Schwachstellen zu zwischengespeicherten Seiten nach dem Abmelden. Dieser Weg war bereits geschlossen, denn der Einstiegspunkt der Konsole wird nie zwischengespeichert, nach dem Abmelden verbleibt keine Zugangsinformation und keine personenbezogene Angabe im Browserspeicher, und jede geschützte Seite wird vor dem Laden erneut gegen den Server geprüft.
  • Eingehende E-Mail an isomate.io verlangt nun ausdrücklich Verschlüsselung. Eine veröffentlichte MTA-STS-Richtlinie nennt einem sendenden Server, welche Mailserver legitim sind und dass die Verbindung verschlüsselt sein muss. Ein Absender lässt sich damit nicht dazu verleiten, eine Nachricht unverschlüsselt oder an einen untergeschobenen Server auszuliefern. Daneben ist die TLS-Berichterstattung veröffentlicht, sodass jeder Fehlschlag für uns sichtbar wird. Die Richtlinie startet im Testmodus, der Probleme meldet, ohne die Auslieferung zu beeinflussen, und wechselt in den erzwingenden Modus, sobald die Berichte ihre Richtigkeit bestätigen. Die Schutzmaßnahmen für ausgehende Mail, SPF, DKIM und DMARC, waren bereits vorhanden; dies ist ihr Gegenstück für den Eingang. Gemeldet über unser Programm zur Offenlegung von Schwachstellen.
  • Fremdkomponenten in der API und in der Verwaltungskonsole wurden auf ihre aktuellen gepatchten Fassungen gebracht, womit jeder Hinweis aus unseren automatischen Abhängigkeitsprüfungen ausgeräumt ist. Bei der Prüfung anhand des tatsächlichen Aufbaus von ISO Mate erwies sich fast keiner als erreichbar, weil sie Funktionen und Darstellungsmodi voraussetzen, die wir nicht verwenden. Einer war um seiner selbst willen und nicht wegen der Prüfung zu erledigen: die Bibliothek, die formatierten Text im Browser filtert, war mehrere Patches im Rückstand, und dieser Code verarbeitet tatsächlich nicht vertrauenswürdige Inhalte, weshalb er nun in einer aktuellen Fassung läuft.
  • Die Laufzeitpakete der Konsole waren auf genaue Versionen festgelegt, weshalb sie Sicherheitspatches nicht selbst aufnehmen konnten und dieselben Befunde bei jeder Prüfung zurückkehrten. Sie folgen nun den Patch-Versionen, und ungenutzte Pakete für serverseitiges Rendern wurden entfernt, anstatt sie mitzuschleppen und jeden Monat erneut zu prüfen.