Website-News April 2026

WordPress-Chaos, Plugin-Skandal und neue Google-Regeln

Diese Woche häufen sich die Meldungen, die Website-Betreiber aufhorchen lassen sollten. WordPress verschiebt Version 7.0 erneut, 31 Plugins wurden über Nacht gesperrt, ein kritisches Sicherheitsleck bedroht Kontaktformulare, Google ändert seine Bewertungsrichtlinien radikal und bestraft ab Juni eine Technik, die viele gar nicht auf dem Schirm haben. Auch für Betriebe in Oldenburg, Ganderkesee und Umgebung bedeutet das: Wer seine Website nicht im Blick hat, riskiert gerade jetzt mehr als sonst. Die gute Nachricht: Die meisten Probleme lassen sich mit klarer Struktur lösen – wenn man weiß, wo man ansetzen muss.

WordPress betreibt 43,5 Prozent aller Websites weltweit – das sind über 810 Millionen Seiten. In Deutschland laufen schätzungsweise 1,7 Millionen Websites auf WordPress. Die Verbreitung macht das System zum primären Ziel für Angreifer: 90.000 Angriffe pro Minute weltweit, 13.000 gehackte WordPress-Seiten täglich. Aber die größere Gefahr kommt inzwischen nicht mehr von technischen Sicherheitslücken allein, sondern von Supply-Chain-Angriffen – wie der aktuelle Fall zeigt.

Was diese Woche passiert ist – und warum es dich betrifft

Fünf Entwicklungen haben sich in den letzten Tagen überschlagen. Einzeln betrachtet wirkt jede davon wie eine Randnotiz für Technikbegeisterte. Zusammen genommen zeigen sie ein Muster: Website-Sicherheit und Compliance sind 2026 keine statischen Checklisten mehr, sondern ein fortlaufender Prozess. Wer denkt „Meine Website läuft seit drei Jahren problemlos, also ist sie in Ordnung", übersieht strukturelle Veränderungen.

Der Patchstack WordPress Security Report 2026 dokumentiert 11.334 neue Schwachstellen allein im Jahr 2025 – ein Anstieg von 42 Prozent. 91 Prozent dieser Schwachstellen betreffen Plugins, nicht WordPress selbst. Die mediane Zeit zwischen Veröffentlichung einer kritischen Lücke und ihrer massenhaften Ausnutzung: 5 Stunden. Das bedeutet: Sobald eine Schwachstelle öffentlich bekannt wird, haben Angreifer binnen weniger Stunden automatisierte Skripte am Laufen, die weltweit WordPress-Installationen scannen.

Was ich als Webentwickler aus der Region Oldenburg bei lokalen Betrieben regelmäßig sehe: Websites laufen auf WordPress 6.2 oder 6.3, Plugins sind teilweise 18 Monate veraltet, niemand hat einen aktiven Wartungsvertrag. Das ist kein Vorwurf – viele Betriebe haben einfach andere Prioritäten. Aber die Gefährdungslage hat sich verändert. Was 2020 noch als „gut genug" durchging, ist 2026 ein reales Risiko.

Die fünf aktuellen Entwicklungen dieser Woche betreffen unterschiedliche Bereiche, haben aber einen gemeinsamen Nenner: Sie erfordern aktives Handeln, nicht nur passives Abwarten.

Thema 1: WordPress 7.0 – Die Verzögerung und was sie bedeutet

Am 22. April 2026 veröffentlicht das WordPress-Team den aktualisierten Zeitplan für Version 7.0. Ursprünglich für Anfang April geplant, wurde der Release mehrfach verschoben. Aktuell liegt Release Candidate 2 vor, aber das WordPress-Entwicklerteam kommuniziert offen: Diese RC-Versionen haben trotz ihrer Nummerierung Beta-Qualität. Für Produktivumgebungen sind sie nicht geeignet.

Was das konkret bedeutet: Wer aktuell ein WordPress-Projekt plant – sei es ein Relaunch, ein neuer Online-Shop oder eine erweiterte Unternehmenswebsite – sollte mit WordPress 6.9.4 arbeiten. Das ist die letzte stabile Version der 6er-Reihe. Der Upgrade auf 7.0 sollte erst nach dem stabilen Release PLUS dem ersten Patch evaluiert werden. Warum dieser zusätzliche Schritt? Große WordPress-Updates bringen typischerweise in den ersten 2-4 Wochen kleinere Bugfixes und Kompatibilitätskorrekturen. Version 7.0.1 oder 7.0.2 wird diese Kinderkrankheiten behoben haben.

Für bestehende Websites gilt: Nicht sofort nach Release auf 7.0 aktualisieren. Backup erstellen, in Testumgebung prüfen, 2-3 Wochen auf Community-Feedback und erste Patches warten. WordPress 7.0 bringt Real-Time Collaboration, AI Connectors UI und ein vollständig redesigntes Admin-Interface. Diese Features sind mächtig, aber sie verändern Kern-Workflows. Plugins müssen angepasst werden, Themes benötigen Updates. Wer am Release-Tag blind aktualisiert, riskiert Kompatibilitätsprobleme mit bestehenden Plugins.

Ein Punkt, den viele Anleitungen im Netz übersehen: WordPress-Updates sind nicht nur ein technischer Klick. Bei Websites mit individuellen Anpassungen, Custom Post Types oder speziellen Plugin-Konfigurationen kann ein Update Stunden Nacharbeit bedeuten. Die Verzögerung von 7.0 ist aus dieser Perspektive keine schlechte Nachricht – sie gibt dem Ökosystem mehr Zeit zur Vorbereitung.

Thema 2: Der Supply-Chain-Angriff – 31 Plugins über Nacht gesperrt

In der Nacht auf den 15. April 2026 hat WordPress.org 31 Plugins mit insgesamt über 400.000 Installationen gesperrt. Der Grund: Ein koordinierter Supply-Chain-Angriff über das Flippa-Marktplatz. Ein Käufer erwarb ein Portfolio von WordPress-Plugins von einem etablierten Entwickler. Acht Monate lang blieb alles unauffällig – normale Updates, keine Auffälligkeiten. Dann, am 14. April, wurde über eine reguläre Update-Funktion eine Backdoor aktiviert, die in den Code eingeschleust worden war.

Betroffene Plugins umfassen unter anderem Countdown Timer Ultimate (über 80.000 Installationen), Blog Designer Pack (über 100.000 Installationen) und verschiedene Popup-Maker-Varianten. Die vollständige Liste findet sich im WordPress.org Plugin Security Advisory vom 15. April 2026. Die Backdoor ermöglichte unbefugten Zugriff auf wp-config.php – die zentrale Konfigurationsdatei jeder WordPress-Installation, in der Datenbankzugänge und Security Keys gespeichert sind.

Das Perfide an diesem Angriff: WordPress.org hat zwar ein erzwungenes Update ausgerollt, das die Backdoor aus dem Plugin-Code entfernt. Aber: Der Code, der bereits in wp-config.php eingeschleust wurde, bleibt bestehen. Automatische Updates beheben diesen Teil NICHT. Das bedeutet: Jede Website, auf der eines der betroffenen Plugins zum Zeitpunkt des Angriffs aktiv war, benötigt eine manuelle Prüfung der wp-config.php.

Wie prüfst du das? wp-config.php per FTP oder SSH herunterladen, mit einem Texteditor öffnen und nach unbekanntem Code-Schnipseln suchen. Suche insbesondere nach base64_decode()-Aufrufen, eval()-Statements oder verdächtigen Funktionen, die du nicht selbst eingefügt hast. Falls du technisch nicht versiert bist: Ein Entwickler kann diese Prüfung in 10-15 Minuten durchführen. Das ist der Unterschied zwischen „Website ist kompromittiert" und „Website ist sauber".

Was viele nicht wissen: Dieser Angriffsvektor wird zunehmen. Flippa, Envato Marketplace und andere Plugin-Verkaufsplattformen sind legitime Geschäftsmodelle. Entwickler verkaufen ihre Plugins, wenn sie aussteigen oder sich umorientieren. Käufer erwerben etablierte Code-Basen mit tausenden Installationen. Das Problem: Niemand prüft bei diesen Übernahmen die Motivationen des Käufers. Und Code-Reviews bei Updates sind bei frei verfügbaren Plugins minimal.

Bin ich von dem Plugin-Skandal betroffen?

Wenn du nicht sicher bist, ob eines der 31 gesperrten Plugins auf deiner Website läuft, gehe zu Plugins → Installierte Plugins im WordPress-Backend. Deaktivierte Plugins zählen auch – sie müssen nicht aktiv sein, um die Backdoor enthalten zu haben. Prüfe besonders: Countdown Timer Ultimate, Blog Designer, Popup Maker (alle Varianten), Social Media Share Buttons & Social Sharing Icons (verschiedene Varianten von EssentialPlugin). Die vollständige Liste ist auf wordpress.org/news verfügbar.

Falls du betroffen bist: Sofort auf die bereinigte Version updaten (WordPress hat erzwungene Updates ausgerollt), wp-config.php manuell prüfen, alle WordPress-Admin-Passwörter ändern, Security Keys in wp-config.php neu generieren. Das sind vier Schritte, die zusammen 20-30 Minuten dauern, aber den Unterschied zwischen „kompromittiert" und „sicher" ausmachen können.

Thema 3: Ninja Forms File Upload – Kritische Sicherheitslücke CVE-2026-0740

Parallel zum Plugin-Skandal wurde am 16. April 2026 eine kritische Sicherheitslücke in Ninja Forms bekannt: CVE-2026-0740, CVSS-Score 9.8 (kritisch). Ninja Forms ist eines der beliebtesten Kontaktformular-Plugins mit über 1 Million Installationen weltweit. Die Lücke betrifft das File-Upload-Feature. Angreifer können ohne jede Authentifizierung beliebige Dateien auf den Server hochladen – darunter PHP-Skripte, die dann ausführbar sind.

Wordfence berichtete am 18. April, dass seit Bekanntwerden der Lücke bereits über 118.600 Angriffsversuche blockiert wurden. Das ist keine theoretische Gefahr – das ist aktive Massenausnutzung binnen 48 Stunden. Der Fix ist in Version 3.3.27 verfügbar. Wichtig: Version 3.3.25 reicht NICHT aus, es gab einen zweiten Patch. Nur 3.3.27 oder höher schließt die Lücke vollständig.

Wer ist betroffen? Alle WordPress-Websites, die Ninja Forms mit aktivierter Datei-Upload-Funktion nutzen. Das betrifft typischerweise Kontaktformulare, Bewerbungsformulare, Supportanfragen. Falls du nicht sicher bist, ob Datei-Uploads aktiviert sind: Gehe zu Ninja Forms → Dashboard → Forms, öffne jedes Formular und prüfe, ob ein „File Upload"-Feld vorhanden ist. Selbst wenn das Formular nicht öffentlich sichtbar ist – die Lücke kann trotzdem ausnutzbar sein.

Was ich bei Website-Checks in der Region häufig sehe: Kontaktformulare werden einmal eingerichtet und dann vergessen. Niemand prüft regelmäßig, welche Plugins das Formular antreiben. Ninja Forms, Contact Form 7, WPForms – viele Websites haben zwei oder drei Formular-Plugins gleichzeitig installiert, weil bei einem Relaunch das alte Plugin nicht deaktiviert wurde. Jedes zusätzliche Plugin ist ein zusätzlicher Angriffsvektor.

Die Empfehlung für Ninja Forms: Sofort auf 3.3.27 updaten. Danach: Prüfe deinen Server auf verdächtige Dateien. Typische Upload-Verzeichnisse sind /wp-content/uploads/ und /wp-content/nfuploads/. Dort sollten KEINE .php-Dateien liegen. Falls du welche findest und nicht weißt, woher sie stammen: Nicht einfach löschen, sondern erst von einem Entwickler prüfen lassen. Es könnte legitimer Code sein – oder eben Malware.

Kostenloser Website-Check

Du willst wissen, ob deine Website von den aktuellen Sicherheitsproblemen betroffen ist? Ich prüfe bei einem kostenlosen 20-Minuten Check:

Welche Plugins laufen auf deiner Website? Sind betroffene Plugins dabei?
Ist deine WordPress-Version aktuell oder läufst du auf einer veralteten Installation?
Gibt es verdächtige Dateien in Upload-Verzeichnissen?
Ist deine wp-config.php kompromittiert? (Quick-Scan auf auffälligen Code)

Kostenlos und unverbindlich. 20 Minuten, die Klarheit schaffen.

Für Betriebe in Oldenburg, Ganderkesee, Wardenburg, Hude, Großenkneten und Umgebung.

→ Kontaktformular

Thema 4: Google verbietet Mitarbeiter-Namen in Bewertungen

Am 17. April 2026 hat Google seine Review-Richtlinien verschärft. Neu verboten: Bewertungen anzufordern, die konkrete Mitarbeiter-Namen enthalten sollen. Ebenso verboten: Mitarbeitern Review-Quoten vorzugeben. Die Konsequenz bei Verstößen: Review-Löschung und Profil-Maßnahmen, bis hin zur Sperrung des Google Business Profils.

Was das konkret bedeutet: Viele lokale Betriebe nutzen Strategien wie „Sag bitte Anna im Review, dass sie dir geholfen hat" oder „Erwähne Torben in deiner Bewertung". Das ist ab jetzt explizit verboten. Google erkannte, dass solche Anforderungen Bewertungen manipulieren – nicht in Bezug auf die Sterne-Anzahl, aber in Bezug auf die Authentizität. Echte Kunden schreiben über ihre Erfahrung mit dem Betrieb, nicht über einzelne Mitarbeiter.

Betroffene Prozesse in KMU: Kassen-Flyer mit „Erwähne bitte [Name] in deiner Google-Bewertung", Bonus-Systeme, bei denen Mitarbeiter Prämien für Bewertungen mit ihrem Namen erhalten, E-Mail-Vorlagen mit vorformuliertem Text inklusive Mitarbeiter-Namen. All diese Praktiken verstoßen jetzt gegen Googles Richtlinien.

Was erlaubt bleibt: Kunden um Bewertungen bitten (allgemein), auf Google Business Profil hinweisen, positive Erfahrungen zum Anlass nehmen, um eine Bewertung zu bitten. Was nicht erlaubt ist: Vorgaben, WAS in der Bewertung stehen soll (inklusive Namen), finanzielle Anreize für Bewertungen, Reviews als Mitarbeiter-Performance-Metrik nutzen.

Warum diese Änderung jetzt? Google hat erkannt, dass Bewertungen mit Mitarbeiter-Namen-Anforderungen ein Muster zeigen: Sie sind oft kürzer, generischer und weniger authentisch. Echte 5-Sterne-Bewertungen erzählen eine Geschichte. Vorgefertigte Bewertungen mit „Danke an [Name]" als Hauptinhalt bieten wenig Mehrwert für andere Nutzer.

Was du jetzt tun solltest: Prüfe deine aktuellen Review-Anforderungs-Prozesse. Kassen-Flyer, E-Mail-Signaturen, Website-Popups – überall, wo du Bewertungen anforderst, sollte KEIN Mitarbeiter-Name erwähnt werden. Falls du bisher Mitarbeiter-Boni an Bewertungen geknüpft hast: Diese Kennzahl muss ersetzt werden. Google scannt aktiv nach solchen Mustern und löscht Bewertungen rückwirkend.

Thema 5: Back Button Hijacking wird ab 15. Juni bestraft

Die letzte Entwicklung dieser Woche betrifft eine Technik, die viele gar nicht bewusst einsetzen: Back Button Hijacking. Google hat am 18. April angekündigt, dass die Manipulation des Browser-Zurück-Buttons ab 15. Juni 2026 als Spam eingestuft wird. Websites, die diese Technik nutzen, riskieren Ranking-Verluste.

Was ist Back Button Hijacking? Eine Seite manipuliert den Browser-Verlauf so, dass der Zurück-Button nicht zur vorherigen Seite führt, sondern entweder auf derselben Seite bleibt oder zu einer anderen Seite weiterleitet. Das wird oft absichtlich eingesetzt, um Nutzer auf der Seite zu halten oder auf Werbeseiten umzuleiten. Aber – und das ist der kritische Punkt – viele Websites nutzen diese Technik unbeabsichtigt.

Typische Auslöser: Third-Party-Werbeanzeigen (AdSense, Display-Ads), Consent-Banner mit falscher JavaScript-Integration, Tracking-Libraries (Facebook Pixel, Google Analytics, wenn falsch implementiert), WordPress-Popup-Plugins, die den History-API-Stack manipulieren.

Wie merkst du, ob deine Website betroffen ist? Öffne deine Website in einem Inkognito-Tab, navigiere durch 2-3 Seiten, drücke dann den Zurück-Button. Führt er dich zur vorherigen Seite? Oder bleibst du auf derselben Seite / wirst umgeleitet? Falls letzteres: Du hast ein Back Button Hijacking-Problem.

Die technische Ursache liegt meist in JavaScript-Code, der history.pushState() oder history.replaceState() unsauber nutzt. Viele WordPress-Themes und Plugins manipulieren den Browser-Verlauf für Single-Page-Application-ähnliches Verhalten – ohne zu bedenken, dass das den Zurück-Button brechen kann.

Was du jetzt tun solltest: Teste deine Website manuell (siehe oben), prüfe alle aktiven JavaScript-Libraries (Google Tag Manager, Facebook Pixel, Analytics), deaktiviere testweise Popup-Plugins und prüfe erneut. Falls das Problem verschwindet: Das Plugin ist die Ursache. Falls du ein WordPress-Theme mit AJAX-Navigation nutzt: Prüfe, ob es eine Option gibt, diese Funktion zu deaktivieren. Die Karenzzeit bis 15. Juni gibt dir zwei Monate Zeit zur Behebung. Danach drohen Ranking-Verluste.

Warum "schnell mal selbst machen" oft nach hinten losgeht

Die fünf Themen dieser Woche haben eines gemeinsam: Sie klingen auf den ersten Blick nach simplen Checklisten. „Plugin updaten", „Datei löschen", „Flyer anpassen" – das klingt machbar. Die Praxis zeigt ein anderes Bild. WordPress-Updates können Plugins brechen. Die Suche nach Malware-Code in wp-config.php erfordert technisches Verständnis, um legitimen Code von Schadcode zu unterscheiden. Back Button Hijacking-Tests brauchen Browser-Developer-Tools und JavaScript-Kenntnisse.

Das ist kein Plädoyer gegen Eigeninitiative. Wer technisch versiert ist, kann vieles selbst lösen. Aber die Fehlerquote bei halbherzigen Lösungen ist hoch. Ein falsch gelöschter Code-Block in wp-config.php kann die gesamte Website crashen. Ein übereilig deaktiviertes Plugin kann Funktionen brechen, die an anderer Stelle benötigt werden. Ein nicht vollständig behobenes Back Button-Problem führt trotzdem zu Ranking-Verlusten.

Aus meiner Erfahrung mit lokalen Websites in der Region Oldenburg: Die größten Probleme entstehen nicht durch Unwissenheit, sondern durch Zeitdruck. Ein Betrieb sieht die Meldung über gesperrte Plugins, klickt hektisch durch WordPress, deaktiviert irgendetwas – und drei Tage später ist das Kontaktformular kaputt, ohne dass der Zusammenhang klar wird. Sorgfalt braucht Zeit. Und Zeit ist genau das, was bei Sicherheitsproblemen oft fehlt.

Die gute Nachricht: Die meisten Konkurrenten in der Region tun noch nichts. Websites laufen auf WordPress 6.1, Plugins sind veraltet, Google-Review-Prozesse enthalten noch Mitarbeiter-Namen. Wer JETZT handelt, hat einen echten Vorsprung – nicht weil die Konkurrenz schlecht ist, sondern weil sie die Entwicklungen noch nicht mitbekommen hat.

Was du jetzt konkret tun solltest

Du hast jetzt einen guten Überblick über die fünf Entwicklungen dieser Woche. Die entscheidende Frage ist: Wo steht DEINE Website? Welche der fünf Themen betreffen dich? Und was ist der erste Schritt?

Ein kostenloser Website-Check gibt dir Klarheit. Ich prüfe in 20 Minuten: Läuft deine Website auf einer aktuellen WordPress-Version oder steht ein Update bevor (mit Blick auf 7.0)? Sind betroffene Plugins vom Supply-Chain-Angriff auf deiner Website installiert? Nutzt du Ninja Forms mit File-Upload, und ist die kritische Lücke gepatcht? Wie sehen deine aktuellen Review-Anforderungsprozesse aus – verstoßen sie gegen die neuen Google-Richtlinien? Manipuliert deine Website den Browser-Zurück-Button (unbeabsichtigt oder absichtlich)?

Das sind fünf Fragen, die sich in 20 Minuten beantworten lassen. Das Ergebnis ist eine klare Einschätzung: Handlungsbedarf ja oder nein, und falls ja – was ist priorisiert.

Kostenloser Website-Check & Strategiegespräch

Du willst wissen, wo deine Website steht und welche der aktuellen Entwicklungen dich betreffen? Ich prüfe bei einem kostenlosen 20-Minuten Check:

WordPress-Version & Update-Strategie für 7.0: Bist du auf einem stabilen Release oder läuft eine veraltete Version?
Plugin-Sicherheit: Sind die 31 gesperrten Plugins oder Ninja Forms auf deiner Website installiert?
Review-Prozesse: Verstoßen deine aktuellen Anforderungen gegen die neuen Google-Richtlinien?
Back Button Hijacking: Manipuliert deine Website den Browser-Verlauf?