Wurden wirklich 5.000 Entwickler gehackt? Welche Auswirkungen hatte die Manipulation des Cursor-Plugins bislang tatsächlich?

Anmerkung des Autors: Dieser Artikel erklärt, was „bis zu 5000 Betroffene“ beim manipulierten Cursor-Plugin tatsächlich bedeutet. Er beleuchtet die Angriffskette, bestätigte Fälle, die Risiken für API-Schlüssel und die Schritte zur Selbstprüfung. So lässt sich unterscheiden, welche Aussagen belegt und welche übertrieben sind.

Am 29. Oktober 2026 tauchte im Cursor-Erweiterungsmarktplatz eine manipulierte Claude-Code-Erweiterung auf. In den folgenden Tagen machten Schlagzeilen wie „5000 Entwickler gehackt“ und „Claude-API-Schlüssel massenhaft geleakt“ die Runde. Tatsächlich gilt: 5000 ist die von Cursor offiziell genannte Obergrenze für potenziell betroffene Nutzer – nicht die Zahl bestätigter erfolgreicher Angriffe.

Das soll das Risiko keineswegs herunterspielen. Cursor hat den Vorfall offiziell bestätigt, ebenso wie das Microsoft-Sicherheitsforschungsteam, Phorion, Expel und weitere Organisationen. Auf Kundengeräten wurden bereits schädliche Aktivitäten beobachtet. Dieser Artikel betrachtet sechs Stufen – „Verteilung, Ausführung, Schreibzugriff, Ausnutzbarkeit, tatsächlicher Angriff und Datenverlust“ – und erklärt, welche Fakten jeweils bestätigt sind und welche Zahlen bislang nicht veröffentlicht wurden.

Das bringt Ihnen der Artikel: Sie können besser einschätzen, welche Folgen das manipulierte Cursor-Plugin für Sie und Ihr Team hat, und anhand der offiziellen Empfehlungen Ihre Systeme prüfen und Zugangsdaten austauschen.

Cursor-Erweiterung kompromittiert: Das Wichtigste auf einen Blick

Zunächst die bestätigten Fakten. Entscheidend ist die Abgrenzung: Es handelt sich um einen Software-Lieferkettenangriff auf ein Entwickler-Tool. Weder wurde das Claude-Modell geknackt noch wurden interne Systeme von Anthropic kompromittiert.

Laut Anthropic wurden die schädlichen Builds weder vom Unternehmen entwickelt noch veröffentlicht. Auch interne Systeme und Computer von Mitarbeitenden seien nicht betroffen. Wie die Angreifer die Berechtigung erhielten, Builds im Cursor Marketplace zu veröffentlichen, war bis zum 2. November nicht öffentlich geklärt.

Zeitlicher Ablauf des Angriffs auf die Cursor-Erweiterung

Bei diesem Vorfall lassen sich zwei Zeiträume leicht verwechseln: das Zeitfenster, in dem die schädlichen Pakete im Marketplace heruntergeladen werden konnten, und der Zeitpunkt, zu dem der Schadcode auf Geräten mit installierter Erweiterung tatsächlich ausgeführt wurde. Letzteres kann deutlich später geschehen. Dass die Erweiterung entfernt wurde, bedeutet also nicht, dass bereits betroffene Geräte sicher sind.

Anfangs gab es auch Berichte, wonach Open VSX angegriffen worden sei. OpenSourceMalware korrigierte diese Aussage später. Auch Socket fand bei der Prüfung der Open-VSX-Registry keine entsprechenden schädlichen Versionen. Derzeit ist nur der Cursor Marketplace als angegriffener Vertriebskanal bestätigt.

So funktioniert die Manipulation des Cursor-Plugins: vom 66-Zeilen-Loader zum Reverse-SSH-Tunnel

Laut Analysen von Phorion und OpenSourceMalware fügten die Angreifer am Anfang der extension.js einer regulären Erweiterung einen etwa 66 Zeilen langen bösartigen JavaScript-Loader ein – noch vor dem eigentlichen Anwendungscode. Er wird ausgelöst, sobald das Erweiterungsmodul geladen wird. Nutzer müssen weder eine Nachricht an Claude senden noch einen Programmierauftrag autorisieren. Oberfläche und Funktionen von Claude Code bleiben wie gewohnt nutzbar, manche Fehler werden zudem stillschweigend abgefangen. Dadurch ist der Angriff schwer zu bemerken.

Die Angriffskette lässt sich in sechs Schritten zusammenfassen:

1. Hostinformationen sammeln: Dazu gehören Hostname, Benutzername, Betriebssystem und CPU-Architektur, Home- und Arbeitsverzeichnis, die globale Git-E-Mail-Adresse und die öffentliche IP-Adresse.
2. Autorisierten SSH-Schlüssel einschleusen: Ein von den Angreifern kontrollierter öffentlicher Schlüssel wird mit der Kennzeichnung svc-telemetry in die authorized_keys des Nutzers geschrieben.
3. SSH-Dienst zu aktivieren versuchen: Ist die SSH-Anmeldung auf dem Gerät verfügbar, können sich die Angreifer möglicherweise mit dem eingeschleusten Schlüssel anmelden.
4. Reverse-SSH-Tunnel aufbauen: Das betroffene Gerät verbindet sich selbst mit dem Server der Angreifer über TCP-Port 22. Darüber wird eine Verbindung zum lokalen SSH-Dienst weitergeleitet, um bestimmte Einschränkungen für eingehende Verbindungen zu umgehen.
5. Persistenz einrichten: Unter macOS und Windows wird nach der Anmeldung eine automatische Wiederverbindung eingerichtet, unter Linux über crontab @reboot. So kann die Hintertür auch unabhängig von der Erweiterung weiterlaufen. Schlägt die Verbindung fehl, wird etwa alle 60 Sekunden ein neuer Versuch gestartet.
6. Ausführungsstatus melden: Ein HTTP-Beacon über TCP-Port 8099 übermittelt Hostinformationen und die Ergebnisse der einzelnen Schritte an den Server.

Warum die Manipulation des Cursor-Plugins keine Prompt-Injection ist

Viele denken bei „einem Vorfall mit Claude Code“ zuerst, dass ein Modell durch einen bösartigen Prompt manipuliert wurde. Diesmal war das nicht der Fall. Es handelt sich um einen typischen Angriff durch die Ausführung von Erweiterungscode. Die Schadlogik hat mit der Modellausgabe nichts zu tun – bei jedem anderen manipulierten IDE-Plugin wäre das Prinzip dasselbe. Über die Sicherheit des Claude-Modells selbst zu diskutieren, hilft bei diesem Vorfall also nicht weiter. Das eigentliche Problem: Wenn sich Angreifer als Anbieter eines Plugin-Vertriebskanals für Entwicklungstools ausgeben können, bricht die Vertrauenskette.

Zwei Implementierungsfehler im Schadcode

Programmierfehler haben die Gefährlichkeit dieses Angriffs reduziert. Unter macOS fragte der Schadcode den Status der entfernten Anmeldung ohne Administratorrechte ab. Das System gab deshalb einen Berechtigungsfehler zurück, nicht „deaktiviert“. Das Programm versuchte SSH aber nur dann zu aktivieren, wenn es den Status ausdrücklich als „deaktiviert“ erkannt hatte. Auf vielen Macs, auf denen SSH noch nicht aktiviert war, schlug dieser Schritt deshalb fehl. Unter Windows rief der Schadcode bei der Installation von OpenSSH Server fälschlicherweise den Unix-Pfad /bin/sh auf, den es in einer Standard-Windows-Umgebung nicht gibt.

Fehler bedeuten allerdings nicht, dass der Angriff wirkungslos war. Der Schadcode konnte weiterhin einen öffentlichen Schlüssel hinterlegen, Persistenzskripte erstellen, Netzwerkverbindungen aufbauen und Host-Informationen melden. Für Geräte, auf denen SSH bereits aktiviert war, bestand ein deutlich höheres Risiko. Calum Hall, Mitgründer von Phorion, sagte gegenüber WIRED ebenfalls, dass dies bei korrekter Implementierung ein sehr gefährlicher Angriffsweg hätte sein können.

Wurden 5.000 Entwickler gehackt? Die sechs Ebenen des Cursor-Plugin-Angriffs

Die Zahl „5.000“ stammt aus der ersten Cursor-Mitteilung vom 29. Oktober: „At most 5,000 users were affected“ – betroffen waren demnach höchstens 5.000 Nutzer. Das ist eine vom Unternehmen selbst genannte Obergrenze, keine von einer Sicherheitsorganisation unabhängig bestätigte Zahl erfolgreicher Kompromittierungen. Die erste Mitteilung erwähnte nur 2.1.313; nach einer Aktualisierung kam 2.1.312 hinzu. Cursor legte aber weder offen, wie viele Nutzer auf die einzelnen Versionen entfielen, noch veröffentlichte das Unternehmen eine vollständige aktualisierte Aufschlüsselung.

Teilt man die Auswirkungen in sechs Ebenen ein, wird klarer, was bestätigt ist und was nur vermutet wird:

Der Unterschied zwischen den beiden Seiten der Grafik zeigt die Lücke zwischen Schlagzeilen und Belegen. Je weiter unten im Trichter, desto weniger öffentliche Belege gibt es. Weder für „5.000 Computer wurden vollständig unter Kontrolle gebracht“ noch für „Die API-Schlüssel von 5.000 Personen wurden gestohlen“ gibt es derzeit Belege.

Was zeigen die vier Fälle von Expel?

Expel bearbeitete am 29. und 30. Oktober vier zusammenhängende Sicherheitsvorfälle bei vier Kunden. In jedem Fall war jeweils ein Mac betroffen. Auf drei Geräten lief CrowdStrike Falcon, auf einem Microsoft Defender for Endpoint. Bei allen vier Vorfällen wurden Netzwerkverbindungen zu einer Server-IP des Angreifers festgestellt. Die Vorfälle beschränkten sich damit nicht mehr auf die Analyse des Codes im Labor.

Besonders auffällig war ein Fall mit verzögerter Ausführung. Der Nutzer meldete sich am 30. Oktober um 12:44 Uhr Pekinger Zeit an seinem Mac an und startete Cursor. Eine Minute später begann die schädliche Aktivität. Bis 22:29 Uhr gab es weiterhin Verbindungen zur IP-Adresse des Angreifers – über einen Zeitraum von fast zehn Stunden. Zu diesem Zeitpunkt war das schädliche Paket längst aus dem Marktplatz entfernt worden. Eine plausible Erklärung: Das Installationspaket war während des Zeitraums, in dem es verfügbar war, bereits heruntergeladen und erst beim erneuten Start von Cursor ausgelöst worden.

Die Aussagekraft dieser Daten hat klare Grenzen: Die vier Vorfälle bedeuten nicht, dass weltweit nur vier Geräte betroffen waren. Auch lässt sich keine Infektionsrate berechnen, indem man vier durch 5.000 teilt. Ein erkannter SSH-Tunnel bedeutet zudem nicht, dass sich der Angreifer bereits erfolgreich angemeldet hat. Phorion fand ebenfalls ein Sample auf einem Kunden-Mac. Ob sich dieser Fund mit einem der Fälle von Expel überschneidet, ist jedoch unklar – die Zahlen lassen sich daher nicht einfach addieren. Expel entdeckte ausserdem auf einem Gerät einen schädlichen Tunnelprozess, aber keine svc-telemetry-Markierung für den öffentlichen Schlüssel. Wer nur nach einer einzigen Markierung sucht, übersieht also leicht einen Befall.

Grenzen des API-Schlüssel-Risikos beim kompromittierten Cursor-Plug-in

Der Schadcode filtert bis zu 40 Umgebungsvariablen heraus, deren Namen KEY, TOKEN, SECRET, PASS, AWS oder GCP enthalten. Ist auf dem Rechner beispielsweise OPENAI_API_KEY gesetzt, kann der Angreifer erkennen, dass dort der entsprechende Dienst genutzt wird. Die Forschenden bestätigten jedoch, dass zunächst nur die Namen der Variablen übermittelt wurden, nicht ihre Werte.

Die genaue Aussage lautet also: Der Angriffscode kann erkennen, welche Arten sensibler Konfigurationen vorhanden sind. Wurde die Hintertür tatsächlich ausgenutzt, könnte der Angreifer darüber hinaus lokale Zugangsdaten und Quellcode auslesen. Wie viele API-Schlüssel tatsächlich gestohlen wurden, ist bisher nicht öffentlich bekannt. Die Behauptung, „alle API-Schlüssel der Nutzer wurden gestohlen“, setzt die Möglichkeit mit dem tatsächlichen Ergebnis gleich. Gerade weil das genaue Ausmass des Risikos unklar ist, sollten Zugangsdaten vorsorglich rotiert werden.

Auswirkungen des kompromittierten Cursor-Plug-ins

Auswirkungen auf Entwickler

• Deinstallation reicht nicht aus: Laut offizieller Warnung werden bereits hinterlegte öffentliche SSH-Schlüssel, Autostart-Einträge und Hintergrundskripte durch eine Deinstallation oder ein Upgrade auf 2.1.314 nicht unbedingt entfernt.
• Aktivierung auch nach der Entfernung möglich: Der Fall einer verzögerten Aktivierung, den Expel dokumentiert hat, zeigt, dass auch Nutzer ihre Systeme überprüfen sollten, die Cursor erst nach der Entfernung des Plug-ins geöffnet haben.
• Höheres Risiko bei dauerhaft aktiviertem SSH: Auf Entwicklungsrechnern ist Remote Login für das Remote-Debugging häufig dauerhaft aktiviert. Damit umgingen diese Rechner genau den Implementierungsfehler des Schadcodes.
• Überblick über mögliche Zugangsdaten: Selbst wenn die Hintertür nicht erfolgreich ausgenutzt wurde, könnte der Angreifer bereits wissen, welche Cloud-Dienste und APIs Sie nutzen.

Auswirkungen auf Teams und die Branche

• Plug-in-Verteilung als neue Angriffsfläche: Versionen derselben Erweiterung können auf verschiedenen Marktplätzen aus unterschiedlichen Quellen stammen. Bei der Prüfung sollten daher Installationsquelle und Dateihash berücksichtigt werden, nicht nur die Versionsnummer.
• Endpunktberechtigungen von KI-Programmiertools neu bewerten: IDE-Plug-ins laufen normalerweise mit den Rechten des Nutzers. Sie können das Home-Verzeichnis lesen und beschreiben sowie Netzwerkverbindungen aufbauen. Unternehmen sollten sie deshalb in ihre Endpunktkontrolle einbeziehen.
• Incident Response muss den gesamten Lebenszyklus von Zugangsdaten abdecken: Repositories, API-Schlüssel, Cloud-Zugangsdaten und Sitzungstoken, auf die betroffene Geräte zugreifen können, sollten überprüft werden. Je stärker die in Projekten genutzten Schlüssel verteilt sind, desto aufwendiger ist ihre Rotation.

Cursor-Plugin-Manipulation: Selbstprüfung und Anleitung zur Rotation von Zugangsdaten

Verwenden Sie zunächst die Prüf- und Bereinigungsskripte für macOS und Windows aus der offiziellen Mitteilung von Cursor. Die folgenden Indikatoren und Befehle helfen beim Verständnis und bei der Fehlersuche, ersetzen aber weder die offiziellen Skripte noch eine Untersuchung der Logs.

Schritt 1: Schnelle Prüfung auf dem eigenen Gerät (Beispiel macOS)

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

Unter Windows können Sie mit schtasks /query /tn SysMon nach der geplanten Aufgabe suchen und anschließend im Autostart-Ordner nach sysmon.cmd schauen. Bei jedem Treffer sollten Sie Beweise sichern, das Gerät isolieren und es anschließend mithilfe des offiziellen Skripts bereinigen. Lässt sich ein vertrauenswürdiger Zustand des Geräts nicht wiederherstellen, sollten Sie eine Neuinstallation des Systems in Betracht ziehen und Ihre Zugangsdaten auf einem anderen vertrauenswürdigen Gerät rotieren.

Schritt 2: Namen möglicherweise offengelegter Zugangsdaten erfassen

Das folgende Skript filtert Umgebungsvariablen anhand derselben Schlüsselwörter wie der Schadcode. Es gibt nur die Namen aus, nicht die Werte. So kannst du eine Liste der Zugangsdaten erstellen, die du rotieren solltest. Prüfe anschließend mit einem einfachen API-Aufruf, ob der neue API-Schlüssel funktioniert:

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

Schritt 3: Zugangsdaten nach Priorität rotieren

🎯 Technischer Tipp: Wenn ein Projekt direkt mit mehreren Plattformen wie OpenAI, Claude und Gemini verbunden ist, müssen Sie sich nach einem Vorfall bei jeder Plattform anmelden, um die Schlüssel zu widerrufen und neu zu erstellen. Offiziell wird empfohlen, Modellaufrufe über APIYI apiyi.com zu bündeln: Ein Schlüssel deckt mehrere führende Modelle ab, und die Schnittstelle ist mit OpenAI kompatibel. Bei einer Rotation muss dann nur eine Konfiguration geändert werden. Außerdem lassen sich Nutzung und auffällige Kosten zentral überwachen.

Häufige Fragen (FAQ)

Die wichtigsten Punkte zur Manipulation des Cursor-Plugins

• Art des Vorfalls: Über den Cursor-Marktplatz wurde eine manipulierte Erweiterung verteilt. Es handelt sich um einen Supply-Chain-Angriff, nicht um eine Schwachstelle im Claude-Modell.
• Was die Zahl 5000 bedeutet: Sie bezeichnet die offiziell genannte Obergrenze potenziell Betroffener, nicht die Zahl bestätigter Einbrüche.
• Bestätigt: Eine unabhängige Organisation hat auf einem echten Mac bösartige Aktivitäten und ausgehende Verbindungen beobachtet.
• Nicht bekannt gegeben: die Zahl erfolgreicher Remote-Anmeldungen, die Zahl gestohlener API-Schlüssel und die Höhe des finanziellen Schadens.
• Wichtiges Risiko: Der Schadcode kann auch nach der Entfernung aus dem Marktplatz noch ausgelöst werden. Die Deinstallation des Plugins entfernt die Hintertür nicht unbedingt.
• Massnahmen: Das offizielle Skript ausführen, Zugangsdaten auf einem vertrauenswürdigen Gerät austauschen und mithilfe von APIYI apiyi.com die Zahl der API-Schlüssel reduzieren.

