Plugin-Name	Tutor LMS
Art der Schwachstelle	SQL-Injection
CVE-Nummer	CVE-2025-13673
Dringlichkeit	Kritisch
CVE-Veröffentlichungsdatum	2026-03-02
Quell-URL	CVE-2025-13673

Dringend: Unauthentifizierte SQL-Injection in Tutor LMS (<= 3.9.6) — Was WordPress-Seitenbesitzer jetzt tun müssen

Eine hochgradige unauthentifizierte SQL-Injection (CVE-2025-13673), die Tutor LMS <= 3.9.6 betrifft. Erfahren Sie, was die Schwachstelle bedeutet, wie Angreifer sie ausnutzen können, und praktische, sofortige Schritte — einschließlich wie WP‑Firewall Ihre Seite schützt — um das Risiko zu reduzieren, bis Sie den offiziellen Patch anwenden können.

Autor: WP‐Firewall-Sicherheitsteam
Datum: 2026-03-02
Stichworte: WordPress, Sicherheit, Tutor LMS, SQL-Injection, WAF, Schwachstelle

Zusammenfassung: Eine hochgradige, unauthentifizierte SQL-Injection, die Tutor LMS-Versionen 3.9.6 und früher betrifft (CVE‑2025‑13673), wurde am 2. März 2026 öffentlich bekannt gegeben und in Tutor LMS 3.9.7 gepatcht. Da der Fehler ohne Authentifizierung ausgenutzt werden kann und die Konstruktion von Datenbankabfragen im Zusammenhang mit der Verarbeitung von Gutscheinen betrifft, sollte jede WordPress-Seite, die eine verwundbare Version ausführt, sofort handeln. Dieser Beitrag erklärt die Schwachstelle, wahrscheinliche Auswirkungen, sichere Milderungsstrategien, die Sie jetzt umsetzen können (einschließlich der Verwendung von WP‑Firewall), Schritte zur Erkennung und Reaktion auf Vorfälle sowie langfristige Härtungsratschläge.

Warum das wichtig ist — kurze technische Zusammenfassung

Die offengelegte Schwachstelle ist eine SQL-Injection (SQLi) in der Art und Weise, wie bestimmter Tutor LMS-Code mit gutscheinspezifischen Eingaben umgeht. Kritisch:

• Sie ist unauthentifiziert — ein Angreifer benötigt kein Konto auf der Seite.
• Sie zielt auf die Logik der Gutscheinverarbeitung ab, die möglicherweise einen coupon_code (oder ähnlichen) Parameter akzeptiert und ihn dann in Datenbankabfragen ohne ausreichende Bereinigung/Parametrisierung verwendet.
• Die Schwachstelle hat einen hohen CVSS-Score (9.3) und wird als CVE‑2025‑13673 verfolgt.
• Der Plugin-Autor hat sie in Tutor LMS 3.9.7 gepatcht. Jede Seite, die Version 3.9.6 oder älter ausführt, gilt als verwundbar.

Da ein Angreifer den verwundbaren Code als unauthentifizierter Benutzer erreichen kann, ist die Gefahr nicht theoretisch. Das Ausnutzen von SQL-Injection in diesem Kontext kann das Lesen oder Ändern von Datenbankinhalten ermöglichen, was zu Datendiebstahl, Offenlegung von Anmeldeinformationen, Privilegieneskalation oder vollständiger Übernahme der Seite führen kann.

Realistische Angriffsszenarien

Angreifer werden wahrscheinlich einen oder mehrere der folgenden Ansätze verwenden:

• Senden von gestalteten HTTP-Anfragen an den Gutschein-Endpunkt, um Datenbankabfragen auszulösen, die Daten (Benutzeraufzeichnungen, gehashte Passwörter, Plugin-Optionen) preisgeben.
• SQLi mit anderen Schwachstellen oder schwachen Anmeldeinformationen verketten, um administrativen Zugriff zu schaffen oder PHP-Code auszuführen (wenn DB-Inhalte später unsicher verwendet werden).
• Massen-Scanning und automatisierte Ausnutzungsversuche über WordPress-Seiten durchführen, um verwundbare Tutor LMS-Instanzen zu finden.
• Die Schwachstelle nutzen, um Bestellungen, Gutscheine oder Kurszugriffe zu manipulieren, um Betrug zu verursachen oder Geschäftsabläufe zu stören.

Diese Szenarien sind realistisch, da codebezogene Gutscheine häufig über öffentlich verfügbare UI oder AJAX-Endpunkte erreichbar sind. Sobald automatisierte Scanner das Muster erkennen, kann die Ausnutzung weit verbreitet und schnell sein.

Wer ist gefährdet?

• Jede WordPress-Website, die Tutor LMS Version 3.9.6 oder früher ausführt.
• Websites, auf denen das Plugin installiert ist, aber nicht unbedingt aktiv genutzt wird (der anfällige Endpunkt könnte weiterhin vorhanden sein).
• Multisite- und Einzelstandortinstallationen gleichermaßen.
• Websites ohne zeitnahe Backups, Protokollierung und EDR/WAF-Schutz sind einem höheren Risiko irreversibler Schäden ausgesetzt.

Wenn Sie eine Website mit installiertem Tutor LMS hosten, behandeln Sie dies als einen dringenden Sicherheitsvorfall.

Sofortige Schritte, die Sie unternehmen sollten (Aktionscheckliste)

Unten finden Sie eine priorisierte Liste, die Sie jetzt befolgen können. Das Ziel ist es, die Exposition schnell zu reduzieren, während Sie den offiziellen Patch validieren und anwenden.

1. Inventar
   • Identifizieren Sie alle WordPress-Websites, die Sie verwalten, und bestätigen Sie die Tutor LMS-Version(en). Wenn Sie Remote-Management verwenden, überprüfen Sie die Plugin-Inventare über alle Websites hinweg.
2. Patchen (beste langfristige Lösung)
   • Planen Sie, Tutor LMS so schnell wie möglich auf 3.9.7 oder höher zu aktualisieren. Testen Sie das Update zuerst in der Staging-Umgebung, wenn Sie Anpassungen vorgenommen haben.
3. Wenn Sie nicht sofort patchen können, wenden Sie vorübergehende Milderungen an (siehe unten).
4. Überwachung und Protokollierung aktivieren
   • Erhöhen Sie die Protokollierungsdetails für Webserver, PHP und WordPress. Achten Sie auf Anfragen an Gutschein-Endpunkte und ungewöhnliche Abfragefehler.
5. Sichern.
   • Machen Sie ein vollständiges Backup der Website und der Datenbank, bevor Sie Maßnahmen zur Behebung ergreifen.
6. Auf Kompromisse prüfen
   • Führen Sie einen Malware- und Integritäts-Scan durch, um nach Anzeichen einer Kompromittierung zu suchen (neue Administratorbenutzer, verdächtige Dateien, modifizierte Kern-/Plugin-Dateien).
7. Ziehen Sie die Incident-Response hinzu, wenn Sie verdächtige Aktivitäten feststellen.

Vorübergehende Milderungen, während Sie aktualisieren

Wenn Sie das Plugin nicht sofort aktualisieren können (z. B. aufgrund von Kompatibilitätstests, Anpassungen oder geplanten Wartungsfenstern), wenden Sie eine oder mehrere dieser Milderungen an, um die Wahrscheinlichkeit einer Ausnutzung zu verringern.

• Verwenden Sie eine Web Application Firewall (WAF), um bösartige Payloads zu blockieren und einen virtuellen Patch zu implementieren.
  • Eine ordnungsgemäß konfigurierte WAF kann Ausnutzungsversuche blockieren, die auf den Couponparameter oder das Endpunktmuster abzielen.
  • Setzen Sie sofortige Regeln ein, um verdächtige Eingabemuster im Couponparameter zu blockieren (z. B. SQL-Metazeichen, die in Injektionsversuchen verwendet werden).
• Beschränken Sie den Zugriff auf den Couponverarbeitungsendpunkt:
  • Wenn Ihr Webdesign dies zulässt, beschränken Sie den Zugriff auf Endpunkte, die Coupons verarbeiten, nur auf authentifizierte Benutzer. Wenn ein öffentlicher Couponendpunkt ausschließlich für Admin- oder Checkout-Workflows existiert, ziehen Sie kurzfristige Zugriffsrestriktionen in Betracht.
• Deaktivieren Sie die Couponfunktionalität:
  • Wenn Coupons nicht kritisch sind, deaktivieren Sie vorübergehend die Akzeptanz von Couponcodes, bis ein Patch angewendet wird.
• Ratenbegrenzung und Drosselung:
  • Fügen Sie Ratenlimits für den Couponendpunkt und für nicht authentifizierte Anfragen insgesamt hinzu, um die Möglichkeit automatisierter Angriffe zu verringern.
• Blockieren Sie verdächtige Benutzeragenten und IPs:
  • Obwohl unvollkommen, kann dies lautes Scannen reduzieren. Verwenden Sie Bedrohungsintelligenz-Feeds und die integrierten Schutzmaßnahmen Ihrer WAF.

Notiz: Temporäre Milderungen können das normale Verhalten der Website beeinträchtigen. Testen Sie Änderungen immer in der Staging-Umgebung und überwachen Sie die Fehlerprotokolle sorgfältig.

Was WP‑Firewall empfiehlt — ein praktischer Verteidigungsplan

Als Sicherheitsteam von WP‑Firewall konzentrieren sich unsere sofortigen Empfehlungen auf die schnelle Reduzierung der Exposition, Überwachung und Wiederherstellung. Im Folgenden finden Sie einen Schritt-für-Schritt-Plan, den Sie mit WP‑Firewall und den Standardbetriebspraktiken von WordPress umsetzen können.

1. Melden Sie sich an / aktivieren Sie den WP‑Firewall-Schutz auf der anfälligen Website
   • Unsere kostenlose Basisstufe umfasst eine verwaltete Firewall, WAF, Malware-Scanning und OWASP Top 10-Minderungen. Dies ist eine ausgezeichnete Grundlage für schnellen Schutz.
2. Aktivieren Sie die WAF-Regeln für virtuelle Patches
   • Wenn Sie Zugriff auf automatische virtuelle Patches (Pro-Stufe) haben, aktivieren Sie diese für sofortigen Schutz gegen dieses spezifische SQLi-Muster. Wenn Sie im kostenlosen Plan sind, aktivieren Sie das verwaltete Regelset und die OWASP-Minderungen, um gängige Injektionsvektoren zu blockieren.
3. Erstellen Sie eine sofortige WAF-Regel zur Minderung des Missbrauchs des Couponendpunkts
   • Konfigurieren Sie eine Regel, die Anfragen nach dem Couponparameter überprüft und Anfragen blockiert, die verdächtige SQL-Token oder Muster enthalten. Konzentrieren Sie sich darauf, nicht authentifizierte Anfragen zu blockieren, bei denen der Parameter vorhanden ist.
   • Fügen Sie eine Regel mit höherer Priorität hinzu, um Anfragen an bekannte anfällige Endpunkte zu blockieren, wenn sie vorhersehbar sind (z. B. Plugin-AJAX- oder REST-Routen, die von Tutor LMS verwendet werden).
4. Aktivieren Sie das ausführliche Anforderungsprotokoll.
   • Erfassen Sie blockierte Anfragen und den vollständigen Anforderungskontext (Header, IP, Zeitstempel, Anforderungstext anonymisiert aus Datenschutzgründen) zur Vorfallbearbeitung.
5. Planen Sie ein Site-Backup und einen Datenbankexport.
   • Führen Sie ein zeitpunktbezogenes Backup vor Updates oder Änderungen durch und bewahren Sie Kopien außerhalb des Standorts zur Wiederherstellung auf.
6. Aktualisieren Sie Tutor LMS zuerst in der Staging-Umgebung, dann in der Produktion.
   • Wenden Sie den Anbieter-Patch (3.9.7 oder später) in einer Staging-Umgebung an, führen Sie Funktionstests durch und setzen Sie ihn dann während eines Wartungsfensters in der Produktion ein.
7. Nach-Patch-Überprüfung.
   • Lassen Sie nach dem Patchen die WAF-Regeln mindestens 7–14 Tage bestehen, um etwaige Versuche zur Ausnutzung nach dem Patch zu erfassen und um sicherzustellen, dass es keine Regression oder unerwarteten Datenverkehr gibt.

Wenn Sie eine unterstützungsfreie Lösung bevorzugen, beinhalten die höheren Stufen von WP-Firewall automatisiertes virtuelles Patchen und verwaltete Unterstützung, um diese Regeln für Sie umzusetzen.

So blockiert WP-Firewall Ausnutzungen (technische Übersicht).

