Zum Hauptinhalt springen
How Can We Help?
< All Topics

Die Supply-Chain ist bei WordPress der grösste blinde Fleck: Jedes Plugin bringt fremden Code und fremde Update-Prozesse mit. Ein Plugin ist fremder Code mit vollen Rechten auf dem Server. Wer ein Plugin installiert, vertraut dem Entwickler, seinem Update-Prozess und allen künftigen Eigentümern.

Typische Supply-Chain-Szenarien

  • Verwaiste Plugins: Der Entwickler pflegt nicht mehr. Neue Lücken werden nie geschlossen. Plugins werden auf WordPress.org zwar geschlossen, bleiben aber auf bestehenden Sites aktiv, ohne Warnung.
  • Verkaufte Plugins: Beliebte Plugins mit vielen Installationen werden gekauft. Der neue Eigentümer liefert per regulärem Update Werbung, Tracking oder Backdoors aus.
  • Kompromittierte Entwickler-Accounts: Mit gestohlenen Zugangsdaten werden manipulierte Versionen veröffentlicht. WordPress.org hat 2024 für Plugin-Committer 2FA eingeführt; bei kommerziellen Anbietern mit eigenem Update-Server ist der Schutz unterschiedlich.
  • „Nulled“ Premium-Plugins und -Themes: Gecrackte Versionen aus inoffiziellen Quellen enthalten sehr häufig Backdoors, versteckte Admin-Accounts oder SEO-Spam. Kein „Testen auf Staging“ rechtfertigt das: Auch Staging hat oft Zugang zu Produktionsdaten.
  • Abhängigkeiten: Plugins bündeln Composer- und npm-Pakete, die selbst verwundbar oder kompromittiert sein können.

Plugins bewerten: Checkliste

  • Letztes Update in den letzten Monaten? „Tested up to“ aktuell?
  • Aktive Installationen, Support-Forum: Werden Fragen beantwortet?
  • Wer steht dahinter? Firma mit Geschäftsmodell oder Einzelperson?
  • Sicherheitshistorie: Wie schnell wurden frühere Lücken geschlossen? (Patchstack-, Wordfence- oder WPScan-Datenbank)
  • Gibt es ein Vulnerability Disclosure Program (VDP) oder Bug-Bounty-Teilnahme?
  • Umfang: Braucht es wirklich ein 2-MB-Plugin für eine Funktion, die 20 Zeilen Code wären?
  • Code-Stichprobe: Werden Nonces und Capabilities geprüft, Eingaben sanitized, Ausgaben escaped?

Laufender Schutz

  • Schwachstellen-Monitoring abonnieren (Patchstack, Wordfence, WPScan, oder Hoster-Integration).
  • Changelogs lesen bei Plugins, die den Eigentümer gewechselt haben. Auffällige neue Berechtigungen oder externe Domains sind Warnsignale.
  • Geschlossene Plugins erkennen: Regelmässig prüfen, ob eingesetzte Plugins noch auf WordPress.org verfügbar sind. Einige Security-Plugins und Wartungstools melden das automatisch.
  • Integrität prüfen: wp plugin verify-checksums --all erkennt veränderte Dateien bei Plugins aus dem offiziellen Verzeichnis.
  • Composer-Lockfile und definierte Versionen statt automatisch „latest“ in kritischen Projekten; Updates bewusst ausrollen.
  • Ausgehende Verbindungen beschränken mit WP_HTTP_BLOCK_EXTERNAL oder Firewall-Regeln. So kann manipulierter Code schlechter „nach Hause telefonieren“.

Weiterführende Artikel

Quellen und Dokumentation

Schlagwörter: