FreeScout: die Polycast-Schwachstelle, die wir gemeldet haben

Wenn Sie in FreeScout ein Ticket öffnen und ein Kollege gerade dieselbe Konversation ansieht, erscheint oben sein Name. Eine kleine, praktische Funktion: Sie verhindert, dass zwei Personen im selben Moment demselben Kunden antworten. Damit das funktioniert, schickt der Browser jedes Agenten regelmäßig eine Anfrage an den Server, die im Kern sagt: "Ich sehe mir gerade Konversation Nummer X an." Der Server prüfte weder, ob diese Konversation existierte, noch ob der Benutzer sie überhaupt sehen durfte. Er nahm den Wert einfach entgegen und speicherte ihn.

Das ist der Fehler, den das Advisory GHSA-vcgj-6qfr-7qr6 beschreibt, veröffentlicht am 17. Oktober 2026 und behoben in FreeScout 1.8.248. Gemeldet haben ihn wir: Entdeckt hat ihn Liam Giannini (Liam-G auf GitHub) von der Sicherheitsforschungsgruppe von Webcracy. Wir danken den Maintainern von FreeScout, die die Korrektur im nächsten Release veröffentlicht haben.

Was hinter der Anzeige "sieht sich gerade an" passierte

FreeScout ist einer der beliebtesten und meistgenutzten Open-Source-Helpdesks: Seit 2018 entwickelt, hat er über 4'600 Sterne auf GitHub und wird von sehr vielen Unternehmen als selbst gehostete Alternative zu Diensten wie Help Scout oder Zendesk eingesetzt. Geschrieben ist er in PHP, auf Basis von Laravel. Bei einem so verbreiteten Projekt bleibt eine Lücke nie das Problem einiger weniger. Die Echtzeit-Aktualisierungen laufen über eine Komponente namens Polycast, die die periodischen Anfragen der Browser am Endpoint POST /polycast/receive entgegennimmt.

Jede Anfrage landete in einer Methode, processConvView(), die das Feld data[conversation_id] las und unverändert verwendete. Keine Prüfung, ob es sich um eine Zahl handelte, keine Längenbegrenzung, keine Berechtigungsprüfung. Die Konversation wurde nur in bestimmten Fällen in der Datenbank nachgeschlagen, und selbst wenn das fehlschlug, wurde der Wert nicht verworfen. Für jede neue ID legte der Server einen eigenen Cache-Eintrag an und fügte dieselbe ID einem einzigen gemeinsamen Array hinzu, conv_view, das die aktiven Ansichten der gesamten Installation enthält.

Genau dieses Array macht aus einer fehlenden Prüfung ein Verfügbarkeitsproblem. Es wird bei jeder Anfrage vollständig gelesen, verändert und vollständig zurückgeschrieben, mit einer Lebensdauer von zwanzig Minuten. Wenn jemand Tausende erfundene IDs hineinschiebt, wird jeder weitere Schreibvorgang schwerer, und das betrifft auch die legitimen Anfragen der anderen Agenten, die dasselbe Objekt verwenden. Verschärft wird das durch einen geplanten Befehl, freescout:check-conv-viewers, der jede Minute läuft: Er geht alle Einträge durch, entfernt für jeden abgelaufenen Eintrag einen Schlüssel aus dem Cache und löst ein Echtzeit-Ereignis aus. Mehr falsche Einträge, mehr Arbeit für die Datenbank und das Broadcast-System. Außerdem hatte der Endpoint kein eigenes Rate Limit.

Das Ergebnis: Ein einziges Agentenkonto, auch ohne Administratorrechte, konnte den Helpdesk für alle verlangsamen. Langsamere Anfragen, ausgelastete Worker, Druck auf Redis oder das konfigurierte Cache-Backend, verspätete geplante Aufgaben. Es gibt keinen Zugriff auf fremde Daten und keine Änderung von Inhalten. GitHub stuft das Problem als mittelschwer ein, CVSS 3.1 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H), in der Kategorie CWE-400, unkontrollierter Ressourcenverbrauch.

Warum "man muss angemeldet sein" nicht reicht

Man könnte die Sache leicht abtun mit dem Hinweis, dass der Angreifer ein Konto braucht. In einem Helpdesk gibt es aber viele Konten, und sie wechseln oft: Saisonkräfte, externe Mitarbeitende, Lieferanten, denen man ein gemeinsames Postfach öffnet, Zugangsdaten, die bei einem anderen, kompromittierten Dienst wiederverwendet wurden. Die Zugriffskontrolle von Polycast prüfte, ob der Benutzer angemeldet war und den angefragten Kanal abhören durfte. Über den Inhalt der Anfrage sagte sie nichts. Die richtige Grenze ist nicht "der Benutzer ist authentifiziert", sondern "der Benutzer darf genau diese Konversation sehen".

Es gibt auch einen Präzedenzfall am selben Endpoint. Im Juli wurde GHSA-gh3r-jh6q-wrvj (CVE-2026-62856) veröffentlicht, eine Lücke mit hohem Schweregrad, behoben in 1.8.226, die die Platzhalter einer LIKE-Abfrage bei der Kanalauswahl ausnutzte, um Benachrichtigungen anderer Benutzer zu lesen. Unser Fall ist anders: Das verwundbare Feld ist data[conversation_id], und die Auswirkung betrifft Ressourcen, nicht die Vertraulichkeit. Aber dass derselbe Einstiegspunkt innerhalb weniger Monate zwei Advisories hervorgebracht hat, sagt etwas aus. Polling-Endpoints, also die, die der Browser alle paar Sekunden aufruft, ohne dass jemand darüber nachdenkt, bekommen tendenziell weniger Aufmerksamkeit als die Bildschirme, die der Benutzer sieht.