So reduziert eine richtig konfigurierte WAF das Risiko dieser Art von SQL-Injection:

• Parameterinspektion: Die WAF überprüft spezifische Parameter (z.B. coupon_code) und lehnt Eingaben ab, die SQL-Metazeichen oder verdächtige Konstrukte (union, select, Kommentar-Tokens) enthalten, wenn diese in unerwarteten Kontexten erscheinen.
• Endpoint-Whitelistierung: Die WAF stellt sicher, dass bekannte Endpunkte nur erwartete HTTP-Methoden und Inhaltstypen akzeptieren. Unerwartete Methoden oder Inhaltstypen werden blockiert.
• Verhaltensanalytik und Heuristiken: Die WAF überwacht Anforderungsraten, IP-Ruf und Verhaltensanomalien (z.B. Ausbrüche unterschiedlicher Coupon-Strings von einer einzigen IP), um automatisierte Scanner zu blockieren.
• Virtuelles Patching: Anstatt auf ein Plugin-Update zu warten, erstellt das virtuelle Patchen Regeln, die die Signatur der Schwachstelle am Rand neutralisieren.
• Antworthärtung: Die WAF kann Fehlermeldungen oder Stack-Traces verbergen, die möglicherweise Datenbank- oder Systeminformationen an Angreifer weitergeben, und so Aufklärung verhindern.

Diese Schutzmaßnahmen bieten zeitkritische Abdeckung und reduzieren dramatisch die Wahrscheinlichkeit einer erfolgreichen Ausnutzung, während Sie den Anbieter-Patch anwenden.

Erkennung — wonach in Protokollen zu suchen ist

Durchsuchen Sie Protokolle nach Folgendem (Beispiele sind konzeptionell; versuchen Sie nicht, die Schwachstelle auszunutzen):

• HTTP-Anfragen, die den Endpunkt zur Validierung/Verarbeitung von Gutscheinen oder AJAX-Routen, die mit dem Tutor LMS-Plugin verbunden sind, aufrufen. Achten Sie auf ungewöhnliche Abfragezeichenfolgenaktivitäten oder POST-Körper, die Gutschein-bezogene Felder von nicht authentifizierten IPs enthalten.
• Wiederholte Anfragen, die sich nur durch den Gutscheinwert unterscheiden – dies ist ein häufiges Muster, wenn Angreifer automatisierte SQLi-Payloads versuchen.
• Datenbankfehler in PHP oder WordPress-Fehlerprotokollen, die auf SQL-Syntaxprobleme, seltsame Feldnamen oder Ausnahmen während der Gutscheinverarbeitung verweisen.
• Unerwartete Abfragen oder große Ergebnismengen, die von Datenbankabfragen zurückgegeben werden, die von der Webanwendung ausgelöst wurden.
• Neue Administratorbenutzer, Änderungen an Benutzerrollen oder ungewöhnliche Modifikationen an Plugin-/Theme-Dateien kurz nach verdächtigen Anfragen.

Wenn Sie verdächtige Aktivitäten identifizieren, isolieren Sie die betroffene Website (oder reduzieren Sie zumindest die öffentliche Exposition), bewahren Sie Protokolle und Backups auf und folgen Sie den untenstehenden Schritten zur Reaktion auf Vorfälle.

Vorfallreaktion (wenn Sie eine Ausnutzung vermuten)

1. Beweise sichern
   • Machen Sie sofort einen Snapshot (oder Export) der Festplatte und der Datenbank und bewahren Sie die Protokolle des Webservers und der WAF für die Untersuchung auf.
2. Isolieren
   • Wenn möglich, versetzen Sie die Website in den Wartungsmodus, deaktivieren Sie den öffentlichen Zugriff auf anfällige Endpunkte oder blockieren Sie die betreffenden IP-Bereiche.
3. Ändern Sie Anmeldeinformationen
   • Rotieren Sie Administrator- und Datenbankanmeldeinformationen. Wenn es Hinweise auf den Diebstahl von Anmeldeinformationen gibt, erzwingen Sie eine Passwortzurücksetzung für alle Benutzer mit erhöhten Rollen.
4. Bereinigen und wiederherstellen
   • Wenn ein Kompromiss bestätigt wird, ziehen Sie in Betracht, von einem bekannten, guten Backup vor dem Kompromiss wiederherzustellen. Wenden Sie dann den Patch an.
