Am Anfang stand keine Sicherheitsuntersuchung. Wir wollten lediglich eine einfache Frage beantworten: Was speichert ein Bambu Lab X1 Carbon eigentlich in seiner verschlüsselten Diagnosedatei?

Das Testsystem konnte den Export zwar erzeugen, lesen ließ er sich für den Eigentümer aber nicht. Statt einer verständlichen Übersicht mit Zeitstempeln, Fehlercodes und Sensorwerten lag eine verschlüsselte Datei vor. Also baten wir Bambu Lab um eine lesbare Bereitstellung der maschinengenerierten Diagnose- und Produktdaten dieses Testsystems.

Was nach einer überschaubaren Supportanfrage klingt, brauchte mehrere Anläufe. Die erste Anfrage ging am 4. Juni 2026 ein. Einen Tag später wurde sie zunächst als Bestell-, Logistik- oder allgemeines Supportthema eingeordnet und weiterverwiesen. Am 14. Juni präzisierten wir die Anfrage erneut und baten Bambu Lab um eine lesbare Bereitstellung der Diagnosedaten des separat betriebenen Testsystems und baten unter Verweis auf den EU Data Act um eine interne Weiterleitung an die zuständige Rechts-, Datenschutz- oder Datenstelle.

Am 7. Juli folgte die nächste Weiterleitung, diesmal an das Privacy Team. Erst am 13. Juli 2026, 39 Tage nach der ersten Anfrage, kam die entscheidende Nachricht. Bambu Lab entschuldigte sich ausdrücklich für die Verzögerung und die wiederholten Weiterleitungen und stellte den Diagnoseexport nach eigener Angabe entschlüsselt bereit. Das Transportarchiv blieb passwortgeschützt, das Kennwort kam in einer separaten E-Mail.

Damit war die Datei vorhanden, aber noch lange nicht verständlich. Der Windows-Explorer konnte das 7z-Archiv nicht öffnen. Mit 7-Zip erschien zunächst eine TAR-Datei, darin wiederum Hunderte komprimierte Protokolle und proprietäre Binärdateien. Aus dem vermeintlich einzelnen Log wurde schrittweise ein Datenpaket mit 299 Dateien und 3,18 GB entpacktem Inhalt.

Genau an diesem Punkt begann die eigentliche Untersuchung. Wir werteten das Paket vollständig und ausschließlich lesend aus. Untersucht wurde ein technisches Testsystem. Projektbezeichnungen, Modellnamen, Benutzerkennungen und alle Angaben, aus denen sich Kundenbeziehungen, Produktionsvolumen oder Auftragslage ableiten ließen, haben wir entfernt.

Die naheliegende Erwartung war: Temperaturen, Fehlermeldungen, Sensorwerte und Informationen zur Firmware. All das war enthalten. Es war aber nur ein Teil der Antwort.

Was nach dem Entschlüsseln tatsächlich vorlag

Untersucht wurde der Diagnoseexport eines Bambu Lab X1 Carbon mit Firmware 01.11.02.00. Bambu Lab bezeichnete den Inhalt als entschlüsseltes Log. Für die technische Analyse überführten wir das bereitgestellte Archiv zusätzlich in eine unverschlüsselte ZIP-Datei, damit alle enthaltenen Ebenen reproduzierbar und getrennt verarbeitet werden konnten.

Die Originaldatei blieb unverändert. Wir entpackten alle Archive und komprimierten Einzeldateien in ein separates Arbeitsverzeichnis. Keine Datei aus dem Paket wurde ausgeführt. Enthaltene Links, Zugangscodes und Token verwendeten wir nicht und testeten sie auch nicht auf ihre Gültigkeit.

Schon die Größenentwicklung zeigte, dass es sich nicht um ein gewöhnliches Textprotokoll handelte: Aus rund 450 MB Archivdaten wurden beim Entpacken mehr als 3,18 GB Nutzdaten. Der Export war eher ein technisches Systemabbild als eine einzelne Logdatei.

Der Hash dient der technischen Nachvollziehbarkeit. Wir veröffentlichen das Originalarchiv nicht, weil es sensible Rohdaten enthält.

Wie ist der Diagnoseexport aufgebaut?

Der Export gliedert sich in vier Hauptbereiche. Die Verzeichnisstruktur ist übersichtlich, die Datenmenge innerhalb der Bereiche allerdings sehr unterschiedlich.

