Die ThingsBoard-CVE-Liste 2026 gelesen: eine Plattform-Lücke, elf aus Abhängigkeiten

WZ-IT führt thingshost weiter. Aktuelles Hosting ab 159,80 € netto/Monat; Einrichtung und Service Level gemäß Angebot. Frühere Paketpreise, Standortlisten und Kostenvergleiche in diesem datierten Artikel beschreiben das damalige Angebot, nicht die aktuellen WZ-IT-Konditionen. Aktuellen Leistungsumfang ansehen.

Wer einen Schwachstellen-Scanner auf eine ThingsBoard-Installation loslässt, bekommt für 2026 eine unangenehm lange Liste. Bei der Prüfung von elf häufig genannten Kennungen gegen die NVD blieb allerdings genau eine übrig, die ThingsBoard selbst betrifft: CVE-2026-53676. Die übrigen zehn liegen in Spring, pgjdbc, Apache OpenNLP, Netty und Apache Tomcat, also in Bibliotheken, die die Plattform mitbringt. Diese Unterscheidung ist keine Wortklauberei, sie bestimmt, wer patchen kann und wann. Dieser Beitrag sortiert die Liste und zieht die Konsequenzen für den Betrieb.

Auch interessant: NIS2 für OT- und IIoT-Plattformen · ThingsBoard CE vs. PE 2026 · ThingsBoard: Cloud oder Managed Hosting?

Inhaltsverzeichnis

• Die eine, die zählt: CVE-2026-53676
  • Wie schlimm ist das?
• Und die anderen zehn?
• Warum die Unterscheidung den Handlungsweg bestimmt
• Ein Vorgehen für Scanner-Meldungen
• Was das für die Betriebsplanung heißt
• thingshost: Managed ThingsBoard aus Deutschland
• Fazit
• Quellen

Die eine, die zählt: CVE-2026-53676

ThingsBoard enthält eine Prototype-Pollution-Schwachstelle, die zur Ausführung beliebigen Codes in einem Sandbox-Kontext führen kann, und zwar durch einen Nutzer, der sich mit Tenant-Administrator-Rechten am betroffenen Produkt anmelden kann [1].

Die harten Daten aus der NVD [1]:

Betroffen sind laut der JVN-Meldung alle Versionen vor 4.3.1.2 [2]. Gemeldet wurde die Schwachstelle von Hiroki Imai von LAC Co., Ltd. an die IPA, die Koordination lief über JPCERT/CC [2]. Der Fix trägt in ThingsBoard den Titel „Hardened remote JS executor script invocation" [2][3].

Wie schlimm ist das?

Hier lohnt die Genauigkeit, weil die beiden CVSS-Werte auseinandergehen und beide recht haben.

Die Voraussetzung ist erheblich: Der Angreifer muss sich bereits mit Tenant-Administrator-Rechten anmelden können. Das ist keine anonyme Ausnutzung über das Internet, sondern eine Rechteausweitung ausgehend von einem ohnehin hochprivilegierten Konto.

Relevant wird das trotzdem, und zwar überall dort, wo Mandanten nicht ausschließlich vom Plattformbetreiber verwaltet werden. Wer Kunden oder Fachabteilungen eigene Mandanten mit eigenen Administratoren gibt, hat genau die Konstellation, in der die Sandbox das trennende Element sein sollte. Dann ist eine Lücke in dieser Sandbox kein akademisches Problem.

Und die anderen zehn?

Die Liste, die in Aggregatoren unter ThingsBoard geführt wird, sieht deutlich bedrohlicher aus, als sie ist. Bei der Prüfung gegen die NVD ergab sich folgendes Bild [4]:

Zehn von elf geprüften Kennungen betreffen also Fremdkomponenten. Das ist keine Kritik an ThingsBoard: Eine Java-Plattform dieser Größe bringt zwangsläufig Spring, Netty, Tomcat und einen JDBC-Treiber mit, und jede dieser Komponenten hat ihren eigenen Schwachstellenstrom.

