SiYuan vor 3.7.4: Zwei kritische Lücken öffnen Debug-Dumps und XSS-Angriffe

Kurzfassung

Für SiYuan sind zwei kritische Schwachstellen veröffentlicht worden. Beide betreffen Versionen vor 3.7.4. Wer die Notizen- und Wissensdatenbank im eigenen Netz oder auf einem Server betreibt, sollte das Update priorisieren.

CVE-2026-74799 erlaubt den Zugriff auf Debug-Endpunkte aus Go-pprof, wenn SiYuan nicht exakt im Produktivmodus läuft. Dadurch können Speicherabbilder ausgelesen werden. In diesen Dumps können Zugangscodes und API-Schlüssel liegen. CVE-2026-74800 betrifft den Auslieferungsweg von Dateien und öffnet Stored-XSS-Angriffe über hochgeladene HTML-Assets.

Was ist passiert?

SiYuan vor 3.7.4 setzt intern Debug-Funktionen und Datei-Handling so um, dass Angreifer an sensible Daten oder an ausführbaren Code kommen können. Das ist kein theoretisches Problem. Bei CVE-2026-74799 reicht der falsche Betriebsmodus, damit Debug-Endpunkte im Netzwerk erreichbar werden. Bei CVE-2026-74800 genügt eine präparierte Datei, die der Besitzer des Workspaces später öffnet.

Für Unternehmen im DACH-Raum ist das relevant, wenn SiYuan als Team-Wissensbasis, in Entwicklungsumgebungen oder auf selbst betriebenen Instanzen läuft. Dann hängen oft API-Schlüssel, Tokens oder interne Inhalte direkt an der Anwendung. Fällt so etwas über einen Dump oder über XSS heraus, ist der Schaden schnell größer als der eigentliche Bug.

Technische Details

CVE-2026-74799: SiYuan registriert Go-pprof-Debug-Endpunkte wie /debug/pprof/heap und weitere Dump-Funktionen ohne Authentifizierung, sofern der Startparameter --mode nicht exakt auf prod steht. Ein Angreifer kann Speicherinhalte auslesen und daraus Geheimnisse extrahieren, darunter AccessAuthCode und API-Schlüssel von KI-Anbietern.

CVE-2026-74800: Beim Ausliefern beliebiger Asset-Dateien setzt SiYuan die Header Content-Disposition und X-Content-Type-Options nicht korrekt. Das erlaubt Stored XSS. Ein authentifizierter Angreifer kann HTML-Dateien als Asset hochladen. Öffnet der Workspace-Besitzer den Link, läuft das Skript mit vollem Zugriff auf die Kernel-API.

Zur Betroffenheit nennt die Quelle nur Versionen vor 3.7.4. Ob weitere Wartungslinien, Forks oder angepasste Builds mitlaufen, bleibt offen. Auch zu Exploit-Aktivität nennt die Quelle keine belastbaren Hinweise.

Wer ist betroffen?

Betroffen sind alle Betreiber von SiYuan vor Version 3.7.4. Besonders kritisch ist das für Admins, die die Anwendung selbst hosten und nicht nur lokal auf dem Laptop nutzen. Wenn der Dienst in einem Team-Netzwerk, hinter einem Reverse Proxy oder mit angebundenen KI-APIs läuft, steigen die Risiken deutlich.

Privatanwender trifft es vor allem dann, wenn sie SiYuan mit sensiblen Inhalten, Tokens oder Cloud-Schlüsseln einsetzen. Wer die App nur offline und ohne vertrauliche Daten nutzt, hat weniger akuten Druck. Ganz entwarnen kann man aber auch dort nicht, weil ein ungünstig gesetzter Modus oder ein schlecht gepflegter Workspace genügt.

Empfohlene Maßnahmen

Das Update auf SiYuan 3.7.4 hat Priorität eins. Vorher sollten Betreiber prüfen, ob Instanzen außerhalb von prod laufen. Genau dort liegt bei CVE-2026-74799 der Knackpunkt. Wer die Anwendung per Container, systemd oder Reverse Proxy startet, muss die Startparameter und Umgebungswerte kontrollieren.

Für die XSS-Lücke hilft nur sauberes Asset-Handling: HTML-Dateien als hochladbare Inhalte möglichst einschränken oder deaktivieren, bis das Update eingespielt ist. Wer bereits verdächtige Assets im Workspace sieht, sollte sie löschen und den Inhalt prüfen. Danach gehören AccessAuthCode, API-Schlüssel und andere Tokens auf den Prüfstand. Im Zweifel sofort rotieren.

Zusätzlich lohnt ein kurzer Blick auf Logs und Netzwerkzugriffe. Debug-Endpunkte wie /debug/pprof/heap oder ähnliche Pfade sollten in produktiven Netzen grundsätzlich nicht offen sein. Wenn sie auftauchen, ist das ein Warnsignal, kein Betriebsdetail.

Einschätzung von CyberSecurity-News.de

Die Meldung ist ernst. Vor allem CVE-2026-74799 ist unangenehm, weil Debug-Funktionen in produktiven Umgebungen oft zu locker behandelt werden. Wer glaubt, ein interner Dienst sei automatisch sicher, irrt. Speicher-Dumps liefern im schlimmsten Fall genau die Geheimnisse, die ein Angreifer für den nächsten Schritt braucht.

Bei CVE-2026-74800 fällt auf, dass ein authentifizierter Angreifer den ersten Schritt schon geschafft haben muss. Das senkt die Schwelle etwas, hebt das Risiko aber nicht auf. Wenn der Workspace-Besitzer anschließend das Präparat öffnet, wird aus einer Datei ein Codeausführungsproblem mit vollem API-Zugriff. Die Informationslage bleibt knapp, doch die Kombination aus Stored XSS und Kernel-API-Zugriff ist in der Praxis klar brisant.

Wer SiYuan produktiv einsetzt, sollte jetzt handeln und nicht auf den nächsten regulären Patch-Zyklus warten. Für die meisten Leser ist das kein Massenproblem. Für Betreiber mit sensiblen Notizen, Tokens oder KI-Schlüsseln ist es aber ein echtes Incident-Szenario.

Fazit

SiYuan vor 3.7.4 bringt gleich zwei kritische Baustellen mit. CVE-2026-74799 kann vertrauliche Daten aus dem Speicher freilegen. CVE-2026-74800 erlaubt über manipulierte Assets Stored XSS und damit potenziell volle Kontrolle über die Kernel-API im Kontext des Opfers.

Die klare Linie ist einfach: auf 3.7.4 aktualisieren, Startmodus prüfen, hochladbare HTML-Dateien absichern und Geheimnisse rotieren, falls es einen Verdacht gibt. Wer die Anwendung nur nebenbei betreibt, sollte trotzdem kurz nachsehen. Solche Lücken leben davon, dass sie im Alltag übersehen werden.