Wichtig: Die Zahl der Dateien oder Logeinträge ist keine Angabe zur Zahl der Druckaufträge. Ein einzelner Vorgang kann sehr viele Einträge erzeugen. Wir nennen deshalb keine Projektlisten, Modellnamen oder zählbaren Auftragskontexte.

Welche Daten sind für die Diagnose erwartbar?

Ein großer Teil der Protokolle ist technisch plausibel und für die Fehlersuche nützlich. Dazu gehören unter anderem:

• Firmware- und Hardwareversionen
• Bootvorgänge, Neustarts und Prozesszustände
• Temperaturen von Düse, Druckbett, Systemchip und AMS
• Lüfter-, Motor-, Achsen- und Extruderzustände
• Druckfortschritt, Kalibrierungen und HMS-Fehlermeldungen
• AMS-Erkennung, Filamenttyp, Farbe, Durchmesser und Restmenge
• Speicher-, CPU- und Systemlast
• Netzwerkzustände und Verbindungsfehler
• Lidar-, Xcam- und Bilderkennungsprozesse

Solche Daten helfen dabei, sporadische Fehler zeitlich einzuordnen. Problematisch wird ein Diagnoseexport nicht dadurch, dass er ausführlich ist. Kritisch wird es dort, wo Geheimnisse, Benutzerbezug oder nicht erwartete Projektinformationen in denselben Datenstrom geraten.

Bis hierhin wirkte der Export wie ein sehr ausführliches, aber grundsätzlich erwartbares Diagnosepaket. Der entscheidende Moment kam bei der Suche nach Werten, die in einer Supportdatei nicht im Klartext stehen sollten. Der erste Treffer lag nicht tief in einem exotischen Binärformat, sondern offen im normalen Syslog.

Fund 1: Der LAN-Zugriffscode stand im Syslog

Der lokale LAN-Zugriffscode des Testsystems erschien im untersuchten Syslog 244-mal im Klartext. Wir erkannten genau einen eindeutigen Code und entfernten den Wert aus allen Auswertungen.

Für die Praxis bedeutet das: Nach einer externen Auswertung oder einer Weitergabe des Roharchivs sollte der LAN-Zugriffscode vorsorglich neu erzeugt werden.

Fund 2: Token und alte Speicherabbilder

Der nächste Fund lag in einem Bereich, den die meisten Nutzer wahrscheinlich nie öffnen würden: in drei Coredumps. Ein Coredump ist ein Abbild des Arbeitsspeichers eines Programms zum Zeitpunkt eines Absturzes. Für Entwickler ist das wertvoll, weil sich daraus der Prozesszustand rekonstruieren lässt. Gleichzeitig kann darin alles landen, was das Programm gerade im Speicher hielt.

Im untersuchten Paket waren Coredumps der Prozesse bbl_screen, forward und mushu enthalten. Zwei Abbilder stammten aus dem Jahr 2023, eines aus dem Jahr 2026.

Darin wurden unter anderem erkannt:

• zwei vollständige JWT-Authentifizierungstoken
• zwei weitere Bearer-artige Token unbekannten Formats
• Benutzer-, Geräte-, Netzwerk- und Profilstrings
• Teile des Druck- und Bedienkontexts
• G-Code-Fragmente

Die beiden auswertbaren JWTs waren zum Zeitpunkt der Analyse bereits abgelaufen. Die beiden anderen Token testeten wir nicht. Wir stellten keine Verbindung zu einem Dienst her und probierten keinen Zugriff aus.

Fund 3: Modellvorschauen und Projektkontext

Beim Durchsuchen des aktuellen mushu-Coredumps tauchte dann etwas auf, das in einer klassischen Fehlerliste kaum jemand erwarten würde: rekonstruierbare Bilder. Insgesamt ließen sich 13 gültige PNG-Dateien extrahieren. Darunter waren kleine Oberflächenressourcen, Platzhaltergrafiken und acht unterschiedliche Modell- oder Bauteilvorschauen.

Diese Bilder waren keine nachgewiesenen Livekameraaufnahmen. Sie stammten aus dem Prozessspeicher der Bedienoberfläche und zeigten Vorschauen von Modellen beziehungsweise gedruckten Teilen.

Zusätzlich enthielten die lesbaren Logs:

• G-Code-Dateinamen und Druckkontext
• Projekt-, Profil-, Task-, Job- und Modellkennungen
• Druckplatten- und AMS-Zuordnungen
• zahlreiche Druckparameter
• 149 Vorkommen vorab signierter Links zu 3MF-Objekten

Die vorab signierten Links waren zum Analysezeitpunkt abgelaufen. Wir öffneten sie nicht und veröffentlichen ihre vollständigen Werte nicht.

Fund 4: AMS-, Material- und Nutzungsdaten

Die AMS- und Materialprotokolle sind ungewöhnlich detailliert. Erfasst wurden unter anderem:

• AMS-Temperatur und Luftfeuchtigkeit
• Filamenttyp und Materialuntermarke
• Farbe und Durchmesser
• Düsen- und Betttemperaturgrenzen
• Trocknungstemperatur und Trocknungszeit
• Restmenge
• RFID-Tag-UID, Tray-UUID sowie AMS- und Chip-Kennungen

Für die Diagnose von Zuführungsproblemen, Materialerkennung oder Feuchtigkeit ist das nachvollziehbar. In Kombination entsteht jedoch eine recht genaue technische Nutzungshistorie.

Hinzu kommen 73.882 Systemmonitor-Momentaufnahmen. Der typische Abstand lag bei zehn Sekunden. Dadurch lassen sich Lastzustände, Prozessaktivität, Speicherverbrauch und SoC-Temperaturen über mehrere Wochen zeitlich nachvollziehen.

Auch hier gilt: Wir leiten daraus weder eine Auslastung noch eine Zahl von Aufträgen ab. Ein Monitor-Snapshot beschreibt einen Systemzustand, keinen Kundenauftrag.

Fund 5: Cloud- und Telemetriepfade

Nach den lokalen Funden stellte sich die nächste Frage: Welche Daten bleiben im Gerät, und welche Kommunikationswege sind im Protokoll erkennbar? Die Logs zeigen mehrere voneinander zu trennende Datenpfade:

• 94 Meldungen mit iot upload success
• 112.394 Meldungen mit compress msg send ok
• MQTT- und Mosquitto-Kontext
• vorab signierte Links zu 3MF-Objekten
• eine Recorder-Konfiguration mit upld_en=yes und dest=cloud für den CMN-Datenstrom
• lokale Verweise auf Bilderkennungsdateien und fehlgeschlagene Dateiübertragungen

Diese Funde belegen laufende Cloud- und Telemetriekommunikation. Sie belegen nicht, dass das vollständige Supportarchiv automatisch übertragen wurde.

Der finale Diagnoseexport war im Syslog als eigener, ausdrücklich angestoßener Vorgang erkennbar. Beim untersuchten Export waren die Optionen camera=0 und gcode=0 gesetzt. Frühere Exportaufrufe im selben Log zeigen allerdings, dass Kamera- und G-Code-Inhalte grundsätzlich auswählbar sein können.

Eine allgemeine Einordnung zu Cloud, STL und Prozessdaten im Inhouse-3D-Druck geben wir im Beitrag Cloud, STL, Telemetrie: Warum Inhouse-3D-Druck Datenrisiken erzeugt.

Was verraten die proprietären Binärdaten?

Am Ende blieb der größte und zugleich undurchsichtigste Teil des Pakets: 266 CMN-Dateien mit zusammen rund 1,60 GB entpackten Binärdaten. Sie ließen sich öffnen, aber nicht wie ein Textprotokoll lesen.

Die Dateien sind nicht einfach verschlüsseltes Zufallsrauschen. Wir identifizierten:

• 43.097.919 hochkonfidente gerahmte Datensätze
• 17 dominante Rahmenstrukturen
• ein wiederkehrender Marker 0xCC
• konsistente Längen-, Typ-, Gruppen- und Periodenfelder
• wiederkehrende Periodenwerte wie 100, 1.000 und 10.000 Einheiten

Damit ist eine stabile maschinelle Struktur nachgewiesen. Nicht nachgewiesen ist die Bedeutung jedes einzelnen Nutzfeldes. Ohne ein öffentliches Datenschema lässt sich nicht seriös behaupten, welcher Rahmen beispielsweise eine Temperatur, Motorposition, Beschleunigung, Lidar-Messung oder einen anderen Zustand beschreibt.