Ein Detail verdient Beachtung: CVE-2026-43512 ist in der NVD als DEPRECATED gekennzeichnet [4]. Wer diese Kennung in einem Bericht als offene kritische Lücke führt, führt eine Karteileiche.

Warum die Unterscheidung den Handlungsweg bestimmt

Das ist der eigentliche Punkt dieses Beitrags, und er gilt weit über ThingsBoard hinaus.

Bei einer Plattform-Lücke ist der Weg klar: Das Projekt veröffentlicht ein Release, Sie aktualisieren. Bei CVE-2026-53676 ist das Version 4.3.1.2 [2].

Bei einer Abhängigkeits-Lücke ist der Weg länger. Die Bibliothek veröffentlicht einen Fix. Danach muss ThingsBoard die neue Version einziehen, testen und ein Release bauen. Erst dann können Sie aktualisieren. Zwischen der Veröffentlichung der Netty-Schwachstellen am 13. Mai und einem ThingsBoard-Release, das die neue Netty-Version enthält, liegt zwangsläufig Zeit.

In dieser Zeit passiert Folgendes: Ihr Scanner meldet die Kennung. Es gibt keinen Patch, den Sie einspielen könnten. Und die Frage, die Ihnen dann gestellt wird, lautet nicht „ist das gefixt", sondern „warum ist das seit sechs Wochen offen".

Die ehrliche Antwort ist selten befriedigend, aber sie ist wichtig: Ein Betreiber kann eine Abhängigkeits-Lücke nicht schließen, bevor das Projekt sie einzieht. Er kann den betroffenen Pfad absichern, einschränken oder abschalten. Patchen kann er ihn nicht.

Ein Vorgehen für Scanner-Meldungen

Drei Schritte, die den Großteil der Aufregung nehmen.

1. Gegen die NVD prüfen, nicht gegen einen Aggregator. Die Zuordnung „das ist eine ThingsBoard-CVE" stammt bei Aggregatoren oft aus einer Abhängigkeitsbeziehung, nicht aus der Schwachstelle selbst. Der NVD-Eintrag nennt die tatsächlich betroffene Komponente. Für die Liste oben war das der Unterschied zwischen elf und einer.

2. Plattform oder Abhängigkeit? Davon hängt ab, ob ein ThingsBoard-Release die Lösung ist oder ob Sie auf eines warten.

3. Ist der Pfad in Ihrer Installation erreichbar? Apache OpenNLP mit 9.8 ist beeindruckend auf dem Papier, aber nur relevant, wenn die betroffene Funktion genutzt wird. CVE-2026-53676 mit 8.6 setzt ein Tenant-Administrator-Konto voraus. CVSS beschreibt die technische Schwere, nicht Ihre Exponierung.

Erst nach diesen drei Schritten ist die Frage nach der Dringlichkeit sinnvoll beantwortbar. Wer sie überspringt, patcht in der falschen Reihenfolge oder gar nicht, weil die Liste zu lang wirkt, um sie anzufangen.

Was das für die Betriebsplanung heißt

Für ThingsBoard bedeutet das konkret:

• Dem aktuellen Release-Zweig folgen, statt auf einer Version zu verharren. Aktualisierte Abhängigkeiten kommen nur über Releases herein, und wer drei Versionen zurückliegt, sammelt Abhängigkeits-CVEs an, ohne selbst etwas falsch gemacht zu haben.
• Tenant-Administrator-Konten wie privilegierte Konten behandeln. CVE-2026-53676 ist eine Erinnerung daran, dass diese Rolle in ThingsBoard viel kann und die Sandbox die Grenze ist, nicht die Rollenzuweisung.
• Die Release-Tabelle als Quelle nehmen, nicht den Scanner-Bericht [5].
• Bei Meldungen an die Geschäftsführung die Unterscheidung mitliefern. Eine Liste mit elf Einträgen und eine Liste mit einer Plattform-Lücke plus zehn Abhängigkeiten führen zu unterschiedlichen Entscheidungen.

