Unter dem Namen „Protect The Shire“ hat Matt Mullenweg im Blog für Meta-Themen verkündet, dass Auto-Updates in Zukunft 24 Stunden verzögert ausgeliefert werden.
Temporary 24-hour cooldown period for plugin/theme releases before auto-updates. […]
https://wordpress.org/news/2026/06/pts/
Leider ist die Beschreibung falsch oder zumindest irreführend, denn es sind nicht nur die automatischen Updates, die verzögert werden, sondern auch die manuellen Updates. Im Backend wird das Update also auch nicht zum manuellen Update angezeigt.

Das Problem dabei ist nur, dass nicht bedacht wurde, dass die readme.txt für WordPress.org schon übernommen wird, also auch der neue Changelog.

Und noch problematischer ist, dass beim Neu-Installieren des Plugins trotzdem die aktuellste Version (in diesem Fall 3.6.1) installiert wird.
Dabei soll die 24-Stunden-Verzögerung ja einen Sicherheitsgewinn bringen. Zeit für LLMs und Security-Researcher, das Update auf Malware zu prüfen.
Ich verstehe die Idee, dem Prozess Zeit zu geben, um das Update überprüfen zu können, bevor es automatisch ausgerollt wird. Aber worin besteht der Vorteil, wenn ich sehen kann, dass es ein Update gibt, es aber nicht manuell aktualisieren kann?
Insbesondere, wenn das Changelog eine Sicherheitslücke erwähnt, es aber nun 24 Stunden keinen Fix über das Update-System gibt.
Im Patchstack-Security-Whitepaper wird erwähnt, dass Lücken innerhalb von etwa 5 Stunden ausgenutzt werden. Wie passt das zusammen?
Ich sehe eine Lücke im Changelog und weiß, dass die Lücke jetzt 24 Stunden nicht gefixt wird, außer ich lade die ZIP-Datei manuell herunter und installiere es selbst – denn auf WordPress.org ist die Version die aktuelle (vermutlich notwendig, damit das Update getestet werden kann) – aber sie wird halt nicht über das Update-System ausgegeben.
Das ist doch nicht sicherer? Oder übersehe ich etwas?

Was denkst du über diese Neuerung? Ergibt das Sinn für dich oder ist es eher hinderlich für die Sicherheit? Ich freue mich über eure Einschätzung in den Kommentaren!
Ergänzung 11. Juni 2026:
Der sehr geschätzte Kollege Bernhard Kau hat das Update auch mal über die WP-CLI versucht: wp plugin list. Auch so war kein Plugin-Update möglich. Die Angabe des Slugs half ebenfalls nicht: wp plugin update <plugin-slug>. Aber beim letzten Versuch mit wp plugin update <plugin-slug> --version=<neue-versionsnummer> hat es geklappt!
Falls ihr also auch mal dringend ein Plugin auf die aktuelle Version bringen müsst, dann geht es über die WP-CLI mit Angabe der neuen Versionsnummer. Alternativ könnt ihr natürlich die ZIP-Datei von w.org herunterladen und auf der Seite hochladen (und hier dann das Ersetzen mit der neuen Version bestätigen).
Ich kann ebenfalls keinen Sicherheitsvorteil erkennen. Bei mir ist es so, dass die NinjaFirewall mir eine Email schickt, dass es für ein installiertes Plugin eine Update wegen einer Sicherheitslücke gibt und das kann ich dann nicht direkt updaten, sondern lade es mir z.Z. aus dem Repository herunter und intalliere dann auf allen betroffenen Installationen manuell drüber. Das ist nur eine zeitaufwändige Zusatzarbeit!
Wenn ich die „Argumente“ von Matt richtig verstanden habe, soll Zeit gegeben werden, um evtl. neue Lücken zu entdecken. Für mich stellt sich jedoch die Frage, was kommt häufiger vor: Neue Lücken in Updates oder das Ausnutzen von bekannten Lücken? Im zweiten Punkt sehe ich das Risiko deutlich höher, weshalb das für mich ein Vorgehen ist, WordPress unsicherer zu machen.
Ja, genau das Problem habe ich auch. Ich nutze ja MainWP und InfiniteWP für die Betreuung von knapp 200 Sites und in beiden gibt es die Möglichkeit nach einem Plugin zu suchen und dann nur für diese Websites einen Install-Vorgang zu starten. Die ZIP muss ich dann herunterladen, das geht ja und dann über diesen Weg auf alle betroffenen Sites ausspielen. Ein unnötiger Aufwand.
Für viele wird das Ganze eher nach einem Bug und nicht nach einem Feature aussehen, wenn der Changelog eine neuere Version anzeigt als das Update-System. Den Timer der 24 Stunden sieht ja nur der Owner und vielleicht auch noch Committer und eher unwahrscheinlich die Support Reps, aber er ist definitiv nicht öffentlich.
Pingback: News aus dem WordPress-Universum – 7/2026