ProjectSend: die öffentlichen Links, die ein Kunde nicht sehen sollte

Viele Kanzleien, Agenturen und kleine Unternehmen tauschen Dokumente mit ihren Kunden über ein Portal aus: Der Kunde lädt seine Dateien hoch, die Mitarbeitenden prüfen sie und geben sie manchmal über einen öffentlichen Link an Dritte weiter. Wer diesen Link erstellen darf und wer ihn sehen darf, ist eine bewusste Entscheidung. In ProjectSend sollte ein Kunde ohne die Berechtigung, Dateien zu veröffentlichen, keinen öffentlichen Link verteilen können. Trotzdem konnte er auf der Bearbeitungsseite einer eigenen Datei die Links, die Mitarbeitende für diese Datei erstellt hatten, vollständig auslesen und sogar löschen.

Das ist der Fehler, den das Advisory GHSA-g9g5-qxp7-f7v2 beschreibt, veröffentlicht am 8. November 2026 und behoben in ProjectSend 2.8.0. Gemeldet haben ihn wir: Entdeckt hat ihn Liam Giannini (Liam-G auf GitHub), ethischer Hacker und Mitgründer von Webcracy. Wir danken den Maintainern von ProjectSend, die die Korrektur in das erste Release nach unserer Meldung aufgenommen haben.

Webcracy und IT-Sicherheit

Neben der Entwicklung von Websites und Anwendungen befasst sich Webcracy mit IT-Sicherheit: Penetrationstests, Code-Reviews, Konfigurationsanalysen und Forschung an der Open-Source-Software, die wir selbst und unsere Kunden einsetzen. Liam arbeitet als ethischer Hacker: Er sucht Lücken mit den Methoden eines Angreifers, aber damit sie geschlossen werden. Er meldet sie vertraulich an die Maintainer und macht sie erst öffentlich, wenn eine Korrektur verfügbar ist. Es ist dasselbe Vorgehen der verantwortungsvollen Offenlegung, das wir bei exarch und FreeScout befolgt haben.

Was öffentliche Links in ProjectSend sind

ProjectSend ist eine der beliebtesten und am weitesten verbreiteten Open-Source-Anwendungen, um Dateien vom eigenen Server aus mit Kunden zu teilen: Es existiert seit 2014, hat über 2'000 Sterne auf GitHub, und allein das Docker-Image von LinuxServer.io kommt auf mehr als 4,9 Millionen Downloads. Geschrieben ist es in PHP, auf Basis von Laravel. Bei einem so verbreiteten Projekt bleibt eine Lücke nie das Problem einiger weniger. Jede Datei kann einen oder mehrere öffentliche Links haben, Adressen der Form /s/{token}, die jeder, der sie besitzt, ohne Anmeldung öffnen kann. Der Token funktioniert wie ein Schlüssel: Wer den Link hat, kommt hinein, ohne weitere Prüfung. Deshalb ist das Erstellen eines solchen Links eine eigene Berechtigung, upload_public, die der Administrator jeder Rolle erteilen oder verweigern kann.

ProjectSend hatte bereits eine klare Regel dafür, wer was sieht: Im Portal sieht ein Kunde nur die öffentlichen Links, die er selbst erstellt hat. Erstellen Mitarbeitende einen Link auf eine vom Kunden hochgeladene Datei, etwa um sie an einen externen Berater zu schicken, erscheint dieser Link nicht in der Dateiliste des Kunden. Der Code setzte diese Regel ausdrücklich um, und es gab sogar einen automatisierten Test, der sie prüfte.

Wo die Regel nicht galt

Das Problem lag an zwei Stellen, die für dasselbe Objekt eine schwächere Regel anwendeten.

Die erste war der Datei-Editor. Ein Kunde mit der Berechtigung edit_files kann die Dateien bearbeiten, die er hochgeladen hat. Öffnete er die Bearbeitungsseite, prüfte der Server zu Recht, ob er diese Datei bearbeiten darf, schickte dann aber alle verknüpften öffentlichen Links an den Browser, ohne nach Ersteller zu filtern. Zu jedem Link gehörten die vollständige Adresse mit dem Token, die Kennung und die Adresse zum Widerrufen. Ein Blick in die Daten der Seite genügte, um an den Link der Mitarbeitenden zu kommen.

Die zweite war der Widerruf. Die Anfrage, die einen Link löscht, prüfte wiederum nur die Bearbeitungsberechtigung für die Datei, nicht aber, wer den Link erstellt hatte. Der Kunde konnte also einen Link der Mitarbeitenden löschen, und wer ihn erhalten hatte, stand plötzlich ohne Zugang da.

In beiden Fällen ist der Fehler derselbe, und er kommt sehr häufig vor: Die Berechtigung für eine Ressource wird mit der Berechtigung für alles verwechselt, was mit ihr verknüpft ist. Wer eine Datei bearbeiten darf, darf noch lange nicht jeden Link verwalten, den andere für diese Datei erstellt haben.

Wie schwer wiegt das