Wie sich das in die Anforderungen aus NIS2 einordnet, haben wir im Beitrag zu NIS2 für OT- und IIoT-Plattformen behandelt. Kurz gefasst: Schwachstellenbehandlung ist dort eine benannte Pflicht, und ein nachvollziehbares Verfahren zählt mehr als eine leere Liste.

thingshost: Managed ThingsBoard aus Deutschland

Wir betreiben ThingsBoard als dedizierte Instanz, standardmäßig in Deutschland, mit AV-Vertrag. Updates fahren wir mit Ankündigung und Wartungsfenster, einschließlich der Release-Wechsel, über die aktualisierte Abhängigkeiten einlaufen.

Der Standard-Plan mit der Community Edition kostet in der Region Deutschland ab 149,90 € im Monat netto, empfohlen bis 100 Geräte und ohne lizenzbedingte Gerätegrenze.

Was wir nicht können und auch nicht behaupten: eine Abhängigkeits-Lücke schließen, bevor ThingsBoard sie in ein Release zieht. Was wir tun, ist den betroffenen Pfad zu bewerten, ihn wo möglich abzusichern und Sie zu informieren, statt Sie die Kennung aus einem Scanner-Bericht erfahren zu lassen.

Leistungsumfang und Bereitstellung mit WZ-IT abstimmen. Bereitstellung und Vertragsbedingungen werden mit WZ-IT im Angebot vereinbart. Es gibt kein Self-Service-Portal und kein automatisches Testabonnement.

Preise ansehen · Kontakt aufnehmen

Fazit

Die ThingsBoard-CVE-Lage 2026 ist ruhiger, als die Listen vermuten lassen. Eine Plattform-Schwachstelle, CVE-2026-53676, behoben ab Version 4.3.1.2, mit einer Voraussetzung, die sie in Mehrmandanten-Umgebungen ernst und in Einzelbetrieben überschaubar macht.

Der Rest ist der normale Schwachstellenstrom eines Java-Stacks. Er verschwindet nicht, er lässt sich nicht durch Anbieterwahl vermeiden, und er wird durch das Zusammenzählen von CVSS-Werten nicht verständlicher. Was hilft, ist die Unterscheidung: Wer patchen kann, wer warten muss, und ob der betroffene Pfad bei Ihnen überhaupt erreichbar ist.

thingshost ist ein unabhängiger Managed-Hosting-Anbieter und steht in keiner Verbindung zu ThingsBoard, Inc., der Apache Software Foundation, Broadcom oder den Netty-Projektbeteiligten. Die CVE-Angaben folgen der National Vulnerability Database, Stand 05.09.2026; Bewertungen und Zuordnungen können sich ändern. Dieser Beitrag ordnet technisch ein und ersetzt keine Sicherheitsberatung.

Quellen

• [[1]] NVD: CVE-2026-53676 – Prototype Pollution in ThingsBoard, CVSS 4.0 8.6 / CVSS 3.0 7.2, veröffentlicht 17.06.2026, Voraussetzung TENANT_ADMIN
• [[2]] JVN JVN16937365 – betroffene Versionen vor 4.3.1.2, Melder Hiroki Imai (LAC Co., Ltd.), Koordination JPCERT/CC
• [[3]] thingsboard/thingsboard · Pull Request #15600 – „Hardened remote JS executor script invocation"
• [[4]] National Vulnerability Database – Suchoberfläche für die geprüften Kennungen (Spring, pgjdbc, Apache OpenNLP, Netty, Apache Tomcat)
• [[5]] ThingsBoard Release Table – offizielle Übersicht der Versionen
• thingshost.de – Managed ThingsBoard Hosting