Wie wir es überprüft haben

Das Problem ist bei einer Durchsicht des Quellcodes von FreeScout 1.8.247 (Commit 9d11ff0) aufgefallen, als wir dem Weg der Daten vom Endpoint bis zum Aufräumbefehl gefolgt sind. In der Meldung haben wir beschrieben, wie es sich im Labor reproduzieren lässt: als normaler Agent anmelden, einige Anfragen mit nicht existierenden IDs senden, den Cache und das Wachstum des Objekts conv_view beobachten und dann den geplanten Befehl laufen lassen. Ein paar Dutzend Einträge genügen, um den Effekt zu sehen: Man muss keinen Helpdesk lahmlegen, um zu zeigen, dass er lahmgelegt werden kann.

Die Korrektur in 1.8.248

Die Release Notes der Version 1.8.248 nennen die Bereinigung der ID in processConvView(). Im korrigierten Code wird der Wert nur akzeptiert, wenn er eine positive ganze Zahl mit höchstens zehn Stellen ist, der Benutzer muss authentifiziert sein, und vor jedem Schreibvorgang in den Cache wird geprüft, ob er die Konversation tatsächlich sehen darf. Eine Anfrage mit einer falschen ID oder mit der ID einer nicht zugänglichen Konversation hinterlässt keine Spuren mehr.

In der Meldung hatten wir noch weitere Maßnahmen vorgeschlagen: ein eigenes Rate Limit für den Polycast-Endpoint, eine Obergrenze für die Anzahl aktiver Ansichten pro Benutzer und pro Konversation und vor allem den Ersatz des globalen Arrays durch eine Struktur pro Konversation, damit nicht bei jeder Anfrage alles neu geschrieben wird. Die Validierung zusammen mit der Berechtigungsprüfung schließt den im Advisory beschriebenen Angriffsweg. Die übrigen Maßnahmen sind Defense in Depth, nützlich gegen künftigen Missbrauch, und bleiben eine Designentscheidung der Maintainer.

Dasselbe Release behebt drei weitere Advisories: GHSA-w3jr-fphw-whgv, zu früheren Konversationen, die für Benutzer sichtbar waren, die nur die ihnen zugewiesenen sehen sollten; GHSA-c8rg-2r2h-5vgc, zum Erzeugen mehrerer Sitzungen durch paralleles Einlösen derselben Einladung; und GHSA-cxf4-7mrp-vvpr, ein Problem mit Steuerzeichen in der Abhängigkeit league/flysystem. Schon das ist Grund genug, das Update nicht aufzuschieben.

Was tun, wenn Sie FreeScout verwenden

Wenn Ihre Installation älter als 1.8.248 ist, aktualisieren Sie sie. Das Advisory nennt keine vorübergehenden Workarounds, und Polycast zu deaktivieren hieße, auf die Echtzeit-Aktualisierungen zu verzichten, auf die sich die Oberfläche stützt. Vor dem Update lohnt sich ein Backup der Datenbank und des Modulordners: Viele Probleme nach einem FreeScout-Upgrade kommen eher von nicht angepassten Drittanbieter-Modulen als vom Kern.

Wenn Ihnen unerklärliche Verlangsamungen des Helpdesks aufgefallen sind, lohnt sich auch ein Blick auf die Größe des Eintrags conv_view im Cache. Ein Wert mit deutlich mehr Einträgen, als Konversationen tatsächlich von Agenten geöffnet sind, ist ein Signal, dem man nachgehen sollte. Nach dem Update laufen die bestehenden Einträge ohnehin innerhalb von zwanzig Minuten von selbst ab.

Und wenn FreeScout auf einem Server läuft, den seit Monaten niemand kontrolliert hat, ist dieses Advisory wahrscheinlich nicht Ihr einziges Problem. Ein Helpdesk enthält die E-Mails der Kunden, Anhänge, manchmal heikle Personendaten: Er verdient dieselbe Wartung wie die Firmenwebsite, wenn nicht mehr.

Warum wir Open-Source-Software untersuchen

Viele unserer Kunden nutzen selbst gehostete Open-Source-Werkzeuge, und wir empfehlen sie oft: keine Lizenzgebühren pro Benutzer, Daten auf dem eigenen Server, Code, den man lesen kann. Aber "man kann ihn lesen" heißt nicht, dass ihn jemand liest. Einen Teil unserer Zeit in die Prüfung der Projekte zu stecken, die wir installieren, und das, was wir finden, verantwortungsvoll an die Maintainer zu melden, ist der konkreteste Weg, den wir kennen, um diesen Projekten etwas zurückzugeben. Und um wirklich zu wissen, was wir in Produktion bringen.

Wenn Sie eine ähnliche Prüfung Ihres Helpdesks, Ihrer Unternehmenssoftware oder einer maßgeschneiderten Anwendung wünschen, sprechen wir gerne darüber. Unsere Arbeit im Penetration Testing beginnt genau hier: Code und Konfiguration lesen, verstehen, wo ein Wert nicht geprüft wird, und Ihnen genau sagen, was wir überprüft haben und was nicht.

Sprechen wir über die Sicherheit Ihrer Anwendungen↗