Mehrere kritische Lücken in CHARX, Rails, SiYuan und TVox: Was Admins jetzt prüfen sollten

Kurzfassung

Mehrere Hersteller und Projekte haben kritisch eingestufte Schwachstellen veröffentlicht. Ein Teil davon erlaubt Zugriff ohne Anmeldung, bei anderen reicht schon lokaler Zugriff oder ein präparierter SQL-Befehl. Für Betreiber in Deutschland, Österreich und der Schweiz zählt vor allem eines: schnell prüfen, ob die eigenen Systeme überhaupt in den betroffenen Versionen laufen. Dann patchen. Nicht später.

Besonders heikel sind CVE-2026-44100 und CVE-2026-44101 in CHARX JupiCore und dem CHARX OCPP Agent, CVE-2026-64827 in Telenia Software TVox sowie die beiden SiYuan-Lücken CVE-2026-69083 und CVE-2026-69084. Dazu kommt CVE-2026-35847 in dnsmgr und eine kritische Schwachstelle in Rails Active Storage mit möglichem RCE-Pfad. Die Lage ist heterogen, aber das Muster ist klar: Authentifizierung, Eingabeprüfung und Zugriffskontrollen sind an mehreren Stellen zu schwach.

Was ist passiert?

Die Sicherheitsmeldungen betreffen unterschiedliche Produkte, folgen aber demselben Grundproblem: Angreifer können Funktionen missbrauchen, die zu offen erreichbar sind oder Eingaben zu locker verarbeiten. Bei CHARX geht es um Ladeinfrastruktur. Bei Rails um Webanwendungen. SiYuan ist eine Wissens- und Notizplattform, TVox eine Kommunikationslösung. dnsmgr liegt im lokalen Bereich und betrifft eine Datei mit einer Ping-Funktion. Das ist keine einzelne Kampagne, sondern eine Reihe separater Schwachstellen mit teils kritischer Tragweite.

Für die Praxis heißt das: Wer mehrere dieser Produkte im Bestand hat, sollte die Meldungen getrennt abarbeiten. Ein gemeinsamer Patch-Plan hilft nur begrenzt, weil die Risiken sehr unterschiedlich sind. Bei einigen Lücken droht Datenabfluss, bei anderen Manipulation oder Dienstausfall, bei Rails sogar potenziell Codeausführung.

Technische Details

CVE-2026-44100 betrifft den CHARX JupiCore Service. Ein entfernter Angreifer ohne Anmeldung kann Ladepunkte neu konfigurieren. Laut Beschreibung sind dadurch die Offenlegung von UID-Daten der Ladepunkte, Denial-of-Service und das Verändern von Dateien möglich.

CVE-2026-44101 trifft den CHARX OCPP Agent. Auch hier fehlt die Authentifizierung. Ein Angreifer kann die Backend-Verbindung umstellen, was wiederum Dienstunterbrechung und den Abfluss vertraulicher Daten auslösen kann.

CVE-2026-35847 liegt in dnsmgr Version 2.15 und älter. Ein lokaler Angreifer kann über die Ping-Funktion in CheckUtils.php eigenen Code ausführen. Ob dafür bereits ein niedriger interner Zugriff reicht, nennt die Quelle nicht im Detail. Klar ist aber: Wer auf dem System schon Fuß gefasst hat, kann damit deutlich weiterkommen.

Bei Rails betrifft die Schwachstelle Active Storage. Ein unauthentifizierter Angreifer kann beliebige Dateien lesen. Unter ungünstigen Bedingungen lässt sich das zu Remote Code Execution ausbauen. Auch hier gilt: Die genaue Angriffsfolge hängt vom Einsatzszenario ab, die Grundgefahr ist aber hoch genug für sofortiges Handeln.

CVE-2026-64827 betrifft Telenia Software TVox 26.5.3 und ältere 26.x-Varianten sowie 24.9.21 und ältere 24.x-Versionen. Die Authentifizierung in set_env.php lässt sich umgehen, wenn der Pfad mit /login_admin.php manipuliert wird. Danach sind alle PHP-Skripte unter dem manager-HTML-Verzeichnis ohne Login erreichbar.

CVE-2026-69083 und CVE-2026-69084 betreffen SiYuan vor Version 3.7.3 beziehungsweise Versionen bis einschließlich 3.7.2. Bei der ersten Lücke können Angreifer über das fullTextSearchAssetContent-Endpoint SQL-Injection ausnutzen und auf die Lese-Schreib-Datenbank zugreifen. Damit sind Lesen, Ändern und Löschen von Cross-Notebook-Daten möglich. Die zweite Lücke reicht über das /api/search/searchEmbedBlock-Endpoint, das SQL-Befehle ungefiltert an die Datenbank weiterreicht. Laut Beschreibung sind gestapelte Befehle möglich; betroffen sind offene Klartext-Notebooks, verschlüsselte pro-Notebook-Bereiche bleiben außen vor.

