Plugin-Name	Amazon Scraper
Art der Schwachstelle	CSRF (Cross-Site Request Forgery)
CVE-Nummer	CVE-2026-8419
Dringlichkeit	Niedrig
CVE-Veröffentlichungsdatum	2026-05-20
Quell-URL	CVE-2026-8419

Dringend: CSRF → Stored XSS im Amazon Scraper-Plugin (≤ 1.1) — Was WordPress-Seitenbesitzer jetzt tun müssen

Veröffentlicht: 19. Mai 2026
CVE: CVE-2026-8419
Schwere: Niedrig (CVSS 4.3) — aber umsetzbar, wenn mit Benutzerinteraktion kombiniert

Zusammenfassung

Eine kürzlich offengelegte Schwachstelle im Amazon Scraper WordPress-Plugin (Versionen ≤ 1.1) kann von einer Cross-Site Request Forgery (CSRF) zu einer gespeicherten Cross-Site Scripting (XSS)-Bedingung verknüpft werden. Obwohl die gemeldete Schwere niedrig ist, kann das Problem in gezielten Szenarien ausgenutzt werden, um JavaScript in privilegierten Benutzerkontexten (z. B. Administratoren oder Redakteuren) nach Social Engineering auszuführen. Dieser Beitrag erklärt die Schwachstelle auf praktischer Ebene, durchläuft realistische Angriffs- und Erkennungsszenarien und gibt einen priorisierten Minderungplan, den Sie sofort umsetzen können — einschließlich wie unsere WP-Firewall-Schutzmaßnahmen Ihnen helfen können, virtuell zu patchen und das Risiko zu reduzieren, während Sie die Behebung vornehmen.

TL;DR

• Eine CSRF-Schwachstelle in Amazon Scraper-Plugin-Versionen bis 1.1 ermöglicht es einem Angreifer, Funktionen im Plugin ohne gültigen Nonce oder ordnungsgemäße Berechtigungsprüfungen auszulösen.
• Diese Aktion kann dazu führen, dass benutzereingereichte Daten gespeichert und später ohne angemessene Escaping gerendert werden — wodurch CSRF in ein gespeichertes XSS umgewandelt wird.
• Sofortige Maßnahmen: Deaktivieren oder Entfernen des Plugins, wenn Sie es verwenden und nicht sofort patchen können; administrative Zugriffe einschränken; Härtung und Überwachung aktivieren; WAF-virtuelle Patchregeln anwenden (unsere WP-Firewall WAF kann helfen).
• Langfristig: Prinzip der geringsten Privilegien anwenden, 2FA aktivieren, Anmeldeinformationen rotieren, die Seite auf verdächtige Änderungen und neue Administratorkonten überprüfen.

Warum das wichtig ist (in einfacher Sprache)

Ein CSRF-Problem bedeutet, dass ein Angreifer einen Browser (von jemandem, der in Ihr WordPress-Backend eingeloggt ist) dazu bringen kann, eine Anfrage zu senden, der das Plugin vertraut. Wenn diese Anfrage bösartigen HTML/JavaScript enthält, das das Plugin später speichert und ohne Bereinigung anzeigt, kann der gespeicherte Inhalt im Browser des Administrators ausgeführt werden. Das ist gespeichertes XSS. Im richtigen Kontext kann dies den Diebstahl von Cookies (wenn Cookies nicht als geschützt markiert sind), Kontoübernahmen oder die Installation von Hintertüren ermöglichen. Das anfängliche Risiko ist “niedriger”, da der Angriff Benutzerinteraktion erfordert (ein privilegierter Benutzer, der eine gestaltete Seite besucht oder auf einen Link klickt). Aber reale Angriffe verlassen sich häufig auf Social Engineering, um diese Interaktion zu erreichen — und selbst eine einzige erfolgreiche Ausnutzung kann verheerend sein.

Schwachstellendetails — technisch, aber nicht ausnutzbar

• Typ: CSRF, das zu gespeichertem XSS führt
• Betroffenes Plugin: Amazon Scraper (WordPress-Plugin)
• Betroffene Versionen: ≤ 1.1
• CVE: CVE-2026-8419
• Ausnutzungsmodell: Der Angreifer erstellt eine Anfrage, die das Plugin dazu bringt, vom Angreifer kontrollierte Eingaben in der Datenbank zu speichern (zum Beispiel Produktdaten, Metadaten oder einen Protokolleintrag), und dieser gespeicherte Inhalt wird später auf einer Administrationsseite ohne angemessene Escaping gerendert. Da der Plugin-Endpunkt CSRF-Schutz (Nonces oder Referer-Überprüfungen) und Berechtigungsprüfungen nicht hat oder unsachgemäß behandelt, benötigt der Angreifer nur einen privilegierten Benutzer, um die Anfrage in einem Browser auszulösen, in dem der Benutzer authentifiziert ist.

Was der Angreifer benötigt

• Die Ziel-WordPress-Seite mit dem aktiven verwundbaren Plugin.
• Ein privilegierter Benutzer (Administrator/Redakteur) auf der Zielseite, der mit dem vom Angreifer kontrollierten Inhalt interagiert (z. B. auf einen Link klicken, eine Seite laden oder dazu verleitet werden, ein Formular einzureichen).
• Eine gestaltete Seite oder E-Mail, die die bösartige Anfrage (CSRF) aus dem Browser des privilegierten Benutzers auslöst.

Warum CVSS niedrig ist und was das für Sie bedeutet

Der öffentliche CVSS beträgt 4.3 (Niedrig), da der Exploit Benutzerinteraktion erfordert und die Schwachstellenkette von einem privilegierten Benutzer abhängt, der eine Aktion ausführt. Niedriger CVSS bedeutet nicht “ignorieren” — es bedeutet, dass das Fenster für den Angreifer, erfolgreich zu sein, enger ist, aber immer noch realistisch. In Umgebungen mit vielen Administratoren oder wo Administratorbenutzer sozial manipuliert werden können (z. B. durch Phishing), wird das Risiko erheblich.

Realistisches Angriffs-Playbook (hochrangig)

1. Der Angreifer lockt einen Administrator auf eine feindliche Webseite oder sendet eine HTML-E-Mail mit eingebettetem Inhalt, der einen Hintergrund-POST an den verwundbaren Plugin-Endpunkt auslöst.
2. Der Browser des Opfers sendet die Anfrage, während er authentifiziert ist; das Plugin akzeptiert die Anfrage, da es an nonce-/Fähigkeitsüberprüfung fehlt.
3. Das Plugin speichert vom Angreifer bereitgestellten Inhalt in der Datenbank (eine Beschreibung, Notiz, Versandinformationen, Produktbeschreibung oder Ähnliches).
4. Später, wenn dieser gespeicherte Inhalt im WordPress-Adminbereich oder anderswo ohne ordnungsgemäße Escaping angezeigt wird, wird die bösartige Payload im Admin-Kontext ausgeführt.
5. Die Folgen können Sitzungsmissbrauch, Erstellung von Administratorkonten, Injection von persistierenden Hintertüren oder Datenexfiltration umfassen.

Erkennung — Anzeichen, auf die man achten sollte

• Unerwartete neue Beiträge, Produkteinträge oder Metadaten, die <script> Tags oder verdächtiges Inline-JavaScript enthalten.
• Administrative UI zeigt unbekannte Inhalte in Textfeldern an (insbesondere Felder, die normalerweise nur strukturierte Daten enthalten).
• Hinweise auf kürzliche Änderungen in Plugin-Dateien oder unbekannte geplante Aufgaben (Cron).
• Ungewöhnliche Protokolleinträge: POST-Anfragen an Plugin-Endpunkte von außerhalb Ihrer Domain oder Anfragen, die von regulären Benutzeragenten zu ungewöhnlichen Zeiten stammen.
• Neue oder modifizierte Administratorbenutzer, die Sie (oder Ihr Team) nicht erstellt haben.

Sofortige Minderung — priorisierte Checkliste (was jetzt zu tun ist)

1. Wenn Sie Amazon Scraper (≤ 1.1) verwenden, nehmen Sie es jetzt offline.
   • Deaktivieren Sie das Plugin sofort, wenn Sie sich Ausfallzeiten leisten können. Wenn Sie darauf für Kernoperationen angewiesen sind und es nicht sofort deaktivieren können, fahren Sie mit den anderen Schritten fort und planen Sie die Deaktivierung so schnell wie möglich.