5. Erneut scannen und überwachen
   • Führen Sie Malware-Scanner und Integritätsprüfungen durch. Überwachen Sie die Website und Protokolle auf Anzeichen von persistierenden Hintertüren.
6. Beteiligte benachrichtigen
   • Befolgen Sie Ihre Richtlinie zur Benachrichtigung bei Datenverletzungen, wenn sensible Kunden- oder Benutzerdaten offengelegt wurden.
7. Überprüfung nach dem Vorfall
   • Dokumentieren Sie die Ursachen, die Zeit bis zur Entdeckung und die ergriffenen Maßnahmen. Aktualisieren Sie die Reaktionshandbücher entsprechend.

Wenn Sie Unterstützung bei der Triage und Bereinigung benötigen, können die verwalteten Dienste von WP-Firewall Unterstützung bei der Reaktion auf Vorfälle bieten.

Sicheres Testen und Verifizieren

Testen Sie niemals aktive, produktive Endpunkte mit Exploit-Payloads. Verwenden Sie eine isolierte Staging-Kopie Ihrer Website, um:

• Den Patch des Anbieters anzuwenden und die Funktionalität zu validieren.
• WAF-Regeln schrittweise zu aktivieren und Blockereignisse zu beobachten.
• Verwenden Sie nicht-destruktive Sicherheits-Scanner, um den Patch und das Verhalten der WAF zu überprüfen.
• Erfassen Sie Beispielanfragen, die in der Staging-Umgebung blockiert wurden, um Regeln zu verfeinern, ohne die Produktionsbenutzer zu beeinträchtigen.

Wenn Sie eine Gruppe von synthetischen Käufern oder Testern für Ihre E-Commerce-Workflows pflegen, verwenden Sie diese, um das Verhalten von Gutscheinen und den Checkout nach der Anwendung von Milderungsmaßnahmen zu überprüfen.

Härtung über diesen Vorfall hinaus

Um die Auswirkungen zukünftiger Plugin-Sicherheitsanfälligkeiten zu reduzieren, übernehmen Sie diese fortlaufenden Praktiken:

• Halten Sie alle Plugins, Themes und den WordPress-Kern auf dem neuesten Stand.
• Abonnieren Sie Sicherheitsintelligenz-Feeds und automatisierte Patch-Benachrichtigungen (oder nutzen Sie einen verwalteten Dienst).
• Verwenden Sie das Prinzip der geringsten Privilegien für das Datenbankkonto, das von WordPress verwendet wird: Vermeiden Sie die Gewährung übermäßiger DB-Rechte.
• Überwachen Sie Protokolle und richten Sie Warnungen bei ungewöhnlichen Mustern ein (z. B. Spitzen bei 500er-Fehlern, Datenbankfehlern).
• Halten Sie einen regelmäßig getesteten Backup- und Wiederherstellungsprozess aufrecht.
• Verwenden Sie WAF-Schutzmaßnahmen, die auf Ihre Anwendung abgestimmt sind, und aktivieren Sie virtuelle Patches, wenn verfügbar.
• Erzwingen Sie starke Authentifizierung — MFA für Administratorkonten und gehärtete Anmeldeprotektionen für Redakteure und andere privilegierte Benutzer.
• Periodische Sicherheitsprüfungen und Code-Überprüfungen für Anpassungen.

Beispielindikatoren, auf die man achten sollte (nicht erschöpfend)

• Unautorisierte POST-Anfragen an Gutscheinendpunkte, die von IPs mit hohem Scanning-Ruf stammen.
• Große oder unerwartete SQL-Abfragevolumina, die vom Webserver-Benutzer stammen.
• Datenbankzeilen, die unerwartete Inhalte oder Änderungen an Kurszugriffsaufzeichnungen enthalten.
• Neue oder modifizierte PHP-Dateien in Upload- oder Plugin-Verzeichnissen.
• Verdächtige Spitzen bei Benutzerregistrierungen oder Passwortzurücksetzungen, die mit Anfragen an Gutscheinendpunkte zusammenfallen.

Häufig gestellte Fragen

F: Kann ich mich ausschließlich auf eine WAF verlassen, anstatt das Plugin zu aktualisieren?
A: Nein. WAFs bieten kritische zeitliche Milderungen und können bekannte Angriffsarten blockieren, sind jedoch kein Ersatz für Anbieter-Patches. Die richtige langfristige Lösung besteht darin, das Plugin auf die gepatchte Version zu aktualisieren und etwaige Kompromisse zu beheben.

F: Wird das Deaktivieren der Gutscheinfunktionalität die Checkout-Workflows unterbrechen?
A: Möglicherweise. Das Deaktivieren von Gutscheinen ist eine vorübergehende Milderungsmaßnahme. Wenn Gutscheine für Einnahmen oder Aktionen unerlässlich sind, verwenden Sie eine sorgfältige Risikoanalyse und ziehen Sie WAF-virtuelle Patches plus eingeschränkten Zugriff vor, anstatt eine vollständige Deaktivierung vorzunehmen, es sei denn, es ist absolut notwendig.

F: Ist Multisite stärker gefährdet?
A: Multisite-Installationen können mehr Seiten exponieren, wenn das Plugin netzwerkaktiviert ist. Behandeln Sie das Multisite-Hosting als eine höherpriorisierte Umgebung für Patches.

Wie man die Behebung über viele Seiten priorisiert

Wenn Sie Hunderte oder Tausende von WordPress-Instanzen verwalten, gehen Sie folgendermaßen vor:

1. Triage — Identifizieren Sie Seiten mit installiertem Tutor LMS und priorisieren Sie nach Exposition (öffentliche Kurskataloge, E-Commerce-Integration, Nutzeranzahl).
2. Aufnäher Kritische/hoch exponierte Seiten zuerst.
3. Anwenden WAF-virtuelle Patches für nicht gepatchte Seiten.
4. Delegieren die Staging-Validierung an die Seitenbesitzer, wo möglich, aber behalten Sie die zentrale Aufsicht über den Patch-Status und die Vorfallaktivität.

Automatisierung und zentrale Sicherheitsverwaltung reduzieren die Behebungszeit drastisch. Wenn Sie einen Hosting-Betrieb oder eine Agentur führen, erstellen Sie ein automatisiertes Inventar und eine Patch-Orchestrierungspipeline.

---

Sichern Sie Ihre Seite noch heute — Beginnen Sie mit dem kostenlosen Plan von WP-Firewall

Wenn Sie schnellen, verwalteten Schutz wünschen, während Sie Plugins patchen und Systeme absichern, probieren Sie den Basisplan (kostenlos) von WP-Firewall aus. Er bietet grundlegenden Schutz: eine verwaltete Firewall, ein Anwendungs-WAF, unbegrenzte Bandbreite, einen integrierten Malware-Scanner und Minderung der OWASP Top 10-Risiken — alles Notwendige, um die Exposition gegenüber öffentlichen SQLi-Versuchen und anderen häufigen Angriffen zu reduzieren. Melden Sie sich an und schützen Sie Ihre Seite jetzt: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Letzte Worte – behandeln Sie dies als dringend

Eine nicht authentifizierte SQL-Injection gehört zu den gefährlichsten Arten von Schwachstellen, mit denen Sie konfrontiert werden können, da sie Angreifern einen direkten Zugang zu Ihrer Datenbank ermöglicht. Der offizielle Patch (Tutor LMS 3.9.7 oder später) ist die endgültige Lösung; jedoch bedeutet die Geschwindigkeit, mit der Angreifer diese Art von Schwachstelle finden und ausnutzen können, dass die Zeit der Feind ist. Wenden Sie den Patch so schnell wie möglich an. Wenn Sie dies nicht können, wenden Sie sofort WAF-virtuelles Patchen an, verschärfen Sie den Zugriff auf Endpunkte und erhöhen Sie die Überwachung und Backups.

Wenn Sie Hilfe bei der Umsetzung dieser Minderung benötigen — einschließlich schneller WAF-Bereitstellung, virtuellem Patchen und Incident Response — steht Ihnen das Team von WP-Firewall zur Verfügung. Unsere verwalteten Firewall- und Scanning-Dienste sind darauf ausgelegt, die Exposition zu reduzieren und Ihnen Spielraum zu geben, um dauerhafte Lösungen mit Vertrauen anzuwenden.

Bleiben Sie sicher, und überprüfen Sie jetzt Ihre Tutor LMS-Version.