Kurzfassung

In OpenProject wurde eine Schwachstelle identifiziert, die dazu führen kann, dass OAuth-Zugangstoken für OneDrive- und SharePoint-Anbindungen im Klartext im Cache abgelegt werden. Betroffen sind Versionen vor 17.3.3 und 17.4.1. Das Problem ist sicherheitsrelevant, weil ein Angreifer mit Lesezugriff auf den Cache-Bereich an ein gültiges Bearer-Token gelangen kann und damit unter Umständen auf angebundene Microsoft-365-Ressourcen zugreift.

Für Unternehmen im DACH-Raum ist das vor allem dann kritisch, wenn OpenProject als zentrales Projektmanagement- oder Kollaborationstool mit Cloud-Speicheranbindungen genutzt wird. Für Privatpersonen ist die Relevanz geringer, da OpenProject typischerweise im Unternehmensumfeld eingesetzt wird.

Was ist passiert?

Die Schwachstelle betrifft das Storages-Modul von OpenProject. Dort werden OAuth-Zugangsdaten für userless Verbindungen zu OneDrive und SharePoint in einem Cache abgelegt. Laut Quelle erfolgt dies in einer Form, die nicht verschlüsselt ist und sich über den Cache-Backend-Zugriff auslesen lässt. Der Cache wird zudem regelmäßig neu befüllt, sodass das Token wiederholt verfügbar sein kann.

Die Problematik liegt damit nicht in einem klassischen Remote-Exploit über das Web-Frontend, sondern in der ungeschützten Ablage sensibler Authentifizierungsdaten. Wer Zugriff auf den Cache hat, kann das Token potenziell abgreifen und für weitere Zugriffe missbrauchen. Die Schwachstelle wurde in den Versionen 17.3.3 und 17.4.1 behoben.

Technische Details

Nach Angaben der Quelle schreibt OpenProject das OAuth-Access-Token in Rails.cache unter einem deterministischen Schlüssel ab. Als Cache-Backends werden file_store, memcache und redis genannt. Diese Backends verschlüsseln die Daten im Ruhezustand laut Quelle nicht automatisch. Dadurch kann ein Angreifer mit Lesezugriff auf den jeweiligen Speicherort das Token auslesen.

Besonders relevant ist, dass es sich um ein Azure-AD-Bearer-Token für den Zugriff auf OneDrive/SharePoint handelt. Ein solches Token kann je nach Berechtigung Zugriff auf Dateien, Dokumente oder andere angebundene Inhalte ermöglichen. Der Angriff setzt also keinen direkten Bruch der Authentifizierung voraus, sondern nutzt die unsichere Speicherung bereits ausgestellter Zugangsdaten aus.

Aus Verteidigungssicht ist das ein typisches Beispiel für ein Geheimnismanagement-Problem: Nicht die Anmeldung selbst ist fehlerhaft, sondern die Art, wie ein gültiges Geheimnis intern verarbeitet und abgelegt wird. Genau solche Schwachstellen werden in der Praxis oft unterschätzt, weil sie außerhalb des eigentlichen Login-Pfads liegen.

Wer ist betroffen?

Betroffen sind OpenProject-Installationen vor 17.3.3 und 17.4.1, sofern das Storages-Modul mit OneDrive- oder SharePoint-Anbindung genutzt wird. Besonders relevant ist das für Organisationen, die OpenProject in hybriden Arbeitsumgebungen einsetzen und Dokumente zentral über Microsoft-365-Dienste bereitstellen.

Für Unternehmen im DACH-Raum ergibt sich daraus ein konkretes Risiko: Projektpläne, vertrauliche Dokumente, interne Abstimmungen oder personenbezogene Daten können über die angebundenen Speicherorte erreichbar sein. Je nach Berechtigung des Tokens kann ein kompromittierter Cache-Zugriff damit weit über ein einzelnes Projekt hinausreichen.

Privatpersonen sind nach der vorliegenden Quelle nicht der typische Zielkreis. Sollte OpenProject jedoch in kleineren Teams, Vereinen oder bei Selbstständigen eingesetzt werden, kann auch dort ein unbefugter Zugriff auf verknüpfte Cloud-Daten erhebliche Folgen haben.

Empfohlene Maßnahmen

Organisationen sollten OpenProject umgehend auf 17.3.3 oder 17.4.1 beziehungsweise auf eine neuere, vom Hersteller freigegebene Version aktualisieren. Zusätzlich sollte geprüft werden, ob das Storages-Modul mit OneDrive- oder SharePoint-Anbindung aktiv ist und welche Berechtigungen die verwendeten Konten besitzen.

Aus praktischer Sicht sind außerdem folgende Schritte sinnvoll: Cache- und Speicherzugriffe auf Applikations- und Infrastruktur-Ebene strikt einschränken, Berechtigungen für Redis, Memcached oder Dateicaches minimieren, Token- und Secret-Lifecycle dokumentieren sowie nach dem Update bestehende Tokens vorsorglich neu ausstellen oder rotieren. Wenn Hinweise auf unbefugten Zugriff bestehen, sollten die betroffenen Microsoft-365-Zugänge überprüft und Protokolle ausgewertet werden.

Für den Betrieb in regulierten Umgebungen empfiehlt sich zudem eine Überprüfung der Datenflüsse zwischen OpenProject und Cloud-Speichern. Ziel ist es, sensible Zugriffsdaten nicht nur auf Anwendungsebene, sondern auch auf Infrastruktur- und Administrations-Ebene abzusichern.

Einschätzung von CyberSecurity-News.de

CyberSecurity-News.de bewertet CVE-2026-52783 als praxisrelevante Schwachstelle mit mittlerem bis hohem operativem Risiko, insbesondere in Unternehmen, die Projektmanagement und Cloud-Dokumente eng verzahnen. Der Fall zeigt, dass auch etablierte Business-Anwendungen durch unsaubere Speicherung von Tokens zu einem Einfallstor werden können.

Für den DACH-Raum ist die Relevanz hoch, weil OpenProject in vielen Organisationen in sensiblen Arbeitsabläufen eingesetzt wird. Der Schaden hängt dabei weniger von der technischen Komplexität des Angriffs ab als von der Bedeutung der angebundenen Daten und der Reichweite des Tokens. Wer solche Integrationen produktiv nutzt, sollte die Schwachstelle daher nicht als theoretisch abtun.

Im Alltag ist das Risiko besonders dann groß, wenn Infrastrukturzugriffe breit vergeben sind oder Cache-Systeme administrativ nur unzureichend abgesichert werden. Genau hier liegt der praktische Mehrwert dieser Meldung: Sie erinnert daran, dass auch interne Speicherschichten Teil der Angriffsfläche sind.

Fazit

CVE-2026-52783 betrifft keine spektakuläre Remote-Exploitation, ist aber sicherheitstechnisch ernst zu nehmen. Die ungeschützte Ablage eines OAuth-Tokens im Cache kann ausreichen, um Cloud-Zugriffe auf OneDrive und SharePoint zu kompromittieren. Für Unternehmen mit OpenProject im Einsatz ist ein zügiges Update die wichtigste Maßnahme.

Wer Projektmanagement-Plattformen mit externen Speicherdiensten verbindet, sollte die Behandlung von Tokens und Caches grundsätzlich überprüfen. Die Schwachstelle verdeutlicht, dass Sicherheitsrisiken oft dort entstehen, wo Anwendungen Authentifizierungsdaten intern weiterverarbeiten und speichern.

Quellenangabe

Quelle: NVD/NIST zu CVE-2026-52783