2. Sperren Sie den administrativen Zugriff.
   • Begrenzen Sie die IPs, die auf wp-admin zugreifen können (über Hosting-Kontrollen oder Firewall-Regeln).
   • Reduzieren Sie vorübergehend die Anzahl der Administratorkonten. Überprüfen Sie Konten und entfernen Sie unnötige Admin-/Editor-Rollen.
   • Erfordern Sie eine stärkere Authentifizierung (2FA) für alle Benutzer mit erhöhten Rechten.
3. Scannen Sie auf Kompromittierung.
   • Führen Sie einen Malware-Scan über das Dateisystem und die Datenbank durch. Suchen Sie speziell nach Skripten, die in Post-Meta, Optionen und Plugin-Protokollen gespeichert sind.
   • Überprüfen Sie kürzlich geänderte Dateien und unbekannte Cron-Jobs.
   • Überprüfen Sie wp_users auf unbefugte Konten.
4. Drehen Sie die Anmeldeinformationen.
   • Ändern Sie die Passwörter für betroffene Administratorkonten und alle Dienstkonten.
   • Widerrufen und erneuern Sie API-Schlüssel, die möglicherweise in den Plugin-Einstellungen gespeichert sind.
5. Wenden Sie Kontenrendering-Kontrollen an.
   • Fügen Sie einen Content-Security-Policy (CSP)-Header hinzu, um die Auswirkungen von gespeichertem XSS zu reduzieren (CSP kann die Ausführung von Inline-Skripten verhindern, wenn es richtig konfiguriert ist).
6. Virtueller Patch mit WAF-Regeln.
   • Erstellen Sie WAF-Regeln, um verdächtige POST-Anfragen an die Endpunkte des Plugins zu blockieren und um Payloads zu blockieren, die skriptähnliche Muster in Formularfeldern enthalten.
   • Aktivieren Sie im WP-Firewall das verwaltete WAF-Regelsystem und fügen Sie eine benutzerdefinierte Regel hinzu, um Anfragen mit verdächtigen Eingaben zu blockieren, die auf die anfälligen Parameternamen abzielen (wir können helfen, diese Regel zu erstellen).
7. Bereiten Sie die Wiederherstellung vor.
   • Wenn Sie einen Kompromiss feststellen, stellen Sie von einem sauberen Backup wieder her, das vor dem Vorfall erstellt wurde. Wenn kein sauberes Backup vorhanden ist, isolieren Sie die Site und stellen Sie sie aus einem bekannten guten Zustand wieder her.

Spezifische sichere Härtungsmaßnahmen, die Sie sofort umsetzen können.

• Aktivieren Sie die Zwei-Faktor-Authentifizierung für alle Administrator- und Redakteurskonten.
• Erzwingen Sie Passwortzurücksetzungen für alle Benutzer, die Administrator-/Redakteursrollen auf der Site haben.
• Begrenzen Sie, welche IPs auf /wp-admin und /wp-login.php zugreifen können (wenn möglich).
• Blockieren Sie externe Anfragen an plugin-spezifische AJAX/Aktionsendpunkte, wenn sie nicht öffentlich zugänglich sein sollen.
• Verwenden Sie serverseitige Sicherheitsregeln, um Anfragen zu blockieren, die verdächtige Zeichenfolgen enthalten (Skript-Tags, Javascript:, onerror=, onload=) in POST-Inhalten.

Wie WP-Firewall helfen kann (praktische, funktionsorientierte Anleitung).

• Virtuelles Patching: Unser WAF kann die Angriffsvektoren blockieren, indem er bösartige POST-Anfragen und Formularübermittlungen, die an die Plugin-Endpunkte gerichtet sind, abfängt. Dies reduziert sofort die Angriffsfläche – selbst wenn das Plugin aktiv bleibt.
• Eingabekontrolle: WP-Firewall überprüft und filtert die Anforderungs-Payloads auf skriptähnliche Fragmente und verdächtige Sequenzen, die häufig in gespeichertem XSS verwendet werden.
• Admin-Härtung: 2FA durchsetzen, den Admin-Zugriff nach IP einschränken und das Anmeldeverhalten überwachen.
• Malware-Scans und Bereinigungsoptionen: Unser Scanner kann verdächtige Dateien und Inhalte identifizieren; bei kostenpflichtigen Plänen sind automatische Entfernung und Behebung verfügbar.
• Verwaltete Regeln und Updates: Unser Team veröffentlicht neue WAF-Signaturen, sobald neue Proof-of-Concepts oder Angriffsmuster erscheinen.

