WordPress-Ticket Nr. 30465 wurde vor 10 Jahren eröffnet – Wird 2025 das Jahr sein, in dem es endlich gelöst wird?

Bereits im November 2014 äußerte ein WordPress-Entwickler namens Sergej Mueller scheinbar berechtigte Bedenken: Benutzer hätten keine Möglichkeit zu erfahren, ob ein von ihnen verwendetes Plugin aus dem offiziellen Repository entfernt wurde – selbst wenn es aus Sicherheitsgründen entfernt wurde. Sein Ticket – offiziell Nr. 30465 – wurde relativ bald darauf geschlossen, jedoch ohne Lösung. Sergej ahnte nicht, dass es fast zehn Jahre später wiedereröffnet werden würde.

Und hier sind wir, Anfang 2025, und ich schreibe ein Update darüber.

Warum?

Aus mehreren Gründen.

Erstens ist es von großer Bedeutung für einige Plugin-Sicherheitsereignisse, die kürzlich stattgefunden haben – genauer gesagt im Oktober letzten Jahres. Ich werde in Kürze darüber sprechen. Und zweitens haben der Wille und die Dynamik, das Problem zu lösen, erheblich zugenommen – die letzte Aktivität auf dem Ticket liegt weniger als einen Monat zurück:

Es sieht also so aus, als würde sich Sergejs Geduld bald endlich auszahlen …

Beginnen wir damit, die Entwicklung des Tickets nachzuzeichnen. Dann können wir darauf eingehen, was in den letzten Wochen damit passiert ist:

Von „wird nicht repariert“ bis zum Auftritt auf der WCEU 2023 🙅‍♂️

Als das Ticket zum ersten Mal geöffnet wurde, erhielt es einige Antworten, wurde jedoch vom WordPress-Chefentwickler Andrew Nacin ziemlich schnell geschlossen. Er schloss es und markierte es als „Kann nicht repariert werden“ und erklärte, dass das Entfernen des Plugins aus verschiedenen Gründen erfolgte, nicht nur aus Sicherheitsgründen:

Danach gab es eine Reihe von Kommentaren, die sich dann aber in einem einmal im Jahr (manchmal sogar weniger) Kommentar von jemandem niederschlugen, der versuchte, das Thema wieder aufleben zu lassen.

Dann, im März 2023 , geschah etwas Interessantes. Joost de Valk, eine bekannte Persönlichkeit in der WordPress-Community, hat das Ticket offiziell neu eröffnet . Sein Argument war, dass WordPress die Verantwortung habe, den Benutzern mitzuteilen, ob ein Plugin gepflegt wird oder nicht.

Er wies auch darauf hin, dass WordPress.org diese Informationen bereits auf der Plattform selbst anzeigte, allerdings erst nach einer Wartezeit von 60 Tagen. Sein Vorschlag bestand darin, die gleiche Transparenz in das WordPress-Backend zu bringen, wo Benutzer ihre Plugins tatsächlich verwalten.

Das löste im gesamten Thread eine neue Welle der Begeisterung aus. Das Ticket erfreute sich so großer Beliebtheit , dass Oliver Sild, der CEO und Mitbegründer von Patchstack, es sogar in seiner WCEU 2023- Rede erwähnte:

Er erwähnte es nicht nur, sondern ermutigte die WCEU-Teilnehmer auch, Kommentare zum Thread zu hinterlassen, indem er den benutzerdefinierten QR-Code verwendete, den er seiner Präsentation hinzugefügt hatte. Er nutzte diesen Plug auch als verzögertes Alley-Oop für einen Wettbewerb, den Patchstack im folgenden Jahr veranstalten würde.

Patchstacks Event im Oktober 2024 🪲

Im Oktober 2024 startete Patchstack im Rahmen des Cyber ​​Security Month ein Bug Bounty-Event. Wenn Olivers Erwähnung von Ticket Nr. 30465 in seiner WCEU-Rede der Knaller gewesen wäre, dann wäre das Ergebnis dieser Veranstaltung ein Volltreffer.

Sicherheitsforscher, die an der Veranstaltung teilnahmen, entdeckten in einem einzigen Monat unglaubliche 1.571 gültige Sicherheitslückenberichte. Dabei handelte es sich nicht nur um Kleinigkeiten, sondern um Folgendes:

• 73 Fälle, in denen Angreifer schädliche Dateien hochladen konnten.
• 67 SQL-Injection-Schwachstellen, die ganze Datenbanken gefährden können.
• 58 Möglichkeiten für Angreifer, ihre Privilegien zu erweitern.
• 17 Sicherheitslücken bei der Remotecodeausführung (Huch!)