Zusammenfassung

Die wichtigsten Erkenntnisse zum Vorfall:

1. Schlagzeilen und Belege unterscheiden: Zwischen „bis zu 5000 Betroffene“ und „5000 gehackte Personen“ liegen mehrere Stufen. Die öffentlich verfügbaren Belege bestätigen derzeit, dass der Schadcode tatsächlich ausgeführt wurde.
2. Der Angriff war real, aber nur eingeschränkt wirksam: Der Schadcode verfügte über eine Hintertür und Mechanismen zur dauerhaften Verankerung. Implementierungsfehler unter macOS und Windows verringerten jedoch die Erfolgschancen einer Remote-Anmeldung.
3. Eine einzelne Prüfung reicht nicht aus: Installationsquelle, Dateihashes, Prozesse, Netzwerkverbindungen und Autostart-Einträge sollten gemeinsam geprüft werden. Wer nur nach svc-telemetry sucht, übersieht möglicherweise Hinweise.

Wenn Sie zwischen dem 29. und 30. Oktober die Claude-Code-Erweiterung über den Cursor-Marktplatz verwendet haben, prüfen Sie Ihr System zunächst anhand der offiziellen Anleitung und tauschen Sie anschließend Ihre Zugangsdaten nach Priorität aus. Für Modell-APIs können Sie die Gelegenheit nutzen, verstreute API-Schlüssel bei APIYI apiyi.com zusammenzuführen. Das vereinfacht einen Austausch im nächsten Notfall.

📚 Quellen

1. Offizielle Sicherheitsmitteilung von Cursor: Zeitpunkt des Vorfalls, Versionen, Hashwerte schädlicher Dateien und Bereinigungsskripte
2. Link: cursor.com/blog/claude-code-extension-security-notice

3. Hinweis: Diese Mitteilung ist der erste Anlaufpunkt für die eigene Prüfung. Sie enthält auch Bereinigungsskripte für macOS und Windows.

4. Microsoft Security Research: Analyse der Angriffskette der schädlichen Claude-Code-Erweiterung

5. Link: microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. Hinweis: Details zur Abgrenzung der Lieferkette, zu SSH-Mechanismen und zur Persistenz

7. Phorion: Official Claude Code Extension Compromise

8. Link: phorion.io/blog/offical-claude-code-vsx-compromise/

9. Hinweis: Technische Details zum 66-zeiligen Loader, zu Plattformunterschieden und Codefehlern

10. Expel: Fake Claude Code extensions in Cursor

11. Link: expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. Hinweis: Vier tatsächliche Vorfälle bei Kunden und Beispiele für verzögerte Ausführung

13. Socket: Cursor Removes Malicious Claude Code Extension

14. Link: socket.dev/blog/claude-code-extension-compromise
15. Hinweis: Überprüfung der Einträge in Open VSX und npm sowie Korrektur früher Fehlmeldungen

Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns gerne über die Startseite von APIYI unter apiyi.com. Weitere Informationen zur Integration finden Sie im Dokumentationszentrum unter docs.apiyi.com.

Weiterführende Artikel

• Claude-Code-Erweiterung kompromittiert: Hintertür in Version 2.1.313 – Selbstprüfung und Entfernung in 5 Schritten: Am 29. Oktober ersetzten SSH-Backdoor-Builds Claude Code 2.1.312/313 im Cursor Marketplace; bis zu 5.000 Nutzer waren betroffen: Fünf Schritte prüfen den öffentlichen svc-telemetry-Schlüssel, entfernen LaunchAgent und geplante Aufgaben, aktualisieren auf 2.1.314+ und rotieren GitHub-, Cloud- und APIYI-Schlüssel.
• Claude Max heißt jetzt Ultra: Ist das 5-Stunden-Limit aufgehoben? 3 Änderungen im Überblick: Claude Max 20x heißt nun Ultra und Max 5x heißt Max, die Preise bleiben gleich; für verifizierte Ultra-Konten entfällt das 5-Stunden-Limit, das Wochenlimit bleibt bestehen; eine Vergleichstabelle, drei Prüfschritte und eine Kostenrechnung helfen bei der Entscheidung über einen Tarifwechsel.