Kein Zugriff auf fremde Dateien, keine Rechte von Mitarbeitenden: Das Problem betrifft nur Dateien, die der Kunde selbst hochgeladen hat, und setzt voraus, dass Mitarbeitende dafür einen öffentlichen Link erstellt haben. Innerhalb dieses Rahmens wurden aber zwei Entscheidungen der Mitarbeitenden ausgehebelt. Ein Kunde, dem das Veröffentlichen verweigert worden war, konnte trotzdem einen aktiven öffentlichen Link an beliebige Personen weitergeben, der die Datei ohne Anmeldung öffnet. Und er konnte einen Link widerrufen, den Mitarbeitende an Dritte gegeben hatten, und damit eine Freigabe beenden, über die andere entschieden hatten. Das Advisory stuft das Problem als mittelschwer ein, in den Kategorien CWE-862, fehlende Autorisierung, und CWE-200, Offenlegung sensibler Informationen. In unserer Meldung hatten wir einen CVSS-3.1-Wert von 5.4 geschätzt.

Betroffen sind die Versionen 2.5.0 bis 2.7.1.

Wie wir es überprüft haben

Das Problem fiel beim Lesen des Codes von ProjectSend 2.7.1 auf, beim Vergleich der verschiedenen Wege, die zu denselben Links führen: die Liste im Portal, der Datei-Editor und der Widerruf. Die Liste filterte nach Ersteller, die anderen beiden nicht.

Zur Bestätigung schrieb Liam vier automatisierte Tests mit den Testwerkzeugen, die das Projekt bereits mitbringt, ausgeführt in einem isolierten Docker-Container mit einer In-Memory-Datenbank und fiktiven Konten. Die Tests prüfen, dass der Editor den Link der Mitarbeitenden preisgibt, dass der Kunde ihn widerrufen kann, dass die Portalliste ihn hingegen korrekt verbirgt und dass der so erlangte Link auch ohne Anmeldung funktioniert. Zwei bestehende Tests dienten als Kontrolle: Ein Kunde ohne upload_public kann keine öffentlichen Links erstellen und keine Links auf Dateien widerrufen, die nicht ihm gehören. Das Verhalten wurde auch auf dem Hauptentwicklungszweig bestätigt.

Die Korrektur in 2.8.0

Die Release Notes von 2.8.0, veröffentlicht am 29. Oktober, fassen es in einer Zeile zusammen: Der Datei-Editor eines Kunden zeigt und widerruft jetzt nur noch die öffentlichen Links, die dieser Kunde selbst erstellt hat. Es ist dieselbe Regel, die das Portal bereits anwendete, ausgeweitet auf die zwei Stellen, an denen sie fehlte. Die Berechtigungen der Mitarbeitenden bleiben unverändert.

Dasselbe Release schließt mehrere weitere Autorisierungsprobleme: API-Tokens, die mehr konnten als ihnen erlaubt war, vorbereitete ZIP-Archive, die nach dem Verlust des Zugriffs auf eine Datei weiterhin herunterladbar blieben, Uploads, die in Ordnern landeten, auf die der Benutzer keinen Zugriff mehr hatte, und anderes mehr. Schon das ist Grund genug, das Update nicht aufzuschieben.

Was tun, wenn Sie ProjectSend nutzen

Liegt Ihre Installation zwischen 2.5.0 und 2.7.1, aktualisieren Sie auf 2.8.0 oder neuer. Lesen Sie vorher den Abschnitt "do these yourself" in den Release Notes: Einige API-Tokens müssen neu erstellt werden, damit sie dieselben Funktionen behalten, und benutzerdefinierte E-Mail-Vorlagen mit Markdown werden jetzt als reiner Text angezeigt.

Nach dem Update lohnt es sich auch, die öffentlichen Links durchzugehen, die Mitarbeitende auf von Kunden hochgeladenen Dateien erstellt haben. Wurde ein Link mit Externen geteilt und hätte der Kunde ihn nicht kennen dürfen, macht ihn das Update nicht nachträglich geheim: Die Lösung ist, ihn zu widerrufen und einen neuen zu erstellen. Und falls ein Link der Mitarbeitenden ohne erkennbaren Grund verschwunden ist, kennen Sie jetzt eine mögliche Ursache.

Ganz allgemein enthält ein Kundenportal Verträge, Rechnungen, Ausweisdokumente. Es verdient regelmäßige Updates und eine periodische Überprüfung der Rollen: wer edit_files hat, wer upload_public hat und ob das wirklich nötig ist.

Warum wir an Open-Source-Software forschen

Wir empfehlen oft selbst gehostete Open-Source-Werkzeuge wie ProjectSend: Die Daten bleiben auf dem eigenen Server, es gibt keine Gebühren pro Benutzer, der Code lässt sich lesen. Aber jemand muss ihn auch wirklich lesen, und zwar mit dem Blick von jemandem, der nach der Stelle sucht, an der zwei Teile des Programms unterschiedliche Regeln auf dieselbe Sache anwenden. Solche Probleme zeigen sich nicht bei der normalen Nutzung der Anwendung, sondern erst beim Vergleichen des Codes. Sie den Maintainern zu melden, ist unsere Art, diesen Projekten etwas zurückzugeben, und genau zu wissen, was wir bei unseren Kunden installieren.

Wenn Sie ein Kundenportal, eine Unternehmenssoftware oder eine Individualanwendung einsetzen und wissen möchten, ob die Berechtigungen wirklich halten, was sie versprechen, sprechen wir gern darüber. Unsere Arbeit im Penetration Testing beginnt genau hier: Code und Konfiguration lesen, verstehen, wo eine Prüfung fehlt, und Ihnen genau sagen, was wir überprüft haben und was nicht.

Sprechen wir über die Sicherheit Ihrer Anwendungen↗