Tapo C520WS am Carport, Passwort gesetzt, Bewegungsmeldungen aktiv — und trotzdem braucht jemand im selben WLAN dein Passwort nicht. Er baut einen JSON-Request, der einen privilegierten Befehl an einen harmlosen anhängt, und ist ohne Authentifizierung drin.

Das ist CVE-2026-34121. Veröffentlicht am 2. April 2026, TP-Link Security Advisory FAQ-5047.

In der ersten Aprilwoche 2026 hat TP-Link sechs Schwachstellen in der Tapo C520WS v2.6 gemeldet. Alle mit CVSS v4.0 zwischen 7.1 und 8.7, also durchgehend "High". Drei Monate davor hatte Sicherheitsforscher Simone Margaritelli einen technischen Writeup zur Tapo C200 veröffentlicht, der zeigt: TP-Link patzt bei Kameras nicht gelegentlich, sondern systematisch.

Was CVE-2026-34121 konkret bedeutet

Die gefährlichste Lücke sitzt im DS Configuration Service. TP-Link beschreibt das Problem als "inconsistent parsing and authorization logic in JSON requests during authentication check". Der HTTP-Handler prüft, ob eine Aktion authentifizierungspflichtig ist, bevor er den vollständigen Request-Body parst. Ein Angreifer packt eine "sichere" Aktion zusammen mit einer privilegierten do-Aktion in einen Request. Der Checker sieht die sichere Aktion, nickt durch, der Prozess führt beide aus.

CVSS v4.0 Score: 8.7. Angriffsvektor AV:A — adjacent network, also gleiches Netzwerksegment. Für eine Kamera im Heimnetz, das womöglich Gäste, Nachbarsgeräte oder andere IoT-Geräte ohne saubere Segmentierung enthält, ist das keine theoretische Einschränkung.

Was man mit unbefugtem Konfigurationszugriff konkret anstellen kann, hängt von den exponierten Endpunkten ab. Aber unauthentifizierte Konfigurationsänderungen an einer Überwachungskamera sind für sich schon ein Problem.

Die weiteren fünf: Kamera abstürzen lassen, jederzeit

Neben dem Auth-Bypass dokumentiert das Advisory fünf Buffer-Overflow-Lücken, alle mit CVSS 7.1:

CVE-2026-34118, 34119, 34120 sind heap-based Overflows in drei verschiedenen Verarbeitungspfaden. 34118 sitzt im HTTP-POST-Body-Parser, dem die Kapazitätsprüfung nach dynamischer Allokation fehlt. 34119 tritt auf, wenn Request-Bodies segmentiert ankommen und ohne lückenlose Write-Boundary-Prüfung aneinandergehängt werden. 34120 steckt im asynchronen Parser für lokale Video-Streams. Alle drei erlauben es, die Kamera durch speziell präparierte Requests zum Absturz zu bringen. CVE-2026-34122 ist ein Stack-Overflow im selben DS Configuration Service. Ein zu langer Parameterwert reicht, um den Stack zu überschreiben und die Kamera in einen Reboot zu schicken. CVE-2026-34124 ist die subtilste der Gruppe: Der HTTP-Parser enforced eine Längenbeschränkung auf den rohen Request-Pfad, berechnet aber nicht, dass der normalisierte Pfad nach Path-Expansion länger sein kann als der Rohpfad. Schick einen kurzen, aber expandierenden Pfad, und du hast einen Buffer Overflow — ohne die Längengrenzen formal zu verletzen.

Alle fünf ermöglichen Denial-of-Service. Im Überwachungskontext ist das bitterer als es klingt: Eine abstürzende Kamera ist eine blinde Kamera. Jemand crasht die Außenkamera kurz bevor er ein Grundstück betritt — das ist kein Film-Szenario, das ist eine Abfolge von drei Requests.

Betroffene Version: Tapo C520WS v2.6 mit Firmware vor 1.2.4 Build 260326 Rel.24666n. Das Firmware-Update wurde am 26. März 2026 released, das Advisory erschien eine Woche später am 2. April.