Die Folgen führten dazu, dass fast 1.000 Plugins vorübergehend geschlossen wurden. Und als Patchstack versuchte, Plugin-Entwickler wegen dieser Probleme zu kontaktieren, waren fast 74 % völlig unerreichbar. Entweder waren ihre Kontaktformulare defekt, ihre E-Mails wurden zurückgesendet oder ihre Domains waren abgelaufen.

Der Clou ist, dass viele dieser anfälligen Plugins sechs bis elf Jahre lang im Repository lagen. Einige sind sogar 17 Jahre alt! Und ja, es gibt immer noch Live-Websites, die auf diesen Plugins basieren.

Unnötig zu erwähnen, dass all diese Daten Oliver im Thread dazu verhalfen, Ticket Nr. 30465 dem Abschluss voranzutreiben. Er nutzte die Gelegenheit gerne aus und veröffentlichte einige Details zwei Wochen vor der Veröffentlichung des offiziellen Patchstack-Blogbeitrags, in dem das Ereignis besprochen wurde:

Von der Diskussion zur Aktion 🛠️

Als Oliver seinen Kommentar hinzufügte, war die Aktivität in dem Thread bereits in vollem Gange, daher ist es schwierig, die einzelnen Auswirkungen abzuschätzen. Es ist jedoch nicht unangemessen anzunehmen, dass es einer wachsenden Flamme Treibstoff hinzufügte. Vor allem, weil andere Benutzer (von denen mindestens einer ein Patchstack-Mitarbeiter ist) seinen Kommentar offen unterstützen.

Als Reaktion darauf äußerte der leitende WordPress-Entwickler Dion Hulse (@dd32) in mehreren Punkten Kritik, legte aber auch gewaltig nach, indem er ein experimentelles Plugin erstellte, das die lang erwartete Funktion implementiert:

Die Implementierung ist wunderbar einfach – wenn ein Plugin im WordPress.org-Repository geschlossen wurde, sehen Benutzer eine klare, aber maßvolle Benachrichtigung. Keine panikauslösenden roten Alarme, sondern nur einfache Informationen über den Status des Plugins.

Jemand findet Sergej und sagt ihm: „Mama, wir haben es geschafft!“

Naja...fast.

Es ist noch nicht Teil des WordPress-Kerns, aber ich habe das Gefühl, dass wir hier kurz vor der Ziellinie stehen!

Nachdem sich nun gezeigt hat, dass dies möglich ist, besteht der nächste Schritt darin, über eine endgültige Implementierung zu entscheiden. Dann kann es in den WordPress-Kern integriert werden.

Was kommt als nächstes? 🎯

Zum Zeitpunkt des Verfassens dieses Artikels wird über die Aufnahme der Funktion in WordPress 6.8 nachgedacht (laut Dion Hulse), obwohl noch einige Hürden zu überwinden sind. Dazu gehören:

• Finalisierung des Benachrichtigungszeitpunkts (es gibt Diskussionen über eine mögliche Verlängerung des 60-Tage-Fensters).
• Standardisierung der Dokumentation von Schließungsgründen.
• Ausgleich des Benutzerbewusstseins mit der Belastung durch den Entwicklersupport.
• Festlegung des genauen Standorts (der Site-Integritätsbildschirm oder direkt im Plugin, wie im Plugin-Beispiel-Screenshot gezeigt).

Das große Ganze 🌐

Die Entwicklung des WordPress-Tickets Nr. 30465 verrät uns etwas Faszinierendes darüber, wie sich die WordPress-Sicherheit im letzten Jahrzehnt verändert hat. Was einst als Randfall abgetan wurde, ist mit dem Wachstum des Ökosystems und den sich vervielfachenden Sicherheitsherausforderungen immer wichtiger geworden.

Auch wenn es zehn Jahre gedauert hat, bis es soweit ist, deutet das experimentelle Plugin darauf hin, dass wir uns endlich einer Lösung nähern, die Sicherheitsbewusstsein und Benutzererfahrung in Einklang bringt. Da Millionen von WordPress-Installationen potenziell von anfälligen Plugins betroffen sind, kann diese Funktion nicht früh genug verfügbar sein.

Wenn Sie die Entwicklung verfolgen möchten, schauen Sie sich das experimentelle Plugin auf GitHub an oder behalten Sie Ticket Nr. 30465 im Auge. Dies könnte einer dieser seltenen Momente sein, in denen wir Zeuge werden können, wie ein jahrzehntelanges Gespräch zu einem greifbaren Ergebnis führt. 💡

Was halten Sie von dieser Funktion? Glauben Sie, dass es für Sie als WordPress-Benutzer hilfreich wäre, darüber informiert zu werden, dass ein Plugin geschlossen wurde? Lass es mich in den Kommentaren wissen. Wir sehen uns dort.