Auch eingebettete Standardformate wurden geprüft. In den CMN-Dateien ließen sich keine vollständigen ZIP-, SQLite-, JPEG-, PNG-, JSON- oder XML-Container verifizieren.

Was wurde ausdrücklich nicht gefunden?

Nach mehreren auffälligen Treffern hätten wir den Rest der Geschichte leicht möglichst dramatisch erzählen können. Genau das wäre fachlich falsch. Deshalb halten wir ebenso fest, welche häufig vermuteten Inhalte nicht nachgewiesen wurden.

Wie passen die Funde zu Aussagen von Bambu Lab?

Bambu Lab erklärte im Dezember 2023, Logdateien würden Maschinenbefehle und Sensorwerte erfassen. Außerdem seien sie nur zugänglich, wenn der Kunde sie ausdrücklich und manuell für die Fehlersuche hochlädt. Vollständige 3MF- oder STL-Dateien seien nicht enthalten. Offizielle Stellungnahme von Bambu Lab

Der untersuchte Export bestätigt Teile dieser Aussage:

• Der Exportvorgang war manuell angestoßen.
• Maschinenbefehle und Sensorwerte bilden einen großen Teil der Daten.
• Vollständige eigenständige 3MF- und STL-Dateien wurden nicht gefunden.

Die Beschreibung ist für den konkreten Export dennoch unvollständig. Zusätzlich vorhanden waren unter anderem ein LAN-Zugriffscode, Authentifizierungstoken, Netzwerk- und Profilkontext, Modellvorschaubilder, Objektlinks und alte Prozessspeicherabbilder.

Bambu Lab hat 2025 ein Trust Center und ein ausführliches Sicherheits-Whitepaper veröffentlicht. Dort beschreibt der Hersteller unter anderem verschlüsselte Kommunikation, sichere Geräteauthentifizierung sowie Datenschutzfunktionen wie LAN-Only Mode, Offline-Updates und Stealth Printing. Bambu Lab Trust Center und Sicherheitsdokumentation

Diese Maßnahmen sind wichtig. Sie lösen aber eine andere Schutzebene als die hier untersuchte Frage: Welche Inhalte gelangen in ein Diagnosepaket, wenn ein Nutzer es exportiert?

Was sollten Nutzer und Unternehmen daraus ableiten?

Ein Diagnoseexport sollte nicht wie eine harmlose Textdatei behandelt werden. Praktisch ist er eher mit einem umfangreichen technischen Systemabbild vergleichbar.

Für einzelne Nutzer

• Roharchive nur über den vorgesehenen Supportkanal senden.
• Diagnosepakete nicht in Foren, öffentlichen Cloudordnern oder sozialen Netzwerken teilen.
• Nach externer Weitergabe den LAN-Zugriffscode erneuern.
• Aktive Kontositzungen und Gerätebindungen vorsorglich prüfen.
• Vor einer Veröffentlichung ausschließlich redigierte Screenshots und aggregierte Tabellen verwenden.

Für Unternehmen mit Inhouse-3D-Druck

• festlegen, wer Diagnoseexporte erstellen und versenden darf
• Supportdaten als potenziell vertrauliche technische Daten klassifizieren
• kritische Bauteile, Projekte und Testsysteme organisatorisch trennen
• Exportzeitraum und Datenklassen dokumentieren
• nachvollziehbar festhalten, an wen das Archiv übermittelt wurde
• Roharchive nach Abschluss des Supportfalls kontrolliert löschen

Das passt zu einer größeren Entwicklung: Ein Desktop-Drucker im Unternehmen ist irgendwann nicht mehr nur ein Werkzeug auf dem Tisch. Er wird Teil der technischen Infrastruktur. Dann zählen neben Druckqualität auch Datenhoheit, Verantwortlichkeiten und reproduzierbare Prozesse.

Ergänzend behandeln wir das Thema in Inhouse-3D-Druck 2026: Kostenfalle Cloud, Abo und Compliance sowie im Beitrag Eigener Bambu Lab im Unternehmen: ungenutztes Potenzial und nächste Schritte.

Was Bambu Lab aus unserer Sicht verbessern sollte

Die Diagnosefunktionen selbst sind sinnvoll. Die Verbesserungen sollten deshalb nicht auf weniger Diagnose hinauslaufen, sondern auf einen kontrollierteren Export:

1. Geheimnisse automatisch entfernen: Zugangscodes und Token dürfen nicht in exportierten Logs erscheinen.
2. Coredumps zeitlich begrenzen: Mehrjährige Speicherabbilder gehören nicht ohne klaren Anlass in einen aktuellen Supportfall.
3. Exportvorschau anbieten: Nutzer sollten vorab sehen, welche Datenklassen und Zeiträume enthalten sind.
4. Ticketbezogene Auswahl ermöglichen: Kamera, G-Code, Coredumps, Netzwerk und Recorder-Daten sollten getrennt auswählbar sein.
5. Lesbare Zusammenfassung erzeugen: Ein nutzerfreundlicher Bericht könnte sensible Rohdaten ergänzen oder in einfachen Fällen ersetzen.
6. Recorder-Format dokumentieren: Zumindest Datenkategorien und Zweck der proprietären Streams sollten transparent beschrieben werden.

Fazit: Kein Spionagebeweis, aber ein sensibler Diagnoseexport

Der untersuchte Bambu-Lab-Diagnoseexport ist technisch umfassend und für die Fehleranalyse wahrscheinlich sehr wertvoll. Er enthält jedoch mehr als Temperaturen und Fehlermeldungen.

Nachgewiesen wurden unter anderem:

• ein LAN-Zugriffscode im Klartext
• Authentifizierungstoken in Coredumps
• mehrere Jahre alte Speicherabbilder
• Modellvorschaubilder und Projektkontext
• detaillierte Material-, AMS-, Netzwerk- und Systemdaten
• strukturierte, aber nicht öffentlich dokumentierte Recorder-Daten

Nicht nachgewiesen wurden gezielte Überwachung, Datendiebstahl oder ein automatischer Upload des vollständigen Supportarchivs.

Die sachliche Schlussfolgerung lautet deshalb: Ein Diagnoseexport ist kein gewöhnliches Logfile. Er sollte wie eine sensible technische Datensammlung behandelt werden.

Für Unternehmen ist das ein gutes Beispiel dafür, warum Inhouse-3D-Druck irgendwann klare Regeln braucht. Standardteile können intern sinnvoll sein. Bei vertraulichen Entwicklungen, kritischen Geometrien oder wiederkehrender Fertigung lohnt sich ein Prozess, bei dem Verantwortung, Datenweg und Ergebnis von Anfang an sauber definiert sind.

Häufige Fragen zum Bambu-Lab-Diagnoseexport

Beweist der Diagnoseexport, dass Bambu Lab Nutzer ausspioniert?

Nein. Das untersuchte Paket liefert keinen Beweis für gezielte Überwachung oder Datendiebstahl. Es zeigt aber, dass Diagnoseexporte sensible technische und personenbezogene Kontexte enthalten können.

Enthält die Bambu-Lab-Logdatei vollständige STL- oder 3MF-Dateien?

Im untersuchten Paket wurden keine eigenständigen vollständigen STL- oder 3MF-Quelldateien gefunden. Enthalten waren jedoch Modellvorschauen, Objektlinks, Dateinamen, Kennungen und Druckkontext.

Ist ein Bambu-Lab-Drucker deshalb grundsätzlich unsicher?

Diese Untersuchung bewertet den Inhalt eines konkreten Diagnoseexports eines Testsystems. Sie ist kein allgemeines Sicherheitsurteil über alle Geräte, Modelle, Firmwarestände oder Betriebsarten.

Sollte man Diagnoseprotokolle an den Support senden?

Bei einem technischen Problem kann das sinnvoll und notwendig sein. Das Archiv sollte ausschließlich über den vorgesehenen Supportkanal übermittelt und nicht öffentlich geteilt werden. Nach einer externen Weitergabe ist es sinnvoll, lokale Zugangscodes zu erneuern und aktive Sitzungen zu prüfen.

Kann man aus diesem Export die Auftragslage des Betreibers erkennen?

Wir veröffentlichen keine Projektbezeichnungen, Modellnamen oder zählbaren Auftragsdaten. Die genannten Datei- und Logzahlen beschreiben die technische Struktur des Systems und sind nicht mit der Anzahl von Kundenaufträgen gleichzusetzen.

Untersuchungsstand: 14.07.2026. Die Ergebnisse beziehen sich auf einen konkreten Diagnoseexport des beschriebenen Testsystems und können sich bei anderen Modellen, Firmwareständen, Exportoptionen oder Zeiträumen unterscheiden.