Die C200: Dasselbe Spiel, ältere Hardware

Drei Monate vor dem C520WS-Advisory, im Dezember 2025, veröffentlichte Simone Margaritelli einen Writeup zur Tapo C200. Margaritelli besitzt selbst mehrere davon, entschied sich an einem Wochenende, die Firmware auseinanderzunehmen — und fand, was er eigentlich nicht mehr erwartet hatte. Die Bugs sind nicht exotisch. Sie sind vorhersehbar. Das macht es schlimmer.

Drei Lücken wurden im Dezember 2025 veröffentlicht und bekamen CVE-Nummern in der 2025-er Serie:

CVE-2025-8065: Der ONVIF SOAP XML Parser auf Port 2020 läuft ohne Bounds-Check auf die Anzahl der XML-Elemente. Schick 100.000 Elemente, bekommst du Heap Overflow und Kamera-Crash. Kein Login nötig. CVE-2025-14299: Der HTTPS-Server verarbeitet den Content-Length-Header mit atoi() — kein Bounds-Check, kein Integer-Overflow-Schutz. Schick 4294967295 als Content-Length, und auf dem 32-Bit-SoC gibt es einen Integer-Overflow, der den Prozess killt. CVE-2025-14300: Das connectAp-Endpunkt ist auch nach abgeschlossenem Setup ohne Authentifizierung erreichbar. Das ist der Endpunkt, über den die Kamera beim Einrichten ihr WLAN bekommt. Ein Angreifer im selben Netz kann die Kamera zwingen, sich mit einem anderen WLAN zu verbinden — was die Kamera aus dem Heimnetz reißt und potenziell in ein kontrolliertes Netz bringt.

Dazu kommt ein strukturelles Problem, das kein CVE bekommt, aber relevanter ist als alle Einzelbugs zusammen: Die Tapo C200 bettet in ihrer Firmware den privaten SSL-Key ein, der die HTTPS-API absichert. Dieser Key ist für alle Geräte identisch. Wer einmal den Firmware-Blob entschlüsselt hat — und TP-Link veröffentlicht die notwendigen RSA-Keys im Rahmen seiner GPL-Pflichten selbst — kann den Traffic jeder Tapo C200 im selben Netz entschlüsseln. Alle. Weltweit.

Wie kommt man an den Firmware-Blob? TP-Link hostet das gesamte Firmware-Repository in einem offenen S3-Bucket. Keine Authentifizierung. aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request listet jede Firmware, die TP-Link je für jedes Gerät released hat.

AI-assisted Reverse Engineering: Warum das jetzt jeder kann

Margaritellis Writeup ist auch aus einem anderen Grund lesenswert: Er hat den Großteil der Analyse mit KI-Unterstützung durchgeführt. Ghidra plus GhidraMCP, mit Claude als AI-Backend, um die dekompilierten MIPS-Binaries zu analysieren. Funktionsnamen aus dem Kontext ableiten, Handler mappen, Variablen umbenennen — was früher Wochen erfahrener Reverse Engineer brauchte, geht heute an einem Wochenende mit einem Tool-Stack, der Open Source ist.

Das ist kein Grund zur Panik. Es verschiebt aber, wie realistisch man die Bedrohungslage einschätzen muss. Sicherheitsforscher können heute schneller und mit weniger Vorwissen analysieren als vor fünf Jahren. Angreifer auch. Ob eine billige IoT-Kamera Schwachstellen hat, ist keine offene Frage mehr. Die offene Frage ist, wann jemand sie findet — und ob der Hersteller bis dahin einen Patch draußen hat.

Bei der C200 waren es 25.000 direkt im Internet exponierte Geräte, die Margaritelli via ZoomEye gefunden hat. Für die C520WS gibt es keine vergleichbare Zahl — sie ist eine Außenkamera ohne ONVIF-Direktexposition, sitzt typischerweise hinter einem Router, nicht direkt im Netz. Aber im lokalen Netz, wo Adjacent-Angreifer wirken können, ist das eine andere Rechnung.