Wer ist betroffen?

Direkt betroffen sind Betreiber der genannten Produkte und Versionen. Das betrifft im DACH-Raum vor allem Unternehmen, die Ladeinfrastruktur mit CHARX verwalten, Rails-basierte Webanwendungen betreiben, TVox als Kommunikationsplattform einsetzen oder SiYuan intern nutzen. Bei dnsmgr spielt der lokale Zugriff eine Rolle. Für klassische Endnutzer ist das Thema nur dann relevant, wenn sie eines der genannten Produkte privat oder in einer kleinen Organisation selbst betreiben. Für die meisten Leser ist das also kein Massenproblem, aber für betroffene Admins sehr wohl akut.

Wichtig ist die Versionsfrage. Bei einigen Meldungen nennt die Quelle klare Grenzwerte, etwa bei TVox und SiYuan. Bei Rails fehlt in der vorliegenden Information die genaue Versionsabgrenzung. Ob ältere oder nur bestimmte Release-Zweige betroffen sind, bleibt offen. Wer Rails produktiv einsetzt, sollte die Herstellerhinweise separat prüfen.

Empfohlene Maßnahmen

Erstens: betroffene Versionen inventarisieren. Ohne saubere Bestandsaufnahme verpufft jeder Patch-Plan. Prüfen Sie CHARX JupiCore, CHARX OCPP Agent, dnsmgr, Rails mit Active Storage, TVox und SiYuan auf den genannten Versionen.

Zweitens: Updates priorisieren, die unauthentifizierte Angriffe ermöglichen. Das sind aus Sicht des Risikos zuerst CVE-2026-44100, CVE-2026-44101, die Rails-Schwachstelle, CVE-2026-64827 sowie CVE-2026-69083 und CVE-2026-69084. Diese Lücken brauchen keinen gültigen Benutzerzugang oder lassen sich mit sehr wenig Vorbereitung ausnutzen.

Drittens: betroffene Dienste vorübergehend einschränken, falls ein Patch nicht sofort möglich ist. Das kann Netzsegmentierung, Zugriff nur aus Verwaltungsnetzen, das Abschalten exponierter Schnittstellen oder eine schnelle Härtung der Reverse-Proxy-Regeln bedeuten. Bei SiYuan und TVox lohnt außerdem ein Blick auf externe Erreichbarkeit und auf Rollen, die bisher zu großzügig vergeben wurden.

Viertens: Protokolle auf Auffälligkeiten prüfen. Unerwartete Konfigurationsänderungen, Zugriffe auf Login-Endpunkte, SQL-Fehler, ungewöhnliche Dateizugriffe und Neustarts von Diensten können Hinweise liefern. Bei CHARX und TVox gehören auch Änderungen an Verbindungen und Authentifizierungswegen in den Fokus. Wer eine Ladenetz- oder Kommunikationsplattform betreibt, sollte außerdem prüfen, ob Konfigurationen ohne Freigabe geändert wurden.

Fünftens: lokale Angriffsflächen ernst nehmen. Bei dnsmgr reicht nach Lage der Quelle ein lokaler Angreifer. Das klingt harmloser als ein Remote-Exploit, ist in gemischten Unternehmensnetzen aber kein Randthema. Ein kompromittierter Arbeitsplatz oder ein falsch abgesicherter Admin-Rechner reicht im Zweifel als Startpunkt.

Einschätzung von CyberSecurity-News.de

Die Lage ist ernst, aber nicht gleichmäßig. Am schärfsten sind die Lücken, die ohne Anmeldung ausnutzbar sind und direkt in Konfigurationsänderung, Datenabfluss oder RCE führen können. Genau dort liegt das Problem in mehreren der hier genannten Fälle. Das macht die Meldung für Betreiber von Ladeinfrastruktur, Rails-Anwendungen, TVox und SiYuan relevant, während dnsmgr eher den internen Admin-Kern trifft.

Die Informationslage ist teilweise dünn. Bei Rails bleibt die genaue betroffene Version in der vorliegenden Quelle offen, und bei einigen Produkten fehlt der tiefere Exploit-Kontext. Das ist in der Praxis unbefriedigend, ändert aber nichts an der Handlungslage: Patchen, absichern, prüfen. Wer jetzt auf eine hübsch aufbereitete Gesamtbewertung wartet, verliert Zeit. Gerade bei unauthentifizierten Schwachstellen ist das der falsche Reflex.

Fazit

Für DACH-Unternehmen mit den betroffenen Produkten gilt: sofort inventarisieren, die angegebenen Versionen prüfen und Updates priorisiert ausrollen. Die Mischung aus fehlender Authentifizierung, möglicher Datenoffenlegung und in Einzelfällen Codeausführung ist zu heikel für abwartendes Verhalten. Besonders CHARX, TVox, Rails und SiYuan gehören auf die Tagesordnung des nächsten Patchfensters. Wer dort zuständig ist, sollte nicht erst auf eine zweite Warnung warten.