Wichtig: Wenn Sie bereits den kostenlosen WP-Firewall-Plan nutzen, aktivieren Sie das verwaltete Regelset und führen Sie jetzt einen vollständigen Scan durch. Wenn Sie noch kein WP-Firewall-Konto haben, deckt unser kostenloser Plan die wesentlichen Schutzmaßnahmen ab (verwaltete Firewall, WAF, Malware-Scans und OWASP Top 10 Minderung), was eine schnelle Möglichkeit ist, die Exposition zu reduzieren. Siehe die untenstehende Notiz, wie Sie anfangen können.

Entwicklerleitfaden – wie man diese Art von Fehlern behebt (für Plugin-Autoren)

Wenn Sie Plugins pflegen (oder Auftragnehmer einstellen, die dies tun), ist die Fehlerklasse, die diese Schwachstelle ermöglichte, gut verstanden und vermeidbar. Die Behebungen sollten sicher, konsistent und den besten Sicherheitspraktiken von WordPress folgen:

1. Überprüfen Sie immer ein Nonce bei Formularen und Admin-Aktionen

   // Im Formular (Ausgabe):
   

2. Überprüfen Sie die Benutzerfähigkeiten

   if ( ! current_user_can( 'manage_options' ) ) {
   

3. Bereinigen Sie eingehende Daten und escapen Sie bei der Ausgabe

   // Eingabe vor dem Speichern bereinigen;
   

4. Verwenden Sie für REST-API-Endpunkte immer permission_callback

   register_rest_route( 'my-plugin/v1', '/save', array(;
   

5. Vermeiden Sie das Speichern von ungefiltertem HTML, es sei denn, es ist unbedingt erforderlich

   $allowed = array(;
   

Entwickler-Checkliste für ein Sicherheitsupdate

• Fügen Sie Nonce-Prüfungen zu jeder Aktion hinzu, die den Status ändert.
• Fügen Sie Berechtigungsprüfungen zu jeder Aktion hinzu, die den Status ändert.
• Alle Eingaben vor dem Speichern bereinigen und validieren.
• Entkommen Sie alles, wenn Sie Ausgaben auf Admin- oder Front-End-Seiten rendern.
• Fügen Sie Protokollierung für verdächtige oder fehlgeschlagene Nonce-/Berechtigungsprüfungen hinzu.
• Versenden Sie einen Patch und kommunizieren Sie klar mit den Benutzern (einschließlich Anweisungen zur manuellen Minderung).

Stichproben und forensische Schritte, wenn Sie einen Kompromiss vermuten.

• Durchsuchen Sie die Datenbank nach Skript-Tags:

  SELECT * FROM wp_posts WHERE post_content LIKE '%

  Durchsuchen Sie wp_postmeta, wp_options und andere Plugin-Tabellen nach verdächtigen Einträgen.

• Prüfen Sie, ob neue Administratoren vorhanden sind:

  SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE ID IN (
   SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE 'ministrator%'
  );

• Überprüfen Sie das Dateisystem auf kürzlich geänderte Dateien:

  find . -type f -mtime -30

• Untersuchen Sie die Zugriffsprotokolle:

  Suchen Sie nach POST-Anfragen, die auf Plugin-Endpunkte abzielen oder Anfragen mit scriptähnlichen Payloads enthalten.

Warum virtuelle Patches in diesem Fall nützlich sind.

Wenn nachgelagerte Benutzer ein Plugin nicht sofort aktualisieren können (weil der Anbieter keinen Patch veröffentlicht hat oder es mit Ihrer Umgebung inkompatibel ist), ist das virtuelle Patchen am WAF der schnellste Weg, um die Exposition zu reduzieren. Ein WAF kann:

• Anfragen blockieren, die versuchen, Skript-Tags oder JavaScript-ähnliche Payloads einzureichen.
• CSRF-ähnliche Schutzmaßnahmen durch Blockieren von Anfragen durchsetzen, wenn der Origin/Referer verdächtig ist.
• Verdächtige IPs, die versuchen, auf Plugin-Endpunkte zuzugreifen, drosseln und blockieren.

Notiz: Virtuelles Patchen ist eine Minderung, kein Ersatz für die Anwendung einer echten Codekorrektur. Es reduziert das Risiko, sollte jedoch nur als vorübergehende Maßnahme verwendet werden, bis das Plugin gepatcht oder ersetzt wird.

Wie Sie Ihre Arbeit priorisieren (empfohlener Zeitrahmen)

• Innerhalb von 0–4 Stunden: Deaktivieren Sie das Plugin, wenn möglich; aktivieren Sie WAF-Schutzmaßnahmen und überprüfen Sie die Admin-Konten. Erzwingen Sie Passwortzurücksetzungen und aktivieren Sie 2FA.
• Innerhalb von 24 Stunden: Scannen Sie nach Anzeichen für Kompromittierungen; überprüfen Sie Protokolle und Datenbanken. Fügen Sie serverseitige Regeln hinzu, um Angriffsvektoren zu blockieren (CSP, Content-Type-Überprüfungen).
• Innerhalb von 48–72 Stunden: Entfernen oder ersetzen Sie das Plugin oder wenden Sie den vom Anbieter bereitgestellten Patch an. Wenn Sie nicht patchen können, behalten Sie die WAF-Schutzmaßnahmen und überwachen Sie weiterhin.
• Laufend: Überwachen Sie die Website, führen Sie regelmäßige Sicherheitsüberprüfungen durch und stellen Sie sicher, dass Plugin-Updates Teil Ihrer Wartungsroutine sind.

Langfristige Sicherheitsverbesserungen (Website-Besitzer & Agenturen)

• Führen Sie ein Inventar der installierten Plugins, deren letztes Aktualisierungsdatum und den Ruf des Anbieters für zeitnahe Sicherheitsfixes.
• Führen Sie regelmäßig automatisierte Scans in der Staging- und Produktionsumgebung durch.
• Übernehmen Sie eine Richtlinie des geringsten Privilegs für Benutzerkonten und API-Schlüssel.
• Halten Sie Backups mit Integritätsprüfungen und Offline-Kopien, um eine schnelle Wiederherstellung zu ermöglichen.
• Verwenden Sie gestaffelte Bereitstellungen und automatisierte Tests, bevor Sie Plugin-Updates in der Produktion anwenden.

Wenn Sie feststellen, dass Sie kompromittiert wurden — schnelle Reaktionsschritte

1. Isolieren Sie die Website: nehmen Sie sie offline oder versetzen Sie sie in den Wartungsmodus.
2. Bewahren Sie Protokolle und Datenbankschnappschüsse für Untersuchungen auf.
3. Bestimmen Sie den Umfang: geänderte Dateien, hinzugefügte Konten, Cron-Jobs/persistente Hintertüren.
4. Stellen Sie von einem bekannt sauberen Backup wieder her oder bauen Sie aus vertrauenswürdigen Quellen neu auf.
5. Rotieren Sie alle Anmeldeinformationen und machen Sie Sitzungen für privilegierte Benutzer ungültig.
6. Härten Sie die Umgebung und überwachen Sie auf eine erneute Infektion.

Ein kurzer Leitfaden für Plugin-Wartende (Sicherheit durch Design)

• Erzwingen Sie serverseitige Überprüfungen (Nonces + Berechtigungsprüfungen) für alle zustandsverändernden Aktionen.
• Etablieren Sie CI-basierte Sicherheitstests (SAST, Abhängigkeitsprüfungen).
• Bieten Sie ein VDP oder einen klaren Prozess an, um Schwachstellen verantwortungsbewusst zu melden.
• Veröffentlichen Sie zeitnahe Sicherheitsupdates und geben Sie klare Upgrade-Anweisungen für Benutzer.

Datenschutz- und rechtliche Überlegungen

Wenn gespeichertes XSS ausgenutzt wurde, könnte ein Angreifer auf kontobezogene Daten zugegriffen oder im Namen von Administratoren Aktionen durchgeführt haben. Je nach Ihrem Rechtsgebiet und den betroffenen Daten haben Sie möglicherweise Offenlegungspflichten. Konsultieren Sie einen Rechtsbeistand, wenn Sie Beweise für den Datenzugriff oder die Datenexfiltration finden.

Erhalten Sie praktischen Schutz in Minuten — kostenloser Plan verfügbar

Sichern Sie Ihre WordPress-Website jetzt mit grundlegenden, aber effektiven Schutzmaßnahmen. Unser kostenloser Plan deckt die wesentlichen Verteidigungen ab, die jede Website haben sollte:

• Verwaltete Firewall und WAF, um Exploit-Versuche zu blockieren
• Unbegrenzte Bandbreitenscans und Schutz, damit Angriffe Ihr Hosting-Kontingent nicht aufbrauchen
• Malware-Scanner, der Dateien und Datenbankeinträge auf verdächtige Inhalte überprüft
• Minderung der OWASP Top 10-Risiken zur Reduzierung gängiger Webangriffsvektoren

Schützen Sie Ihre Website schnell mit unserem Basic Free-Plan

Wenn Sie die Exposition sofort reduzieren möchten, melden Sie sich für den Basic (Free)-Plan von WP-Firewall an, um schnell verwaltete Firewall- und WAF-Schutzmaßnahmen einzurichten: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Der kostenlose Plan umfasst: verwaltete Firewall, unbegrenzte Bandbreite, WAF, Malware-Scanner und OWASP Top 10-Minderung.)

Ein späteres Upgrade kann Ihnen automatisierte Malware-Entfernung, IP-Zulassungs-/Verweigerungskontrolle und fortgeschrittenes virtuelles Patchen bieten, wenn Sie es benötigen.

Gespräch mit Ihrem Hosting-Team oder Entwickler — was zu fragen ist

• Verwenden wir das Amazon Scraper-Plugin? Wenn ja, welche Version?
• Können wir es vorübergehend offline nehmen? Wenn nicht, können wir den Zugriff auf die Plugin-Endpunkte per IP blockieren?
• Haben wir ein aktuelles sauberes Backup? Sind Offline-Backups verfügbar?
• Können Sie 2FA aktivieren und es sofort für Admin-/Editor-Konten durchsetzen?
• Können wir WAF-Regeln hinzufügen, um verdächtige POSTs und scriptähnliche Payloads zu blockieren?

Abschließende Gedanken — seien Sie pragmatisch und priorisieren Sie Risiken

Selbst Schwachstellen, die als “niedrig” eingestuft sind, können ausgenutzt werden, wenn ein Angreifer nur einen privilegierten Benutzer täuschen muss. Der sinnvolle Ansatz ist mehrschichtig: Entfernen oder patchen Sie die verwundbare Komponente; wenn Sie das nicht können, virtuellen Patch am WAF; administrative Zugriffe absichern; aggressiv scannen und überwachen. Planung und Automatisierung reduzieren die Reaktionszeit und machen Vorfälle viel einfacher einzudämmen.

Wenn Sie direkte Hilfe bei der Implementierung von WAF-virtuellen Patches, der Einrichtung von Regelblöcken für die verwundbaren Endpunkte oder der Durchführung eines schnellen Scans und einer Bereinigung benötigen, steht Ihnen unser Team bei WP-Firewall zur Verfügung. Beginnen Sie mit dem kostenlosen Basisplan, um schnell grundlegende Schutzmaßnahmen zu implementieren: https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Literaturhinweise und weiterführende Literatur

• CVE-2026-8419 (öffentliche Beratungskennung)
• Allgemeine Best Practices zur Sicherheit von WordPress: nonce-Nutzung, Berechtigungsprüfungen, Eingabesäuberung und Ausgabevermeidung (siehe WordPress-Entwicklerdokumentation)
• OWASP-Leitlinien zu CSRF- und XSS-Minderungen

Wenn Sie Hilfe benötigen: Unsere Experten können Ihnen helfen, Ihre Website zu überprüfen, virtuelle Patches einzurichten und eine Bereinigung durchzuführen, wenn Sie einen Kompromiss vermuten. Kontaktieren Sie uns über das WP-Firewall-Dashboard, nachdem Sie sich für einen kostenlosen Basisplan angemeldet haben – es ist der schnellste praktische Schritt, um Ihre Exposition zu reduzieren, während Sie an der Behebung arbeiten.