TP-Link ist seit 2024 selbst eine CVE Numbering Authority (CNA). Das bedeutet: Wer eine Schwachstelle direkt an TP-Links Security-Team meldet, gibt damit TP-Link die Kontrolle darüber, ob und wann diese Schwachstelle eine CVE-ID bekommt.

Gleichzeitig nutzt TP-Link auf seiner "Security Commitment"-Seite CVE-Zahlen als Verkaufsargument. Grafiken zeigen, dass TP-Link weniger CVEs als Cisco, Netgear oder D-Link hat — als würde weniger öffentliche Dokumentation für bessere Sicherheit stehen.

Margaritelli formuliert das in seinem Writeup direkt: "There's an obvious and structural conflict of interest when a vendor is allowed to be their own CNA while simultaneously using their CVE count as a marketing metric." Ich kann dem wenig hinzufügen. Wer die CVE-Vergabe kontrolliert, kontrolliert auch, was im öffentlichen Register auftaucht. Das ist kein Beweis für aktive Unterdrückung — aber es ist ein Anreiz, der nicht sein sollte.

Beim C520WS-Advisory hat TP-Link die Disclosure-Timeline diesmal eingehalten: Firmware-Update am 26. März, Advisory am 2. April. Das ist besser als bei der C200, wo Margaritelli 150 Tage warten musste. Volle 90+30 Tage Responsible Disclosure ausgereizt, mehrfache Verschiebungen, keine Reaktion auf Follow-up-Mails — dann hat er veröffentlicht.

Was jetzt zu tun ist

C520WS v2.6: Tapo-App öffnen, Geräteeinstellungen, Firmware-Update. Die gepatchte Version ist 1.2.4 Build 260326 Rel.24666n. Alternativ manueller Download über die TP-Link Support-Seite (FAQ-5047 verlinkt direkt darauf).

C200: Die drei Lücken von Margaritelli wurden im Dezember 2025 gepatcht. Prüfen, was auf dem Gerät läuft.

Das Wichtigere ist das Netz-Setup, unabhängig vom Gerät: Eine Kamera gehört nicht in dasselbe Segment wie der Hauptrechner, das NAS oder der Home-Assistant-Server. Ein IoT-VLAN ist kein Overkill, es ist das Minimum. Wenn jemand CVE-2026-34121 auf deiner Kamera ausnutzt, soll das Worst-Case-Szenario eine kompromittierte Kamera sein, kein Sprungbrett ins Heimnetz.

Für Frigate-Nutzer: Wer Tapo-Kameras via RTSP in die Objekterkennung eingebunden hat und kein getrenntes Netz betreibt, hat dieselbe Risikooberfläche wie alle anderen. Das RTSP-Segment zu isolieren ist eine Stunde Arbeit im Router, die lohnt.

Das eigentliche Problem

Sechs CVEs in einer Kamera sind kein Ausrutscher, den ein Team mal hatte. Hardcoded SSL-Keys, atoi() ohne Bounds-Check, Auth-Logik die JSON nur halb liest — das ist, was passiert, wenn Outdoor-Kameras für 49 Euro gebaut werden und trotzdem Margen erwirtschaften sollen. Die Security-Abteilung kommt dann nach dem Preisblatt, nicht davor.

Ich kaufe keine Tapo-Kamera zurück. Aber ich würde auch keine neue kaufen, ohne das IoT-Segment vorher sauber vom Rest des Netzes getrennt zu haben. Nicht weil TP-Link besonders schlimm wäre — sondern weil in dieser Preisklasse alle Hersteller denselben Kompromissen unterliegen, und bei TP-Link wissen wir zumindest, wie die Lücken aussehen.

Wer eine Tapo C520WS oder C200 betreibt und das Firmware-Update noch nicht eingespielt hat: jetzt wäre der Moment. Und wer beim nächsten Kauf prüfen will, ob ein Hersteller ernsthaftes Security-Disclosure betreibt — schau auf die Advisory-Seite und schau, wie lang die Timelines dort sind. 150 Tage ist eine Antwort.