Eine Schwachstelle melden
Schreiben Sie an [email protected]. Nennen Sie die betroffene URL oder den Plugin-Slug, die Version, die Sie getestet haben, und genügend Details, damit wir den Befund reproduzieren können. Ein kurzer Proof-of-Concept hilft mehr als ein Scanner-Bericht.
Die erste Nachricht müssen Sie nicht verschlüsseln. Wenn der Befund es wert ist, vereinbaren wir in der Antwort einen verschlüsselten Kanal. Wir veröffentlichen derzeit keinen PGP-Schlüssel, und das sagen wir lieber offen, als eine Schlüsseldatei zu listen, die nicht existiert.
Wir antworten auf Deutsch, Englisch und Polnisch.
Was diese Richtlinie abdeckt
Sie umfasst wppoland.com, plogins.com und jedes Plugin, das wir unter dem Namen plogins veröffentlichen - ob über das WordPress.org-Verzeichnis oder über unsere eigene Verteilung.
Nicht abgedeckt sind Plugins, Themes oder Hostings von Drittanbietern, die wir lediglich im Auftrag eines Kunden installieren oder warten. Diese gehören zu ihren Autoren; eine Meldung leiten wir auf Wunsch weiter, aber fremden Code können wir nicht patchen. Wenn Sie etwas in einer Komponente gefunden haben, die wir empfohlen haben, wollen wir es trotzdem wissen - denn dann ändert das, was wir empfehlen.
Was wir zusagen
| Phase | unsere Zusage |
|---|---|
| Bestätigung Ihrer Meldung | 2 Werktage |
| erste Einschätzung, bestätigt oder nicht | 5 Werktage |
| Patch für eine bestätigte kritische Schwachstelle in unserem Plugin | 7 Tage ab Bestätigung |
| Patch für einen bestätigten hohen oder mittleren Schweregrad | nächstes geplantes Release |
| öffentliche Empfehlung nach dem Patch | innerhalb von 14 Tagen |
Bei einer kritischen Schwachstelle ziehen wir das Plugin, wenn ein Patch nicht innerhalb dieser 7 Tage gelingt, aus der Verteilung zurück, statt eine bekannte Lücke weiter im Umlauf zu lassen - und wir sagen Ihnen, dass wir genau das getan haben.
Die Frist beginnt, wenn wir Ihre Meldung erhalten, nicht wenn die Schwachstelle entstanden ist. Wenn wir länger als 10 Werktage schweigen, ohne einen Grund zu nennen, behandeln Sie das als unser Versagen und eskalieren Sie an den zweiten Kontakt in unserer security.txt.
Wenn eine Behebung nicht rechtzeitig gelingt
Manchmal ist ein Fix nicht fertig, oder er ist fertig, beschädigt aber etwas, das Nutzer mehr trifft als die Schwachstelle selbst. In dem Fall veröffentlichen wir einen Workaround und sagen, warum die Behebung später kommt. Was wir nicht tun: schweigen und darauf hoffen, dass der Finder das Interesse verliert.
Wenn Sie eine Disclosure-Frist haben, nennen Sie sie in der ersten Nachricht. Wir halten sie ein oder verhandeln sie offen. Unbegrenzte Embargos verlangen wir nicht.
Safe Harbour
Wenn Sie die folgenden Regeln einhalten, verfolgen wir wegen Ihrer Forschung keine rechtlichen Schritte gegen Sie und unterstützen keine - auf Wunsch bestätigen wir das schriftlich.
Testen Sie nur gegen Ihre eigene Installation oder gegen eine Website, für die Sie ausdrücklich autorisiert sind. Führen Sie keine Denial-of-Service-Tests durch. Senden Sie keinen Spam und keine Massennachrichten. Setzen Sie kein Social Engineering gegen unsere Mitarbeitenden, Kunden oder Lieferanten ein. Greifen Sie nicht auf Daten anderer zu, verändern, exfiltrieren oder speichern Sie sie nicht, und stoppen Sie in dem Moment, in dem Sie genug haben, um den Befund zu belegen.
Wenn Sie versehentlich auf Daten anderer zugreifen: Stoppen Sie, speichern Sie nichts, und schildern Sie in der Meldung, was passiert ist. Das hören wir lieber von Ihnen.
Anerkennung statt Geld
Wir betreiben kein Bug-Bounty-Programm und zahlen keine Prämien. Wir sind ein kleines Unternehmen und sind da ehrlicher, als ein Programm zu bewerben, das wir nicht finanzieren können.
Was wir anbieten: Wir nennen Melder mit Name oder Handle in den Release Notes und in der öffentlichen Empfehlung, wenn sie das möchten, und wir bestätigen schriftlich, dass eine Meldung gültig war und was wir unternommen haben. Für einen Researcher, der eine Erfolgsbilanz aufbaut, ist diese schriftliche Bestätigung meist das Entscheidende.
Was wir über unsere eigenen Plugins veröffentlichen
Zwei Zusagen, die daraus folgen, wie sich das Plugin-Ökosystem tatsächlich verhält. Wir haben das WordPress.org-Verzeichnis im August 2026 vermessen und festgestellt, dass mehr als die Hälfte aller gelisteten Plugins seit zwei Jahren kein Update erhalten hat, fast immer ohne jede Ankündigung.
Deshalb: Wenn wir die Pflege eines Plugins einstellen, sagen wir das auf seiner Seite und in einem letzten Release, statt es still einschlafen zu lassen. Und wenn wir eine Sicherheitsaktualisierung ausliefern, steht in der Änderungsliste, dass es eine Sicherheitsaktualisierung ist - so kann jeder, der unsere Plugins verfolgt, zwischen einem Fix und einem neuen Feature unterscheiden.
Für Kunden mit regulatorischen Pflichten
Wenn Sie unter NIS2 oder dem polnischen nationalen Cybersecurity-Gesetz arbeiten und ein Plugin von uns einsetzen, müssen Sie uns möglicherweise als Lieferanten in Ihrer ICT-Lieferkette dokumentieren. Diese Seite zusammen mit den Fristen oben ist das Dokument, auf das Sie verweisen können. Auf Anfrage bestätigen wir die Details schriftlich auf Firmenbriefpapier, einschließlich der von Ihnen eingesetzten Versionen und deren letzter Aktualisierung.
Wir können keine Vorfallmitteilungen an Behörden für Sie einreichen. Diese Pflicht liegt beim betroffenen Unternehmen, nicht bei seinem Lieferanten. Wir liefern die technischen Details, die Sie für Ihre eigene Meldung brauchen - und das innerhalb Ihres Meldungsfensters, wenn Sie uns nennen, wie lang es ist.
Kontakt
- [email protected] für Schwachstellenmeldungen
- Das Kontaktformular für alles andere
- Maschinenlesbare Version: security.txt
Zuletzt geprüft: 11. August 2026.
